# git

## Setup
- Login with your username found on your name badge and set the initial password for your account:  https://git.aspp.school/user/login
- You'll have to type that password many many times this week: choose wisely!
- We will use the [exercise](exercise.md) in the repo for the rest of the lecture
- find a partner to do pair-programming for this lecture by finding someone with the same tarot card as you
- before starting, make yourself acquainted with the meanining and the power of the tarot cards: carefully read [this booklet](https://aspp.school/wiki/_media/tarot-runic.pdf)

## A cautionary quote

> My first instinct is to sell all my computers, fake my own death, move to another planet, and reinvent computing from scratch, rather than try to understand Git.
> 
>    I rarely actually do that, mind you. But the urge is there.

— Lars Wirzenius (Linux kernel developer)

## Warm-Up
- how to start a repo from scratch?
    - `git init` local method
    - on an online forge (GitHub, GitLab, …): `git clone`
- how to revert mistakes?
    - before commit:
      - `git restore <file>` [discard changes in the working directory] __changes files__
      - `git restore --staged <file>` [unstage changes ➔ opposite of `git add <file>`, does not modify the working directory]
    - after commit:
      - `git revert <commit>` [creates a new commit, modifies the working directory]
      - `git reset <commit>` [only reset the HEAD pointer, does not modify the working directory] __rewrites history__ ➔ can not be used if you have already pushed to some remote
      - `git reset --hard <commit>` [reset HEAD and modify working directory] __rewrites history__ and __changes files__ ➔ can not be used if you have already pushed to some remote
- how to *move* the whole working directory to a specific point in history?
    - `git checkout <commit>` ➔ `DETACHED HEAD` problem, __changes__ __files__
    - interaction with branches: `git branch <branch_name>` + `git switch <branch_name>` 
- how to copy a file from a different branch:
    - `git checkout <branch> <file>` ➔ the file is staged automatically
    - `git restore --source=<branch> <file` ➔ the file is not staged
- `git gui`: building commits along the way interactively (for the *mess around* type of workflows)
- check out these [sketches](git-commands-visualizations.pdf) for a graphical visualization of git commands!

## The Open Source model
- remotes: `git pull <from_where> <what>`, `git push <where> <what>`, `git fetch <from_where> <what>`, `git merge <another_branch>`
- GitHub: forks, branches and PRs: important ➔ explain fork vs. clone!!!
- strategies for keeping your fork up-to-date: your `main`, origin's and upstream's `main`, short-lived and long-lived topic branches
- a more thorough and detailed explanation can be found on the [SciPy Contributor's Guide](https://docs.scipy.org/doc/scipy/dev/gitwash/gitwash.html). This guide can be adapted to your own needs, see [gitwash](https://github.com/matthew-brett/gitwash).
- make it clear that GitHub and GitLab are just options (git≠GitHub)

## Scenarios
1. [lone scientist](scenarios/scenario1.png) working alone in the cellar without Internet (local git)
2. [lone scientist](scenarios/scenario2.png) uploading their software to the Internet in the hope it can be useful for other people (local git + one personal GitHub repo)
3. [lone scientist](scenarios/scenario3.png) sharing one software project with some other befriended lone scientist working in a different place (local git + one personal GitHub repo + permissions)
4. [research group](scenarios/scenario4.png) sharing software among members (local git + several GitHub repos + permissions + branches + [optional] PRs)
5. [fully distributed software development](scenarios/scenario5.png) using the most typical open source software workflows as used by numpy, scipy, sklearn, etc. (like above + we don't trust our contributors, i.e. work strictly with forks)