Our git flow

We've decided to go with the forking model because it provides less opportunities to break upstream's master (upstream = https://github.com/rails-up/expert). Also there should be more visibility with pull requests from different people's accounts.

Tutorial

Here's a good tutorial: Atlassian forking flow tutorial. You probably won't understand everything on the first try and will have to refer to it later. Sections of interest in the tutorial: "Forking workflow" and "How it works" for general understanding; "Example" for practical stuff.

NOTE: We won't use feature branches for simplicity.
NOTE2: Nothing is actually stopping you from using feature branches within your fork.

The flow in a nutshell

Upstream repo will have a master branch with a general rule that it should always be in a working state. There will also be a develop branch - it will be the only branch that gets merged into master. You will fork the upstream using github web interface. Within your fork (the origin) you will have copies of both branches and you have to stick to develop branch for your work locally. As soon as you have cool stuff to share with others, you want to merge upstream/develop into your develop (locally using a git console command). Then push your develop to origin/develop (console command again). Then go to github.com and create a pull request for merging origin/develop into upstream/develop.

Just give me the console commands!

make a local copy of your fork
git clone [email protected]:$name/expert.git

do your work within this branch
git checkout develop

merge upstream/develop in before publishing your stuff
git pull upstream develop

push your work to origin for making a pull request
git add . && git commit -m "$message" && git push origin develop

FAQ

Ask questions right here if you have the permissions or in #git_question-answers. The most frequent will be published here.