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.
This post has been published on Medium, too.
Medium
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 master, frequently.
Naming Branches
We have a pattern for naming our branches.
[Module Name]-[Type]-[Detail]
// Example
users-fix-attach-roles-issue#765
Module Name
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.
Type
According to the type of task, developers should choose between one of these types:
featureenhancecleanuprefactorfixhotfix
Type hotfix is for urgent fixes on the master branch and won't be used that often.
Detail
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.
Commit Messages
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 dev (or 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 dev (or 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.
Pull Requests
Title
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.
Body
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.
Review
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.
Top comments (0)