Overview
Teaching: 20 min
Exercises: 40 minQuestionsObjectives
- How can we collaborate with others within one repository?
- Understand how to collaborate using a centralized workflow.
- Understand the difference between local branch, origin/branch, and remote branch.
Git implements a distributed version control. This means that any type of repository links that you can think of can be implemented - not just “everything connects to one central server”.
In this episode, we will explore the usage of a centralized workflow for collaborating online on a gitlab project.
In Git, all repositories are equivalent but in the typical centralized style, we consider one repository as the main development line and this is marked as “central”. The “central” is a role, not a technical difference.
Features:
Advantages:
Disadvantages:
In this exercise we will practice collaborative centralized workflow in small groups. We’ll discuss how this leads to code review and discuss a number of typical pitfalls.
Exercise preparation
- We form small groups (4-5 persons).
- Each group needs to appoint someone who will host the shared GitLab repository: an administrator.
- For online teaching, use breakout rooms.
One person per group (administrator) generates a new repository by importing the template-centralized-workflow-exercise repository called
centralized-workflow-exercise
.- Then everyone in your group needs their GitLab account to be added as collaborator to the exercise repository:
- Participants give their GitLab usernames (or gfz email address) to their chosen administrator (in their respective group).
- Administrator gives the other group members the newly created gitlab repository URL.
- Administrator adds participants as collaborators to their project (Members → Invite member).
- You can use this template to share this information in the collaborative document:
# Group N - administrator: some_user - exercise URL: https://gitlab.com/someuser/centralized-workflow-exercise - collaborators: - another_user - yetanother_user - my_username - other_username
Watching and unwatching repositories
- Now that you are a collaborator, you get notified about new issues and merge requests via email.
- If you do not wish this, you can remove your selected notification (top of the project page).
- However, we recommend using notification for repositories you are interested in. You can learn things from experts just by watching the activity that come through.
$ git clone https://git.gfz-potsdam.de/swc-bb/swc-lessons/2021-02-24-potsdam-berlin/template-centralized-workflow-exercise.git centralized-workflow-exercise
Where you replace swc-bb/swc-lessons/2020-11-05-potsdam-berlin
by the namespace of the repository administrator.
This is a representation of what happens when you clone:
remote:
local:
git clone
creates pointers origin/master
so you can see the branches of the origin.origin
refers to where we cloned from, try: git remote -v
.origin
is a shortcut for the full URL.origin/master
is a read-only pointer.git pull
or git fetch
or git push
.git pull
or git fetch
or git push
require network.$ cd centralized-workflow-exercise
yourname/somefeature
pointing at your commitCreate a branch from the current master
:
$ git branch yourname/somefeature
$ git checkout yourname/somefeature
The yourname/
prefix has no special meaning here (not like origin/
): it is just part of a
branch name to indicate who made it.
yourusername.txt
In this file share your favourite cooking recipe or haiku or Git trick or whatever.
$ git add yourusername.txt
$ git commit
remote:
local:
$ git push origin -u yourname/somefeature
Can we leave out the -u
?
After you have pushed your branch and other participants have too, browse the network of branches and commits and discuss with others what you see.
Submit a merge request from your branch towards the master
branch.
Do this through the web interface.
A merge-request means: “please review my changes and if you agree, merge them with a mouse-click”. In a popular project, it means that anyone can contribute with almost no work on the maintainer’s side - a big win.
Code review and protected branches
- Merge requests are like change proposals.
- We recommend that merge requests are reviewed by someone else in your group.
- In our example everyone has write access to the “central” repository.
- A good setting is to make the
master
branch protected and all changes to it have to go through code review.- Centralized workflow with protected branches is a good setup for many projects.
Once the merge-request is accepted, the change is merged:
central:
local:
Finally also discuss /network.
Your branch yourname/somefeature
is not needed anymore but more importantly, you need to sync your local copy:
$ git checkout master
$ git pull origin master
central:
local:
Exercise/discussion: Why did we create a feature branch
yourname/somefeature
?This exercise is done in groups of 4-5 persons and can be done through a discussion only. Whenever we make update to our repository, we create a new branch and make merge-request. Let’s now imagine that everyone in your group makes a new change (create a new file) but without creating a new branch.
- You all create a new file in the master branch, stage and commit your change locally.
- Try to push the change to the upstream repository:
$ git push origin master
You probably see something like this:
$ git push To https://gitlab.com/user/repo.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://gitlab.com/user/repo.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
- The push only worked for one participant.
- Discuss why push for everybody else in this group was rejected?
Discussion: How to make changes to remote branches
We can create a local branch
somefeature
trackingorigin/somefeature
:$ git checkout -b somefeature origin/somefeature
If there is no local branch
somefeature
and there is a remote branchorigin/somefeature
, then this is enough:$ git checkout somefeature
Once we track a remote branch, we can pull from it and push to it:
$ git pull origin somefeature $ git push origin somefeature
We can also delete remote branches:
$ git push origin --delete somefeature
Key Points
Centralized workflow is often used for remote collaborative work.
origin
refers to where you cloned from (but you can relocate it).
origin/mybranch
is a read-only pointer to branchmybranch
onorigin
.These read-only pointers only move when you
git fetch
/git pull
orgit push
.