Exercise to practice collaborative centralized workflow. On the way to a pull request and code review we will meet and discuss a number of typical pitfalls.

1. Participants add their usernames to a shared document.
2. Instructor adds participants as collaborators to this project.

$ cd centralized-workflow-exercise

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

$ git add yourusername.txt
$ git commit

$ 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".

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.

It will work only for one participant. Why?

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

$ git pull origin master

Ideas? What happened under the hood? Discuss git fetch as an alternative to git pull. Discuss git pull --rebase as an alternative to avoid merge commits.

It will work for one more person.

First find out the hash of your commit, then create a branch "in the past" pointing to that hash:

$ git branch yourname/somefeature [hash]

$ git push origin -u yourname/somefeature

Can we leave out the -u?

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

Finally also discuss {{ site.centralized_workflow_exercise_url }}/network.