Introduction to git

In this exercise, we practice collaborative centralized workflow:

First, we all clone (make a local copy) and try to push (send code to) the main repository. We’ll see a small problem with that, and then make a pull request (sending code so that others can review and accept later). We’ll discuss how this leads to code review and discuss a number of typical pitfalls.

Before we start:

Everyone needs their GitHub account to be added to our central repository.
Participants add their usernames to a shared document.
Instructor adds participants as collaborators to this project.

1. Clone this repository

$ git clone git@github.com:comp-sci-tools/centralized-workflow-exercise.git centralized-workflow-exercise

Note: set up ssh keys:

This is a representation of what happens when you clone:

remote:

local:

We clone the entire history, all branches, all commits.
git clone creates pointers origin/master and origin/experiment.
origin refers to where we cloned from, try: git remote -v.
origin is a shortcut for the full URL.
origin/master and origin/experiment are read-only pointers.
They only move during git pull or git fetch or git push.
Only git pull or git fetch or git push require network.
All other operations are local operations.

2. Step into the newly created directory

$ cd centralized-workflow-exercise

3. Create a file with a unique name, e.g.: `yourusername.txt`

In this file share your favourite cooking recipe or haiku or Git trick or whatever.

4. Stage and commit the change

$ git add yourusername.txt
$ git commit

remote:

local:

5. Try to push the change to the upstream repository

$ git push origin master

By “upstream” we mean here the repository which we have cloned. Imagine “upstream” being closer to the main development and your local clone to be “downstream”.

6. Stop here: why push for most participants was rejected?

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. Why?

remote:

local:

The natural reflex is now to git pull first but what happens if we git pull origin master?

7. Pull updates from the upstream repository

$ git pull origin master

remote:

local:

8. Stop here: why we obtained a merge commit locally?

Ideas? What happened under the hood?

We did:

$ git pull origin master

which is equivalent to:

$ git fetch origin
$ git merge origin/master

git pull consists of two operations: a git fetch followed by a git merge.
Summary: git pull origin master fetches master from origin and merges it.
There is always a git merge “hidden” in git pull.
Many people will simply git pull, very careful people first git fetch and inspect the commits before merging them.
With Git you typically merge several times a day without even noticing.

An alternative:

$ git pull --rebase origin master

would have produced:

remote:

local:

9. Try to push again

It will work for one more person.

10. Create a branch `yourname/somefeature` pointing at your commit

First find out the hash of your commit. You can do this using git graph or git log:

$ git log yourusername.txt

Then create a branch “in the past” pointing to that hash:

$ git branch yourname/somefeature [hash]

The yourname/ prefix has no special meaning: it is just part of a branch name to indicate who made it (we discussed branch naming before).

11. Push your change as a new branch

$ git push origin -u yourname/somefeature

Can we leave out the -u (-u is equivalent to --set-upstream)?

12. Submit a pull request

Submit a pull request from your branch towards the master branch. Do this through the web interface.

How to make changes to remote branches

Create a local branch somefeature tracking origin/somefeature:

$ git checkout -b somefeature origin/somefeature

If there is no local branch somefeature and 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

Centralized workflow with protected branches

Forking workflow may be overkill for small closed-source projects.
A good alternative to the forking workflow for a group of collaborators is to use a protected (only certain people may directly push to it) master branch.
Only designated “code owners” have write access to the protected branch.
Anyone else may contribute code changes via pull requests from feature branches.
Pull requests need to be approved by a code owner.
Discuss the advantages or disadvantages of this workflow.

previous episode