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
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: