Mastering Git: The 3 Essential Workflows for Efficient Version Controlling

Author:Murphy | View: 24914 | Time: 2025-03-22 22:58:57

If you aim to work with Git efficiently and elegantly, you've found the right place! After reading and applying the presented workflows in your project, I assure you that your projects will leverage to a new level. Adopting a Git workflow is not just a good practice for me; it's a must! You can apply it even if you don't work collaboratively, as I always have since discovering its benefits. It may seem challenging to get used to it initially, but with practice you will embrace it and find yourself fond of it. Without delay, let's discover the 3 most essential workflows.

Not a Medium member? No worries! Continue reading with this friend link.

Table of contents:

· 1. Introduction · 2. Centralized workflow · 3. Feature branch workflow · 4. Forking workflow · 5. Gitflow workflow · 6. Branch naming conventions · 7. Conclusion

1. Introduction

Hmm, when I was a beginner and I worked on simple small projects, I was only using Git to save my projects and upload them to platforms that uses Git. However, when the projects started to be just a little bit bigger, I found myself lost in my commits and had difficulty in rollbacks. I also struggled to keep my code works properly as it lacks of consistency and the risk of errors increased. Furthermore, I thought about the possibility of future collaboration! this strategy has limited code reviews and collaboration is difficult or even impossible. Therefore, I said to myself: "I need a Git workflow to establish!" and this latter was the beginning of my journey of learning Git workflows and in this tutorial I'll share with you what I have learned.

A Git workflow is a set of conventions and practices established to manage a Git repository. Working with workflows provide a well structured and organized Git repositories. It allows features and fixes isolation; enables efficient code reviews and collaboration; keeps a main branch stable; increases traceability; facilitates conflict resolution; and eases rollbacks. There are several workflows designed by development teams to meet their needs in order to manage their projects efficiently. However, these latter are generally adoptions or mixtures of one or more of 3 essential workflows namely, feature branch workflow, forking workflow and gitflow workflow .

In this article, we will discover the three essential Git workflows cited previously. However, before presenting these latter, I'll start by presenting the centralized workflow.

2. Centralized workflow

Centralized workflow is the most straightforward workflow which I've already presented in the introduction section. In this approach you only have one branch ‘master' that you work on and all the changes are directly committed to it. Indeed, this the approach we usually use when we were a beginner. Centralized workflow is suitable for simple projects and small teams. I can more or less recommend it for simple projects, however, I strongly do not recommend to use it when working in team even if it's small for the same reasons I cited before.

3. Feature branch workflow

Feature branch workflow is a straightforward workflow that involves creating a dedicated branch for each new feature/fix rather than making direct changes to the main branch. Then, rebase/merge are used to integrate the feature branch into the main branch. Keep in mind that branches are created from the main branch which keeps the latest code state of a project.

Feature branch workflow mainly involves the following commands:

To switch to the main branch:

git checkout master

To update the local branch with changes from the remote repository and automatically merge:

git pull origin master

To create a branch and activate it:

git checkout -b

To save changes:

git commit -m ""

To push the branch to the remote repository:

git push origin

To merge the branch into the main branch:

# First, ensure you are on the master branch
git checkout master
# Perform the merge
git merge

To rebase the branch:

# Switch to the branch you want to rebase
git checkout 
# Perform the rebase
git rebase master

The order of executing merging and pushing depends on the adopted strategy : while working in team, if merging is assigned to a single team member then other members should push their branches instead of merging/rebasing and then pushing the main branch with changes. Another possible scenario is that before the merge, the feature branch is submitted for review and integration (generally called pull request) and that branch can, then, be merged or closed.

Feature branch workflow is an efficient approach. It provides features isolation, eases collaboration and enables code review. Additionally, the main branch tends to be more stable and the risk of bugs introduction is reduced compared to the centralized workflow. However, in some cases more elaborate workflows are applied, as we will see in the following sections.

4. Forking workflow

