menuqr source control management styleguide.
- 2.1 Always have
* text=autoset on.gitattributes.
It ensures line endings are normalized.
3.1 We use a range of change types to easily identify and differentiate changes.
| Prefix | Description |
|---|---|
feature |
When adding a feature that provides real value to the product |
fix |
When fixing a bug |
wip |
When testing something (work in progress) |
refactor |
When working on a refactor of some sort |
- 4.1 Write meaningful and straightforward commit summaries.
# Bad
git commit assets -m 'changed something' # ORLY? What have you changed?
# Good
git commit assets -m 'Switched `reset.css` to `normalize.css`.'- 4.2 Avoid long commit summaries by limiting the maximum characters to
50.
Detailed descriptions should go on the commit message.
# Bad
git commit assets/javascripts -m 'Added `FIXME` note to dropdown module because it wasn't working on IE8.'
# Good
git commit assets/javascripts -m 'Added `FIXME` note to dropdown module.'- 4.3 Write commit summaries in the past tense.
By the time you commit something, the change is already there.
# Bad
git commit scripts -m 'Fix CI integration.'
# Bad
git commit scripts -m 'Fixes CI integration.'
# Bad
git commit scripts -m 'Fixing CI integration.'
# Good
git commit scripts -m 'Fixed CI integration.'- 4.4 Use proper english writing on commits.
Because SCM is also code documentation.
# Bad (Everything in lower case, no proper punctuation and "whatever" really?)
git commit assets/stylesheets -m 'updated clearfix or whatever'
# Bad (Why are you screaming?)
git commit assets/stylesheets -m 'UPDATED CLEARFIX'
# Good (Meaningful commit summary with proper orthography)
git commit assets/stylesheets -m 'Updated clearfix implementation to use a more modern approach.'- 4.5 Prefix commit summaries with the change type in upper case wrapped within
[].
This is specially useful for filtering commit entries and measuring our work.
# Bad
git commit tests -m 'Test specs.'
# Good
git commit tests -m '[FEATURE] Added test specs for JSON parser.'- 5.1 Always work inside a feature branch.
Feature branches are simple and effective. Avoid touching the
masterbranch.
- 5.2 Branches should be named as their change type, followed by their feature title (lower hypen-case and in the present tense) and then their JIRA ticket id.
We found this to be an easy way to consolidate our agile workflow with the way we ship code.
# Bad
git checkout -b fixed-analytics
# Good
git checkout -b fix/fix-analytics-implementation-1345
# Bad
git checkout -b SideBarEnhancements
# Good
git checkout -b refactor/sidebar-4055- 6.1 When fetching from remote, prefer rebase instead of the default merge.
Git's merge creates meaningless micro merge commits. Our commit history should make sense.
# Bad (default strategy is to merge, which will generate a commit entry)
git pull
# Good
git pull --rebase- 6.2 Always review your commits with interactive rebase before pushing your changes.
This is like your own code review. You're responsible for maintaining a great commit history.
# Bad
# (...) Lots of commits later
git push
# Good (rebase last 5 commits in history before pushing the changes)
git rebase -i HEAD~5 && git push
# Good (rebase specific branch against the current one before pushing the changes)
git rebase -i feature/1755-social-links-on-footer && git push- 6.3 The person who opened the pull request should be the one responsible for merging and closing it.