52 lines
3.9 KiB
Markdown
52 lines
3.9 KiB
Markdown
# 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)
|