Git workflows

Centralized flow

The Centralized Workflow is a great Git workflow for teams transitioning from SVN. Like Subversion, the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. Instead of trunk, the default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master.

Compared to other workflows, the Centralized Workflow has no defined pull request or forking patterns. A Centralized Workflow is generally better suited for teams migrating from SVN to Git and smaller size teams.

The overall flow of Centralized workflow is:

  1. Initialize the central repository

  2. Clone the central repository

  3. Make changes and commit

  4. Push new commits to the central repository

  5. Resolve conflicts if exists

Git Feature Branch 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. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

The Feature Branch Workflow assumes a central repository, and master represents the official project history. Instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch

Some key takeaways to know about Feature Branch workflow are:

  • focused on branching patterns

  • can be leveraged by other repo oriented workflows

  • promotes collaboration with team members through pull requests and merge reviews

The overall flow of Feature Branch workflow is:

  1. Start with the master branch

  2. Create a new-branch

  3. Update, add, commit, and push changes

  4. Push feature branch to remote

  5. Create pull request

  6. Resolve feedback

  7. Merge pull request to master

Git flow

Gitflow Workflow is a Git workflow that helps with continuous software development and implementing DevOps practices. The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.

Some key takeaways to know about Gitflow are:

  • The workflow is great for a release-based software workflow.

  • Gitflow offers a dedicated channel for hotfixes to production.

The overall flow of Gitflow 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

The additional complexity inherent to Git Flow is necessary for certain situations, such as:

  • When you have discrete named or numbered releases

  • When you need to freeze development on a release candidate while still continuing to develop and integrate features for a subsequent release. This may happen, for example, when a release candidate needs to be reviewed, accepted with bug fixes, or approved before being released. Development continues on a subsequent release simultaneously

  • When multiple versions of the software need to be supported and maintained independently

GitHub flow

GitHub proposes an alternate workflow called GitHub Flow. GitHub Flow has some of the same elements as Git Flow, such as feature branches. But unlike Git Flow, GitHub Flow combines the mainline and release branches into a “master” and treats hotfixes just like feature branches.

This simplified model is better suited to continuous delivery models where changes can be quickly made and easily deployed, sometimes multiple times a day.

The overall flow of GitHub flow is:

  1. A feature branch is created from main

  2. Add commits

  3. Open a Pull Request

  4. Discuss and review your code

  5. deploy from a branch for final testing in production

  6. Merge to main

Forking workflow

The Forking Workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own 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. The Forking Workflow is most often seen in public open-source projects.

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

The Forking Workflow typically follows a branching model based on the Gitflow Workflow. This means that complete feature branches will be purposed for merge into the original project maintainer's repository. The result is a distributed workflow that provides a flexible way for large, organic teams (including untrusted third parties) to collaborate securely. This also makes it an ideal workflow for open source projects.

The overall flow of Forking workflow is:

  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

The Forking Workflow helps a maintainer of a project open up the repository to contributions from any developer without having to manually manage authorization settings for each individual contributor. This gives the maintainer more of a "pull" style workflow. Most commonly used in open-source projects, the Forking Workflow can also be applied to private business workflows to give more authoritative control over what is merged into a release. This can be useful in teams that have Deploy Managers or strict release cycles.

How to choose the workflow

When evaluating a workflow for your team, it's most important that you consider your team’s culture. You want the workflow to enhance the effectiveness of your team and not be a burden that limits productivity. Some things to consider when evaluating a Git workflow 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

  • Does this workflow scale with team size?

  • Is it easy to undo mistakes and errors with this workflow?

  • Does this workflow impose any new unnecessary cognitive overhead to the team?

Last updated

Was this helpful?