Team Workflow with Git, What to pick?
They task me to write an article and here I am. Hi I’m Tsaqif and this is the story of my journey on learning about software development workflow with git, and how my team decide which workflow to choose for our project (well more accurately how we convince ourselves that this workflow and project, both given by our lecturer, is a perfect match).
The Basic, Centralized Workflow
In a Centralized Workflow, also known as the Trunk-based development,a team would only have one branch called master branch and it is usually stored in a remote server. This branch would serves as the project final branch. Development would be done on each developer’s local repository, cloned from the master branch. This workflow is the base of other workflows.
For example when a developer want to add something, they would clone the master branch to their own local repository. On that branch they would add, edit and commit but, they won’t push to the master branch until they are done with what they want to add. When it is done, they would first pull from the master branch, to make sure their local branch is up to date with the current master branch. If there were conflicts, they would fix it on their local branch and then push to the master branch. After pushing to the master branch, usually they would delete their local branch, and when they want to add more to the project, they would repeat again. Clone the master to a new local branch, and so on.
The Stylized, Feature-based Workflow
Feature-based Workflow is similar to Centralized Workflow but with a new rule added. When developers clone a new branch from master branch, they can only add changes in that branch for one specific feature. That branch is called the feature branch. That branch is later merge to the master branch after other developers review the code.
For example when a developer want to add a new feature, they would clone the master branch to a new branch and work on it. The new branch on local will also be uploaded to the remote server. After they are done and commit, they would create a merge request to the master branch. On those request, other developers can comment and start discussion about the changes. If the request have been reviewed and approved, then the branch would be merge to the master branch and the cycle repeats for the next feature.
The Upgrade, Gitflow Workflow
This workflow is an addition to the Feature-based Workflow. It’s far more complex than Feature-based Workflow and usually implemented in a large team. In this workflow they are multiple type for branches.
a. Master: The final project assembled here.
b. Development: Based from the Master branch. This branch is where all feature branches are based from.
c. Feature: Based from the Development branch. This branch is where all the changes for one feature is developed. If a feature branch is done, it would be merge to the Development branch.
d. Release: Based from the Development branch. This branch is made after all feature branches have been merge to the development branch for a particular release. In this branch no new feature would be added, only bug fixing and preparation for a release such as documentation, etc. After it is done, this branch would be merge to the master branch and development branch, and then deleted.
e. Hotfix: Based from the Master branch. This branch is where quick changes or edits are done. For example, a crucial bug passed undetected from the release branch into the master branch. A new branch from master branch is created called the hotfix branch and quickly edited and merge to master to fix it. Later it would also be merge to development branch, similar to release branch. The only difference is while release branch is based of development branch, hotfix branch is based of master branch.
In this workflow, development would be done between merging a development branch and multiple feature branches. When a set of feature is ready to be released, a release branch is made from the current development branch and additional polishing is done in that branch. After polishing, the release branch would be merge to the master branch for release and to the development branch to keep the current development up to date. If a crucial edit is needed from the production, a new branch would be created from master branch called the hotfix branch. After the quick fix, the hotfix branch is merge to master branch and development branch.
So, what to pick?
Centralized Workflow are perfect for small team and simple projects, since it’s a simple workflow and quick development are easier to be implemented in this workflow. However this workflow struggles on project with higher complexity and bigger teams.
Feature-based Workflow are perfect for small to medium team and higher complex projects than Centralized Workflow. On small teams, Feature-based workflow is a bit slower than Centralized Workflow but on medium teams, Feature-based Workflow is more effective because the feature-based branches allow the team to work multiple features on parallel, contrast to Centralized workflow that needs to be in-sync with the current development on master branch. The feature branch also prevent broken codes entering the master branch by code review before a merge.
Gitflow Workflow are perfect for large teams with complex projects. It is slower compare to the other 2 but it sacrifice speed for control. It has the same benefits from Feature-based Workflow on parallel development and broken codes prevention, but it also gives a quick recovery with hotfix branch, and allow the team to keep on developing on feature and development branch while the release branch and hotfix branch are still on the works.
So, what would we pick?
Feature-based with a sparkles of Gitflow, let me explain. We dropped Centralized Workflow because our project is not simple and we are on a schedule, so we don’t want merge conflicts slowing us down to the deadline. Feature-based Workflow would be the next option and it’s great but we want more control in our workflow because this project is an increment from a previous project and most of our teammate are not familiar with the project framework. Hopefully with an extra control we can have a smoother development pace. Finally Gitflow Workflow is far to complex and since our team isn’t that big, we wouldn’t benefit much from it.
Our workflow will be Feature-based Workflow that implements the development branch from Gitflow Workflow for more control and maybe hotfix branch if we ever need a quick fix. We dropped release branch because with the size of our team, developing while releasing won’t be feasible and it will contribute in a higher chance of merge conflicts that would just slow us down.
