Working with Git

[ctapobep]

Commit message conventions

We're using conventions similar to what they have in Linux. Example:

#12345 First line ideally is less than 50 symbols

And here we describe the change in more details. Lines here shouldn't
exceed 72 symbols. In this section we should describe what the change
is about, why the change was necessary.

You can put a lot of information here, don't be shy.

Linear history

We never use merge commits in master, the history must always stay linear. Most of the time we create lot's of temporary commits, then in the end we want to squash them into 1 (or multiple) and push to master. The easiest way of doing this:

git fetch                       # get the latest changes from GitHub
git merge origin/master         # merge latest master to your branch
git reset --soft origin/master  # uncommit all your changes
git commit -m  'blah blah'      # now commit a single pretty commit
git push origin HEAD:master     # push to master

Trunk-based development

As much as possible we use trunk-based development. Meaning we try not to work in branches for a long time. Other branches are created only to safely stash the changes for short periods of time (don't trust your local hard drive to last ;)).

Here are some rules:

1. If you're sure the change is safe (it doesn't break previously working functionality), push it to master.
2. If the change potentially is unsafe, you need to wait until QA asks for the new task.

If you use Branching by Abstraction and Feature Toggles, it's likely that you'll often have safe commits. So if you implement a new feature which requires changes in the existing code, you could copy (or abstract away) the code temporarily and push it to master; and then when QA is ready to take your feature - switch everything to the copied code and remove the outdated pieces.