Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
# Git workshop
**Welcome!**
These notes are written in the [Markdown](https://www.markdownguide.org/basic-syntax/) format.
## Git, gitlab, github?
`git` is a version control tool.
You can install it with:
- `brew` or `apt` on Mac, Linux
- https://gitforwindows.org with the `git bash` programme (my recommendation)
GitLab, GitHub are online services built around git. Nowadays they provide much more than pure version control.
GitHub has been bought by Windows a while ago.
GitLab is an "open-core" company. gitlab.com is very much like github. git.uibk.ac.at is a local gitlab server and is only good for local university projects. You can move repositories around, so starting at UIBK and then move to gitlab.com is always an option.
## Examples of utilization of gitlab/github
Project management:
- https://git.uibk.ac.at/acinn/it-projects
- https://github.com/GLIMS-RGI/rgi7_scripts/projects/1
Website:
- https://github.com/OGGM/oggm.github.io
- https://github.com/OGGM/tutorials
- jupyterbooks (makes webpages from jupyter notebooks)
- https://github.com/OGGM/oggm-edu
- https://git.uibk.ac.at/acinn/stations-metadata
- static webpage generator inside (e.g. jekyll, pelikan)
Publication:
- Works only nicely with Latex or text based editors
- Overleaf / HackMD <-> GitHub sync
Code:
- https://github.com/OGGM/oggm
- all of GitLab / GitHub
## Not so nice with git
- Pictures, data, binary files
- if you change a picture, netCDF file, can not understand the actual differences between the versions
- Branches and collaborative is quite a learning curve (worth it though)
- people working on the same script might result in conflicts which are sometimes complicated to solve (note that this is the very nature of conflicts - if fact git is trying to help us here)
- fit GUIs are confusing (I recommend to learn with the command line first)
- sometimes issues with cloud data storage (e.g., pClouddrive) for commits
- First collaboration among people can become caothic
- if you do something slightly different than your "normal" workflow, you might get "errors" or "warnings", so you might feel "afraid" that you do something wrong when "forcing" something ...
## Not so nice with gitLab
- slightly more complex if people outside of the university want to join
## Getting started with git
- you always want a local + online version of git
- when created, do git clone ... in the terminal with the "clone with HTTPS" path
- if you do not want that you have to write the password every time, use SSH, but need to exchange "keys" for each machine where you use it
- Gitlab e.g. https://docs.gitlab.com/ee/ssh/
- holy trinity of git: git fetch (information), re-doing git status will show changes, then git pull, git commit, git push
- `git commit -a -m`
- `git status` tells you what changed
- add new file with `git add` + filename
- git switch -
**The four commands which go online:**
- `git clone` `git pull` `git fetch` `git push`
## Additional tools/information
- Github to Zenodo integration (uses tags, i.e. name to specific commit to create DOIs)
## Collaborations
- Branches for collaborations
Collaborating:
- Upstream Repo (Main Repo, "the Holy one" the one you don't want to force push)
- Fork (named Origin) to clone from, i.e. Local Repo (where you add your changes ideally in a dev branch)
- Push changes to origin (fork), from that create pull request to Holy Repo
What happens when there are changes at the Holy Repo?
- git fetch upstream (from Main aka Holy Repo), git pull on clean master branch (not on dev branch)
- Best option is git rebase from dev to local master (avoid git merge)
- If conflicts arise you have to solve them (online or locally)