OverviewTeaching: 20 min
Exercises: 40 minQuestions
- 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 github 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.
Real life examples:
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.
- We form small groups (4-5 persons).
- Each group needs to appoint someone who will host the shared GitHub repository: an administrator.
- For online teaching, use breakout rooms.
One person per group (administrator) generates a new repository from the template template-centralized-workflow-exercise called
centralized-workflow-exercise(There is no need to tick “Include all branches” for this exercise):
- Then everyone in your group needs their GitHub account to be added as collaborator to the exercise repository:
- Participants give their GitHub usernames to their chosen administrator (in their respective group).
- Administrator gives the other group members the newly created github repository URL.
- Administrator adds participants as collaborators to their project (Settings → Manage Access → Invite a collaborator).
- Group members need to accept the invitation (GitHub emails you an invitation link).
- You can use this template to share this information in the collaborative document:
# Group N - administrator: someuser - exercise URL: https://github.com/someuser/centralized-workflow-exercise - collaborators: - anotheruser - yetanotheruser - myusername - otherusername
Watching and unwatching repositories
- Now that you are a collaborator, you get notified about new issues and pull requests via email.
- If you do not wish this, you can “unwatch” a repository (top of the project page).
- However, we recommend watching repositories you are interested in. You can learn things from experts just by watching the activity that come through.
$ git clone https://github.com/coderefinery/centralized-workflow-exercise.git centralized-workflow-exercise
Where you replace
coderefinery by the namespace of the repository administrator.
Instead of using https you can also clone using ssh keys:
This is a representation of what happens when you clone:
git clonecreates pointers
origin/masterso you can see the branches of the origin.
originrefers to where we cloned from, try:
git remote -v.
originis a shortcut for the full URL.
origin/masteris a read-only pointer.
git pushrequire network.
$ cd centralized-workflow-exercise
yourname/somefeaturepointing at your commit
Create a branch from the current
$ git branch yourname/somefeature $ git checkout yourname/somefeature
yourname/ prefix has no special meaning here (not like
origin/): it is just part of a
branch name to indicate who made it.
In this file share your favourite cooking recipe or haiku or Git trick or whatever.
$ git add yourusername.txt $ git commit -m "added a file for a feature and stuff"
$ git push origin -u yourname/somefeature
Can we leave out the
After you have pushed your branch and other participants have too, browse the network of branches (adiministrator’s GitHub account) and commits and discuss with others what you see.
Submit a pull request from your branch towards the
Do this through the web interface.
A pull-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
- Pull requests are like change proposals.
- We recommend that pull 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
masterbranch 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 pull-request is accepted, the change is merged:
Finally also discuss https://github.com/coderefinery/centralized-workflow-exercise/network.
yourname/somefeature is not needed anymore but more importantly, you need to sync your local copy:
$ git checkout master $ git pull origin master
Exercise/discussion: Why did we create a feature branch
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 pull-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://github.com/user/repo.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.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
$ git checkout -b somefeature origin/somefeature
If there is no local branch
somefeatureand there is a remote branch
origin/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
Creating pull requests from the command line
There are several possibilties:
How you can find out in which repositories you are a collaborator
Visit https://github.com/settings/repositories where you will see an overview of all repositories you have write access to.
- Projects often start under a personal namespace.
- If you want the project to live beyond the interest or work time of one person, one can share projects under an “organization”.
- You can then invite collaborators to an organization.
- This is what we do in the CodeRefinery project: https://github.com/coderefinery
Centralized workflow is often used for remote collaborative work.
originrefers to where you cloned from (but you can relocate it).
origin/mybranchis a read-only pointer to branch
These read-only pointers only move when you