Git workflow in 5 minutes

A stable and reliable git workflow can improve your and your team productivity. Let’s learn it in 5 minutes.

What git workflow can provide

A reliable method when writing code in a team goes a long way. Merge/Rebase hell is far too common and can waste a lot of dev time. Reviewing also becomes easier: with scoped PRs, only a small amount of code gets reviewed at a time.

Challenges to an optimal git workflow

A team is good at git as the most inexperienced team member is. It is the responsibility of everyone to make sure your own team is capable of using git.

Being on the same page is also a huge part of a good workflow. Half assign stuff never goes far.

We will assume some rules aimed at simplifying and reducing the possible issues. We aim for simplicity, as developers with different experiences will be working together.

Git workflow philosophy

History is the most precious thing git can offer us, so we are going to preserve it no matter what. This means rebase has to go, we don’t allow anything that can alter the history of our branches.

This will increase the transparency of our project. Checking older commits will offer a clearer path to understand past decisions.

Last but not least, since no one is able to change the git history, everyone works on the same one. This simplifies merging branches and reduces the number conflicts.

Branches

Master is where deployment happens. It shouldn’t do anything else. In most cases, you shouldn’t even have it on your machine.

Development is our multi-purpose branch. This is the only branch that merges into master. Every other branch should come from here. This is also where QA happens.

Work branches are where coding gets done. Based on development, they are scoped to a single feature and are short-lived.
Only one developer works on a branch. If two or more are assigned to the same feature, then each will get its own branch.
Once completed, they are reviewed and once the review is ok, merged into development.
These branches names should be self-explanatory:

• feature/login-page
• fix/lazy-loading
• refactor/error-handling

Pull Requests

Pull requests happen between work branches against development. Here reviews take place to make sure the code is up to standard. Once the branch is considered good, it can be merged into development.
Here it will be QAed, usually on a staging environment mimicking production.
Once development is good, it can be merged into master and deployed.

Commits

Commits are atomic in nature, they have a single and clear scope. The goal is to always be able to to back to an old commit and understand what it does, why and how.

For this reason names should also be clear. First letter capitalized, no longer than 50 character, no third person (wasted characters). If a commit needs more to explain its purpose, you can use the commit body to go more into details.
Good examples of commit titles:

• Fix stripe error
• Improve dropdown style
• Fix issue #123

---

Working with a team can be difficult in many ways. A good workflow can help improve your job, the amount of work delivered as well as its quality.

Simplicity is the ultimate sophistication.