- Cleanup: delete branches after it was merged into `master`
(2 slides - Lukas/Georgiana)
## Best practices - Naming convensions
- Use **meaningful** names for branches
- `feature_<short-desc>` for a new feature
- `bugfix_<short-desc>` for a bugfix
- Use **meaningful** commit message made of a title (max 50 chars) and a body containing a detailed explanation
* name convensions for branches
* text for commit message; structure of the commit message (1 line + \n + comment)
* keep commits as small as possible
* one branch per one functionality/bugfix
* good examples
## Best practices - Good Examples
TODO
## Remote repo & dkrz GitLab
# Remote repository & dkrz GitLab
(3-4 slides - Georgiana/Lukas)
* checkout existing repository: fork vs clone; push/pull
* remote repo
* GitLab: setup authentication based on ssh keys
* add new members to a project
* merge requests
* stop lecture: do exercises
- checkout existing repository: fork vs clone; push/pull
- remote repo
- GitLab: setup authentication based on ssh keys
- add new members to a project
- merge requests
- stop lecture: do exercises
## fork vs clone
- `git clone`: download locally (`local`) the remote repository (`origin`)
- `git fork` & `git clone`: duplicate the original repository (`upstream`) under a different username (`origin`) and then download it locally (`local`)
- check the remote links
```bash
git remote -v
```
## fetch vs pull
```bash
git pull
```
=
```bash
git fetch
+
git merge
```
## GitLab merge requests
- web interface to review the code changes proposed to be merged into the main branch
- holds useful info:
- author
- reviewer
- change diff
- commits history
- gitlab pipeline status
- ...
## Take-away/Summary
(Lukas/Georgiana)
* you should use git daily!
* industry is using it as defacto standard
* always choose merge requests instead of pushing code directly to the main branch
