Bureaucrat, emailconfirmed, incoming, administrator, uploaders
735
edits
Changes
→SCM history: Add another link to git commit message guide. I found this helpful as it links back to Git and Linux repos to model good message style.
* We provide a permanent, stable master branch (i.e., no force pushes).
* We try to write [http://chris.beams.io/posts/git-commit/ thorough , informative] and [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html well-formatted] commit messages. As a rule of thumb: relevant information that cannot be deduced easily from the patch itself should be provided in the commit message's ''body'', e.g. what other approaches were tried first and why they did not work, a motivating blurb why the patch is desirable, or links to discussions.
* In general, we prefer merging to rebasing, so that individual commits continue to reflect what was actually the true development history (i.e., what was tested and working at the time). That said, we do use rebasing sometimes on topic branches to keep our commits well organized and easy to understand.
* We use topic branches for large feature additions and complex code changes, and purge them promptly once merged to master. We prefer to make explicit merges (i.e. with <code>--no-ff</code>) to document the purpose of each merged branch.
