The journey of using Git - Zero to Workflow

During my first year in the University, people have been talking about Git. Some of us, the freshies, tried to adapt it in our assignments. We rushed through the basic tutorial, learning about the magic commands of git clone, git pull, git add, git commit and git push origin master and assume that they are the gist of Git. We knew a little about the scary merge conflict little monster, therefore we had some discussion to avoid it at the first place.

 
We managed to pull through.
 

In fact, with a small improvement of handling merge conflict properly, I have managed to pull through in my early career in a startup and new team in a mid-size company, until I joined a large organisation that requires heavy collaboration between engineers. I was required to study the onboarding materials and get exposed to Git Workflows. In the meantime, I have started to contribute to open source project in GitHub. It was an Ah Ha! moment to me as everything connects.

I wish I'd known about the terminology Git Workflow earlier. Hopefully this article is able to help you to gain awareness of some common Git Workflows and explore them in depth if you hasn't.

Centralized Workflow

If you work individually or in a team where everyone is developing features to the master/main branch directly, this workflow is called the Centralized Workflow. It is okay for small team but the conflict resolution process can form a bottleneck as your team scales in size. This workflow is intuitive for Git beginner, or teams that are transitioning from SVN.

The Centralized Workflow is essentially a building block for other Git workflows.

Feature branching

With some further reading of Git branching, it will be intuitive to create branches for development. Perhaps you have tried to create a branch for entire development, or assign one branch for each developer using the developer's name as branch name, etc. You are very close to the idea of Feature branching.

Feature Branching is a logical extension of Centralized Workflow. The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase.

Gitflow Workflow

With the foundation of Feature Branching, you can proceed to understand the famous Gitflow Workflow. This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. The overall flow for Gitflow Workflow is:

1. A develop branch is created from master
2. A release branch is created from develop
3. Feature branches are created from develop
4. When a feature is complete it is merged into the develop branch
5. When the release branch is done it is merged into develop and master
6. If an issue in master is detected a hotfix branch is created from master
7. Once the hotfix is complete it is merged to both develop and master

Forking Workflow

If you are interested to contribute to Open Source, I strongly recommend you to understand the Forking Workflow. The Forking Workflow is fundamentally different than the other workflows discussed above. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. You can imagine yourself contributing on a public project with the step-by-step example of this workflow.

1. A developer 'forks' an 'official' server-side repository. This creates their own server-side copy.
2. The new server-side copy is cloned to their local system.
3. A Git remote path for the 'official' repository is added to the local clone.
4. A new local feature branch is created.
5. The developer makes changes on the new branch.
6. New commits are created for the changes.
7. The branch gets pushed to the developer's own server-side copy.
8. The developer opens a pull request from the new branch to the 'official' repository.
9. The pull request gets approved for merge and is merged into the original server-side repository.

You can understand further from the external links attached on the workflows or search the keyword online. This blog is not served as a complete explanation for each workflow, but intended to give an overview of some common Git Workflows.

Some key takeaways are:

• There is no one-size-fits-all Git workflow
• A workflow should be simple and enhance the productivity of your team
• Your business requirements should help shape your Git workflow