Managing a Better Git Workflow
Introduction
It is hard to manage a large codebase, especially with the large teams with many developers. To increase the code quality and team efficiency, a robust git workflow is the essential practice for the team.
Thanks to git workflow from Atlassian, we can have a comprehensive idea for different kinds of git workflows like feature branch, gitflow, forking workflow, etc.
In this article, we will make use of those technique to help shaping up the idea how to build up a better git workflow.
Why Important?
Especially for a large team, developers always be divided into different small teams, each team will keep developing features and finally merge their codes into a central branch, usually a develop branch. Since every teams are working on their own private branch, different teams may work on the same line of codes or amend project dependencies. Once the codes merge into the central branch, it may have merge conflicts. If the team cannot handle the merge conflicts well, the whole project may get stuck.
Prerequisites
What do we need with the good git workflow? To ensure code quality, large team should discuss together to setup some best practices for the team.
Firstly, the whole team should follow the same code styles. Code Styles is like the grammer of the languages, developers should follow the code style guide to write their codes.
Use mobile development as an example, there are some code styles guides:
Swift — https://github.com/linkedin/swift-style-guide
Kotlin — https://github.com/raywenderlich/kotlin-style-guide
There are some other open source guides on GitHub, discussing with your teammates to build up the most approapriate guides for the whole team.
Secondly, choosing the git workflow and git practices.
Gitflow is the famous workflow. It is a good starting point to reference. The feature/develop/release branches will be the foundation of the git workflow.
Pull Request is a great practice to protect the main branch from code pollution . With the practices like code review, teams can ensure code quality by keeping at least two people on same piece of codes. Moreover, by enabling automated pull request unit test, teams can have much more confidence with the code safety.
Git rebase is a great tool to manage commit history. With the help with git rebase, commits can be combined and also well organized. It is a good practice for a large team since the team can easily keep track the problem throughout the whole commit history.
This blog post shows how clean the commit history is after using git rebase.
Finally, the branching strategy.
For the general agile software development cycle, dev team will start with a sprint kick-off meeting. All members in the team have to agree all the checkout branches for the sprint after sprint kick-off meeting. Everyone will take up some tasks and team can foresee what branches need to checkout.
User stories and tasks should be classified as features or hot-fixes. Thus, corresponding feature branches, hot-fixes branches will be planned and assigned to corresponding engineers.
Depending on the culture of the team, there should be one or more engineers to be the owner of the develop/release branch, usaually is the technical lead engineer or an experienced one. The roles for these people is to ensure all commits merging to develop/release branches should be reviewed or passed the automated testings if there is in the development pipeline. The owner is the one to do code review for all pull requests to the protected branches (develop/release branch).
When Feature Branch Completed
Once the engineers complete codings in their feature branch, firstly, they do is to tidy up the comments of their commits by git rebase.
For more info about git rebase using command line and Sourcetree, checkout these.
Secondly, fetch the develop branch to check whether there are changes upstream. If there are changes, engineers need to rebase the local changes on the upstream’s commits. It is important to do it in local branch to protect the upstream one from pollution. And this is the safe place to resolve merge conflicts.
Lastly, pushing the local feature branch to remote origin. Filing the pull request to team lead which is the owner of the developer branch.
Pull Request & Code Review
Master, Develop and Release branches are common protected branches. Codes cannot freely be merged into these branches. Experienced developers like team lead should be the owner of these branches to watch for any unapproved commits.
Branch owners also need to review pull requests to approve commits to merge into the protected branch. The owners have right to reject the pull request based on some predefined organization internal rules. For example, owners can reject codes without following style guides, or codes without rebasing.
For common mistake using git, this is a great article from @i_AnkurBiswas
Conclusion
A better git workflow is an essential tool to support good code quality and hence a good product. I hope that I can bring out some ideas to inspire your team to build up your own workflow.
