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:
Initialize the central repository
Clone the central repository
Make changes and commit
Push new commits to the central repository
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:
Start with the master branch
Create a new-branch
Update, add, commit, and push changes
Push feature branch to remote
Create pull request
Resolve feedback
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:
A
develop
branch is created frommaster
A
release
branch is created fromdevelop
Feature
branches are created fromdevelop
When a
feature
is complete it is merged into thedevelop
branchWhen the
release
branch is done it is merged intodevelop
andmaster
If an issue in
master
is detected ahotfix
branch is created frommaster
Once the
hotfix
is complete it is merged to bothdevelop
andmaster
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:
A feature branch is created from
main
Add commits
Open a Pull Request
Discuss and review your code
deploy from a branch for final testing in production
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:
A developer 'forks' an 'official' server-side repository. This creates their own server-side copy.
The new server-side copy is cloned to their local system.
A Git remote path for the 'official' repository is added to the local clone.
A new local feature branch is created.
The developer makes changes on the new branch.
New commits are created for the changes.
The branch gets pushed to the developer's own server-side copy.
The developer opens a pull request from the new branch to the 'official' repository.
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?