Skip to content

Latest commit

 

History

History
147 lines (91 loc) · 4.81 KB

git.md

File metadata and controls

147 lines (91 loc) · 4.81 KB
Raw

Git Guidelines

###Table of content:

  1. Master Branch
  2. Commit messages
  3. Commiting and pushing
  4. Coding features
  5. Applying fixes
  6. Commit review
  7. Deploying
  8. Git configuration

Master branch

The master branch should be kept stable at all times.

Master reflects code currently running on production.

Commit messages

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]

  1. Summary is maximally 80 characters long, from capital letter, no dot at the end

  2. We prepend ID of an issue in issue tracker at the beginning of summary

  3. Next lines are description explaining the details

  4. At the very end we sometimes put tags for various tools (CI etc).

  5. Write present-tense, imperative-style commit messages

    GOOD: [JIRA-123] Add currency service

    BAD: [JIRA-123] Adds currency service

BAD: [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.

Coding features

We commit directly to next branch unless:

  1. Feature cannot be easily disabled by feature flag
  2. Feature is not going to be released at the end of current sprint
  3. Feature concern code redesign that can affect other developers
  4. 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: feature/something-new.

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/PRO-123-something-new

Feature branch flow

Feature branches are branched only from next.

Before merge feature branch to next:

  1. We always issue git rebase -i next on feature branch and
  2. We use --no-ff flag 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 next.

Applying fixes

Fixes are applied using following rules:

  1. Bugs in master branch are fixed in master and immediately merged to next branch.
  2. Bugs in next are fixed in next, rebased to all feature branches
  3. Bugs in feature branches are fixed in feature branched and rebased before merge to next

Once feature is merged to next, all fixes should go to next.

Global changes like:

  1. Localeapp pull
  2. Config/Settings/Env updates
  3. Gems update

Which not affecting to core functions should go direct to branch staging or next e.g via feature branch.

Commit review

We use internal GHCR tool for doing code review.

We use [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.

Deploying

When we decide the next branch is to be deployed, we:

  1. We make sure everything works as expected on staging and CI
  2. We merge next branch to master branch with flag --no-ff
  3. We push code to production

After deployment all feature branches are rebased to current next.

Git configuration

git config --global branch.autosetuprebase always
git config --global rerere.enabled true

The autorebase prevents "merge hells" that happend when we git pull without --rebase flag.

The rerere git feature feature remembers our past merge conflicts.