Git Guidelines

Git branches

When naming git branches:

• Put the related issue number at the beginning, but please leave out the hash
• Add a brief description after the issue number, separate issue number and individual words w/ dashes

For example:

1691-blank-jazz-landingpage
1664-dropdown-filter-regression
1435-heading-line-height-regression
1787-staging-basic-auth

Git commits

• Please read How to Write a Git Commit Message and adapt the guidelines outlined there
• Make sure your commit message includes fixes #issue-number if a related issue exists.
• when multiple commits go inside a PR to resolve an issue, the PR title should be "..., resolves #1691". The individual commits should have "..., ref #1691" (as each commit for itself does not resolve the issue)
• Avoid including files in source control that are specific to your development machine or process. Use global .gitignore for those.

Pull requests

Before requesting a review for your PR, please:

• fix all linter warnings (if a warning is unjustified make a note or create a PR to disable this specific linter in our default linter configuration repo)
• Ensure feature branch is up-to-date with master (if not - please rebase it).
• Squash related commits together (use git rebase interactively to squash them into cohesive commits with good messages).
• Give the PR a clear, meaningful title.

Working with gems from git repositories

When working with gems from git repositories and before requesting a PR merge into master, always explicitly specify a branch or tag or a specific SHA for this repository in the Gemfile using the ref, tag or branch keywords (see http://bundler.io/v1.12/git.html).

Otherwise we could end up with a broken master branch in case e.g. commits are squashed before a merge (thus rewriting the SHA) which would not get automatically updated in Gemfile.lock due to the implicit reliance on the outdated git revision.