workflow.md

Usually, the workflow looks like this on github:

1. You find a repo you want to contribute to, say coala/coala
2. You fork it on github, which creates a copy zenara/coala
3. You copy it to your machine with git clone https://github.com/zenara/coala (actually, it's better to use ssh here, but let's omit that now) At this point, git creates origin that points to your repo: zenara/coala.
4. You create upstream with git remote add upstream https://github.com/coala/coala that points back to original repo.
5. You create a local branch with your changes: git checkout -b zenara-awesome-feature
6. You develop/test it for a long-long time (the coala/coala repo moves forward in the meantime)
7. You are ready with your local feature branch. Now, you need to catch up with the coala/coala repo.
8. You get back to the local master branch (which is "old" now): git checkout master
9. You update it from upstream to make it fresh again: git pull upstream master
10. You test that the master branch (without your changes) works on your machine.
11. You add all the advances from the master branch into your feature branch: git checkout zenara-awesome-feature followed by git rebase master
12. You test that zenara-awesome-feature works on your machine.
13. You push it to zenara/coala with git push --set-upstream zenara-awesome-feature
14. You go to github and use its user interface to create a pull request.
15. You get comments that you need to fix/update/change something in your feature, so you repeat steps from 7 to 14. You usually end up moving/removing/squashing your commits, which makes a completely new git history. To push that new history, step 15 no longer works, you need to force-push with git push --force That updates your awesome-feature-branch on zenara/coala Github is smart enough to notice that and updates your PR request to coala/coala/ automatically.
16. If somebody asks for changes again, you repeat from step 17.
17. Finally, you get merged.