-
Notifications
You must be signed in to change notification settings - Fork 255
Git workflow
[WIP!] With the move to Git and Github, there are much more tools at the disposal of contributors.
Here are a few guidelines to keep, for the repositories to be clean, easy to read back, and less bug- and confusion- prone.
-
Atomic commits. http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Convention This is a requirement, for readability, repository cleanliness and decent collaboration.
-
Feature branches, bug-fix branches.
It is preferable to make a branch, if you develop a new feature, or a multi-commit bug fix. It doesn't matter that you started in your local repository master branch. Before making a pull request (PR), you can start a branch, that will contain what you already committed.
- Branch: git checkout -b new_awesome_stuff
- Push: git push origin new_awesome_stuff
- Make a PR. Document what you're proposing.
-
All commits must be signed-off. Please see the readme of each repository, for instructions.
-
If you receive a PR: Please check it out. Make sure it does what it says it does, and it's correctly signed-off, formatted, tested, referring to one single item. If it contains "merge" commits, or other useless or unrelated commits, please ask the contributor to rebase it.
Rebase: http://www.kernel.org/pub/software/scm/git/docs/v1.6.0.6/git-rebase.html
It will be useful to know how to do an interactive rebase:
git rebase -i [commit] (where commit can be the hash of a commit, or HEAD~3)
Cherry-picking: http://beust.com/weblog/2010/09/15/a-quick-guide-to-pull-requests/