📌 Learning objectives:
- Learn to collaborate with Git
- Discover GitLab/GitHub
- Start working in team
Branches are what naturally happens when you want to work on multiple features at the same time. This is also useful to collaborate in teams.
You wouldn't want to end up with a master
branch that has Feature A half done
and Feature B half done.
git branch
lists the local branches of your project:
$ git branch
* master
git checkout feature
switches to the branch named feature
if it
exists. To create a branch and switch to it, you can also use:
$ git checkout -b feature
Switched to a new branch 'feature'
- Create a branch named
feature
- Switch to it (if not done in a single command)
- Create and commit the following files:
pluton.txt
,jupyter.txt
andearth.txt
- Switch to the
master
branch and see what happens
Merging is Git's way of putting a forked history back together again. The git merge
command lets you take the independent lines of development created by
git branch
and integrate them into a single branch.
$ git merge feature
Always generate a merge commit:
$ git merge --no-ff feature
$ git branch -d feature
Force delete a branch with -D
:
$ git branch -D branch-not-merged
- Switch to
master
and mergefeature
into it - View the log with the
--graph
option - Create a branch named
feature-no-ff
- Add a new file
mercury.txt
and commit it - Switch to
master
and merge this branch with the--no-ff
option - View the log with the
--graph
option
Remote repositories are versions of your project that are hosted on the Internet or network somewhere.
$ git remote -v
origin [email protected]:tailordev-academy/git-101.git (fetch)
origin [email protected]:tailordev-academy/git-101.git (push)
$ git remote add <name> <repo>
$ git remote rm <name>
$ git remote set-url <name> <new repo>
git clone <repo>
downloads a full copy of a repository into a new directory.
Different protocols are supported: file, HTTPS, SSH, etc.
It automatically setups a default origin
remote for repo
that you can use
for push
and pull
.
git pull <remote> <branch>
copies changes from a remote repository to a local
repository.
git pull
is a shortcut for git fetch
+ git merge
.
git fetch
retrieves the commits from a remote repository, but do not apply
them on your working directory. git merge
applies them.
git push <remote> <branch>
copies changes from a local repository to a remote
repository.
GitLab is an Open Source (MIT licensed) web-based Git repository manager with wiki and issue tracking features.
- Log in to https://gitlab.com/
- Create a group
- Create a project inside this group
- Add a
README.md
file via GitLab - Clone this repository locally
- Create a feature branch
- Add a
CONTRIBUTING.md
file - Push this branch to GitLab
- Open a merge request
- Review your changes and merge
- Synchronize your local repository
Git can support your project not just with version control, but also with collaboration and release management.
There are many workflows but let's focus on a simple one.
master
must always be deployable- all changes made through feature branches (merge request + merge)
- rebase to avoid/resolve conflicts; merge in to
master
- keep
master
in working order - rebase your feature branches
- pull in (rebase on top of) changes
- tag releases
- push feature branches for discussion
- learn to rebase
- merge in broken code
- commit onto
master
directly- no hotfix onto
master
, use a feature branch
- no hotfix onto
- rebase
master
- merge with conflicts, handle conflicts upon rebasing
git rebase
"replays" the commits of your branch on top of a branch, usually
master
.
You may have to "force-push" your branch (-f
) since commits are applied again
(identifiers change).
git pull
is a shortcut for git fetch
+ git merge
.
git fetch
retrieves the commits from a remote repository, but do not apply
them on your working directory. git merge
applies them.
You can use --rebase
to rebase a branch on pull:
$ git pull --rebase origin master
- Modify the
README.md
file on GitLab - Modify the
README.md
file locally - Push your change without synchronizing your local repository and see what happens
- Rebase your local branch and push it
Congratulations, you have resolved your first conflict 🎉
- Give access to your GitLab project to a teammate
- Tell her to propose a change to the
README.md
file - Review her code, you can add comments
- Once everything looks good, accept the merge request
Invert the roles and do these steps again.
- Each team creates a simple issue, for instance to add a few lorem
ipsum paragraphs to the
README.md
file - Each team forks a project from another team and proposes a fix for the issue of that project
- You can edit your own
README.md
file in the meantime - Review the merge request, comment it if needed
- Accept the merge request when it looks good