Every team has its own workflow based on the type of project, company size, team preferences, and many other things. The bigger the team, the harder it is to keep everything under control: problems with conflicts become more common, release dates need to be postponed and priorities keep getting changed on the fly.

Employing Git solves the basic issues with code collaboration but it is not always enough. Given Git’s focus on flexibility, there is no standardized process on how to interact with Git. When working with a team on a Git-managed project, it’s important to make sure the team is all in agreement on how the flow of changes will be applied. To ensure the team is on the same page, an agreed-upon Git workflow should be developed or selected.

Git is not opinionated, but lots of people have opinions about how you should do it.

Git Workflow

Our source control workflow is a big part of our project development workflow, so it has a big impact on developers day to day quality of life. A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner.

Git workflows encourage users to leverage Git effectively and consistently. Ideally, our Git workflow is going to align well with our business processes, so it’s good to take a look at the most common strategies rather than blindly pick what you think is the most popular.

1. Centralized Workflow

The Centralized Workflow uses a central repository to serve as the single point of entry for all changes to the project. The default development branch is called main and all changes are committed to this branch.

This workflow doesn’t require any other branches besides main. The central repository is the official project and should be treated as sacred and immutable (i.e. no rewriting of history).

How it works

• Clone the repository (i.e. git clone).

• Make, stage, and commit changes. (i.e. git add, git commit).

• Merge in the latest from the central repository (i.e. git pull).

• Use git pull –rebase to move all of your commits to the tip of the history.

• This will allow you to handle any conflicts on a case-by-case basis.

• Push changes (i.e. git push).

This is an easy-to-understand workflow, great for small teams or projects (i.e. few contributors). But, resolving conflicts can be a burden as the team scales up.

2. Feature Branch Workflow

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 main branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main code base.

It also means the master branch should never contain broken code, which is a huge advantage for continuous integration environments.

How it works

• Start from main (i.e. git checkout main).

• Create a new branch off of main (i.e. git checkout -b MyNewFeature).

• Similar to before, make, stage, and commit changes (i.e. git add, git commit).

• Push your new branch to the remote (or centralized) repo (i.e. git push origin MyNewFeature).

• Use the tooling of your repository management system to create a Pull Request / Merge Request.

• Note that if there are conflicts, those will need to be corrected locally

  (i.e. git pull –rebase again) and the feature branch re-pushed.

• Before the pull request, if another developer wanted to contribute to the feature branch, they could pull it locally to contribute to it (i.e. git pull MyNewFeature) assuming the feature branch has already been pushed to the centralized repository.

3. Gitflow Workflow

The Gitflow Workflow defines a strict branching model designed around the project release. 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.

Develop and Master Branches

Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It’s also convenient to tag all commits in the main branch with a version number.

Feature Branches

Each new feature should reside in its branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of main, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master

Release Branches

Making release branches is another straightforward branching operation. Like feature branches, release branches are based on the develop branch. Creating this branch starts the next release cycle, so no new features can be added after this point — only bug fixes, documentation generation, and other release-oriented tasks should go into this branch. Once it’s ready to ship, the release branch gets merged into main and tagged with a version number and then deployed. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release.

Hotfix Branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they’re based on master instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and main should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle.

How it works

There are so many commands involved in Gitflow workflow because of the many steps involved and strict branching concepts followed.
See Atlassian’s write-up for a complete walkthrough of this workflow with the necessary commands.

---

Conclusion:

Choosing the right Git workflow is crucial for optimizing team collaboration and maintaining a structured development process.

The Centralized Workflow offers simplicity but may pose challenges with growing teams, while the Feature Branch Workflow enhances collaboration and facilitates continuous integration. The Gitflow Workflow provides a more structured approach to release management.

Ultimately, the choice of workflow depends on team size, project complexity, and release requirements. By implementing a suitable Git workflow, development teams can streamline collaboration, ensure code quality, and effectively manage releases throughout their projects.