Git without a doubt is one of the essential tools for every developer. As helpful as Git is, not following best practices will make it completely useless. That’s why there are different standard workflows to make most out of Git and its awesome features.
For a long time, my inception of Git and GitHub was a tool that back-ups the codes and let us access them online; Which was not completely wrong, but there are so much more about them that I didn’t know until I start my work as a developer in YasnaTeam.
In our team, about 10 developers are actively working on the same repository. Having the same habit and so-called culture is necessary to avoid conflicts and chaos. With over 100 commits per day, things could get out of hand very soon. To avoid such problems we implement a modified version of Gitflow.
How it works
Instead of having one single
master branch, we have another extra branch named
dev. These both branches are locked and no one can push directly into them.
master is reserved for production only. After testing new features, the repository owner updates
master before each release.
dev is the default branch that all of the developers create a branch from and merge back into.
dev is always ahead of master and it’s the only branch that will be merged into
We have a pattern for naming our branches.
[Module Name]-[Type]-[Detail]// Example users-fix-attach-roles-issue#765
Since we have a modular structure in our code base, changes related to each module should be committed on a separated branch with the module name. This part could be removed if you don’t have such structure, in your project.
According to the type of task, developers should choose between one of these types:
hotfix is for urgent fixes on the master branch and won’t be used that often.
The detail is a short description of what is going to be delivered by the branch.
This branching rules force us to separate each task to meaningful chunks and merge frequently into
dev and always have fresh branches. One great side-effect of this approach is to minimize conflicts.
In order to have clean and descriptive commit list, we also have a naming rule for commit messages (I love rules!).
[[Module Name]] [Commit Message]// Example [users] add fetch users endpoint
Having the module name in each commit message might seem redundant since we have the name in our branch, but the truth is after merging all branches into
master), looking at the commits history you cannot say which branch each of the commits was belonged to. Because right now they are all belonged to the
master) branch. In order to filter through all commits easily, we need to have the module name somewhere inside the commit message.
The commit message itself should complete the sentence “This commit will…” grammatically.
Title of the pull request is automatically filled with the branch name. In case the branch name is too generic, more details are expected to be added.
The body should contain details about the pull request. In our workflow pull requests are usually related to an existing issue. We create an issue for each bug or feature. So we link to the related issue inside the pull request body. We also mention highlights of the changes that are made inside the pull using bullet points. We have created a template for our pull requests, to facilitate the process.
Code review is one of the most important parts of our daily job. Once a pull request is created, the creator should choose two of peers to review the code based on some prespecified criteria.
Once the pull is approved by reviewers, the creator can merge into dev and delete the branch.
We have been using this workflow for more that one year and update frequently based on our needs. Do you use some other git workflows on your team? Let me know how they are.