Forking workflow is a bit different from the previous workflows. In general, when a new developer joins a Git project, he clones the single official server-side repository, updates it locally then pushes to changes to that repository. In forking workflow, instead of working directly on the only server-side repository, they create a copy of it on the server that serves as their personal repository: this operation is called forking. The forked repository is then cloned locally and the changes are pushed to it. Finally, the changes are proposed to the official repository by pull requests so its maintainers review and merge the pushed changes.

Forking workflow mainly involves the following commands:

To fork a repository, a fork button provided by the hosting platform is typically used. There is not a direct git command for forking.
To clone the fork to the local machine:

git clone

To keep the fork with changes made to the original repository add it as a remote :

git remote add upstream

To sync with the main repository and keep the fork up-to-date with changes made in the main repository, fetch changes from the upstream remote and merge/rebase them into the local branches :

git fetch upstream
git checkout main
git merge upstream/main  # or git rebase upstream/main
git push origin main

To create features, make changes, commit and push to the fork, the same commands as branch work flow are used:

git checkout -b 
git commit -m ""
git push origin

To create a pull request from the fork feature branch to the main repository's branch, a pull request button provided by the hosting platform is typically used as well.

Forking workflow is an efficient approach especially when contributors do not have direct write access to the main repository as in open-source projects. Other than this latter, its steps and pipeline are very similar to feature branch workflow.

5. Gitflow workflow

When working in big projects with large teams, keeping the product and the main branch stable, and surfing between the different branches become challenging. To overcome these challenges, Gitflow was introduced by Vincent Driessen. Gitflow workflow is a popular Git branching model that establishes a set of conventions for how branches are organized and managed: it defines specific branch names and their roles to improve collaboration and release management.

Gitflow workflow includes two main branches (master and develop) and three supporting types of branches (feature, release and hotfix branches) :

The master branch represents the production-ready code.
The develop branch represents the ongoing development code.
The feature branches are created for a new feature development.
The release branches are created for a new production release.
The hotfix branches are created to fix the issues in the production code.

Hmm, now that the branches are defined, they are managed as follows:

The develop branch is created from the master branch.
The feature branches are created from the develop branch and merged into develop once it's completed.
If a issue is detected in the master branch, a hotfix branch is created from the master branch and merged into master and develop branch once it's completed.
The release branch is created from the develop branch and merged into develop and master branch once it's done. The master branch is then tagged with a version number.
No new features can be added after creating a release branch but only bug fixes, documentation generation, and other release related tasks should be added in this branch.

As we can deduct, no new command is introduced in this workflow, only naming conventions and management rules are defined in this workflow : only commands for creating and merging branches, and switching between them are used.

The Gitflow workflow is powerful and offers us a simple, elegant and organized working environment where we can collaborate and, find and surf between different branches simply. Furthermore, it can adapted for our needs. For example, we can omit the release branch when working on personal offline projects.

6. Branch naming conventions

Branch naming conventions in Git or in Version Control systems in general, strengthens the project structure and organization. It also eases automation and integration with CI/CD systems and Git based platforms. The naming conventions can vary between projects and teams however, there are some common practices :

The default branch representing the production-ready code is named main or master .
The develop branch is named develop or dev .
The feature branches name is typically preceded by the prefix feature or feat as follows: feature/ or feat/ .
The release branches name is typically preceded by the prefix release and named with the release version, for example: release/version-0.1 or release/0.1 .
The hotfix branches name is typically preceded by the prefix hotfix, for example : hotfix/ .

7. Conclusion

Here comes the end of this article! In this article, I presented the three essential git workflows. By adapting a git workflow in our version controlling environment, we can successfully maintain and manage our projects. Adapting a workflow is one of the MLOps best practice as I explained in my previous tutorial. In the next articles, I will elaborate on additional workflows which are specifically defined by well-known version control platforms.

My aim through my articles is to provide my readers clear, well-organized and easy-to-follow tutorials, offering a solid introduction to the diverse topics I cover and promoting good coding and reasoning skills. I am on a never-ending journey of self-improvement, I share my findings with you through these articles. I, myself, frequently refer to my own articles as valuable resources when needed.

Thanks for reading this article. If you appreciate my tutorials, please support me by following me and subscribing to my mailing list. This way, you'll receive notifications about my new articles. If you have any questions or suggestions, feel free to leave a comment.