###Table of content:
- Master Branch
- Commit messages
- Commiting and pushing
- Coding features
- Applying fixes
- Commit review
- Git configuration
master branch should be kept stable at all times.
Master reflects code currently running on production.
We use following format for our commit messages:
[JIRA-123] Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. [skip ci]
Summary is maximally 80 characters long, from capital letter, no dot at the end
We prepend ID of an issue in issue tracker at the beginning of summary
Next lines are description explaining the details
At the very end we sometimes put tags for various tools (CI etc).
Write present-tense, imperative-style commit messages
[JIRA-123] Add currency service
[JIRA-123] Adds currency service
[JIRA-123] Added currency service
If commit is for some reason not assigned to any ticket, we use following tags:
[fix]: Changes fixing code not assigned to issue
[docs]: Changes of documentation, not affecting code
[style]: Changes that do not affect the meaning of the code
[refactor]: Changes that affect code, but not behavior of app
[perf]: Changes that improve performance
[test]: Adding missing tests
[chore]: Other, usually boring or repeating tasks
Commiting and pushing
We apply "leave the campground cleaner than you found it" rule for the code we commit.
We don't commit code with trailing whitespaces or no new line at the end.
We make sure all tests pass before pushing any code.
If pushing fails because remote is not in sync, we use
git pull --rebase command.
If we really need to use
git push --force, we use it immediately after push, or not at all.
We commit directly to
next branch unless:
- Feature cannot be easily disabled by feature flag
- Feature is not going to be released at the end of current sprint
- Feature concern code redesign that can affect other developers
- Project uses feature branches
If we decide that feature in
next is not to be released on next deploy, we mark it with feature toggle
The feature toggles should span as little code as possible, for example only hiding view through which feature can be accessed.
We name feature branches prepending "feature/" prefix and using dashes, like:
If we use Trello or JIRA in project, we also prepend ID of Trello card, like:
feature/123-something-new or JIRA project code and task number
Feature branch flow
Feature branches are branched only from
Before merge feature branch to
- We always issue
git rebase -i nexton feature branch and
- We use
--no-ffflag when merging feature branches to
next(for easy reverts).
We make sure all tests on feature branch are passing after rebasing.
We remove feature branch from repository after we merge it to
Fixes are applied using following rules:
- Bugs in
masterbranch are fixed in
masterand immediately merged to
- Bugs in
nextare fixed in
next, rebased to all feature branches
- Bugs in feature branches are fixed in feature branched and rebased before merge to
Once feature is merged to
next, all fixes should go to
Global changes like:
- Localeapp pull
- Config/Settings/Env updates
- Gems update
Which not affecting to core functions should go direct to branch
next e.g via feature branch.
We use internal GHCR tool for doing code review.
[no review] tag in description of commits that don't need code review
(like pulling translations from localeapp, debug logging, automatically generated commits).
If our commit
xxx was rejected, we commit fix and add
[accepts xxx] in description of it.
When we decide the
next branch is to be deployed, we:
- We make sure everything works as expected on staging and CI
- We merge
masterbranch with flag
- We push code to production
After deployment all feature branches are rebased to current
git config --global branch.autosetuprebase always git config --global rerere.enabled true
The autorebase prevents "merge hells" that happend when we
git pull without
rerere git feature feature remembers our past merge conflicts.