Branching Strategy

rebase vs. merge

We prefer a rebase workflow. Most work happens directly on the main branch. For that reason, we recommend setting the pull.rebase setting to merges.

git config --global pull.rebase merges

Readability

Which side are you able to read and understand more easily?

Why you should care about readable git history?

• Because you want to be able to easily decipher the order of the commits in your repository.
• Because you want to understand more easily what and when was changed.
• It facilitates finding commits that might have introduced bugs and enable rollback if necessary.
• (With semantic commit messages) to enable automatically extracting release notes, creating a change log.
• To be able to deploy any commit on your development branch using your CI/CD system.
• If you are handling mobile app releases and you are responsible for figuring out what feature is in which release.

Tips to reduce merge conflicts when using rebase:

• Rebase often. I typically recommend doing it at least once a day.
• Try to squash changes on the same line into one commit as much as possible.

References:

• When do you use Git rebase instead of Git merge?
• Clean GIT history — a Step by Step Guide