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 branch strategy effectively and consistently. Git offers a lot of flexibility in how users manage changes. Given Git's focus on flexibility, there is no standardized process on how to interact with Git. To ensure the team is on the same page, an agreed upon Git workflow should be developed or selected. There are several publicized Git workflows that may be a good fit for your team. The array of possible workflows can make it hard to know where to begin when implementing Git in the workplace. This page provides a starting point by surveying the most common Git workflows for software teams. As you read through, remember that these workflows are designed to be guidelines rather than concrete rules. What is a successful Git workflow. You want the workflow to enhance the effectiveness of your team and not be a burden that limits productivity. Like Subversion, the Centralized Workflow uses a central git branch strategy 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. Your team can develop projects in the exact same way as they do with Subversion. First, it gives every developer their own local copy of the entire project. This isolated environment lets each developer work independently of all other changes to a project - they can add commits to their local git branch strategy and completely forget about upstream developments until it's convenient for them. The Centralized Workflow is similar to other workflows in its utilization of a remote server-side hosted repository that developers push and pull form. Compared to other workflows, the Centralized Workflow has no defined pull request git branch strategy forking patterns. How it works Developers start by cloning the central repository. Initialize the central repository First, someone needs to create the central repository on a server. Hosted central repositories Central repositories are often created through 3rd party Git hosting services like or. The process of initializing a bare repository discussed above is handled for you by the hosting service. The hosting service will then provide an address for the central repository to access from your local repository. Clone the central repository Next, each developer creates a local copy of the entire project. Make changes and commit Once the repository is cloned locally, a developer can make changes using the standard Git commit process: edit, stage, and commit. This can be very useful for large features that need to be broken down into simpler, more atomic chunks. Push new commits to central repository Once the local repository has new changes committed. These change will need to be pushed to share with other developers on the project. When pushing changes to the central repository, it is possible that updates from another developer have been previously pushed that contain code which conflict with the intended push updates. Git will output a message indicating this conflict. In this situation, git pull will first need to be executed. This conflict scenario will be expanded on in the following section. Managing conflicts The central repository represents the official project, so its commit history should be treated as sacred and immutable. Before the developer can publish their feature, they need to fetch the updated central commits and rebase their changes on top of them. If local changes directly conflict with upstream commits, Git will pause the rebasing process and give you a chance to manually resolve the conflicts. The nice thing about Git is that it uses the same git status and git add commands for both generating commits and resolving merge conflicts. This makes it easy for new developers to manage their own merges. Plus, if they get themselves into trouble, Git makes it very easy to abort the entire rebase and try again or go find help. John works on his feature In his local repository, John can develop features using the standard Git commit process: edit, stage, and commit. John publishes his feature Once John finishes his feature, he should publish his local commits to the central repository so other team members can access it. He can do this with the command, like so: git push origin master Remember that origin is the remote connection to the central repository that Git created when John cloned it. Merge the remote changes e. This prevents Mary from overwriting official commits. Mary resolves a merge conflict Rebasing works by transferring each local commit to the updated master branch one at a time. This means that you catch merge conflicts on a commit-by-commit basis rather than resolving all of them in one massive merge commit. This keeps your commits as focused as possible and makes for a clean project history. In turn, this makes it much easier to figure out git branch strategy bugs were introduced and, if necessary, to roll back changes with minimal impact on the project. In our example, Mary would simply run a to see where the problem is. Git will move on to the next commit and repeat the process for any other commits that generate conflicts. The Centralized Workflow is great for small teams. The conflict resolution process detailed above can form a bottleneck as your team scales in size. If your team is comfortable with the Centralized Workflow but wants to streamline its collaboration efforts, it's definitely worth exploring the benefits of the. Other common workflows The Centralized Workflow is essentially a building block for other Git workflows. Most popular Git workflows will have some sort of centralized repo that individual developers will push and pull from. git branch strategy Below we will briefly discuss some other popular Git workflows. These extended workflows offer more specialized patterns in regard to managing branches for feature development, hot fixes, and eventual release. Feature branching Feature Branching is a logical extension of Centralized Workflow. The core idea behind the 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 should never contain broken code, which is a huge advantage for continuous integration git branch strategy. Gitflow Workflow The was first published in a highly regarded 2010 blog post from. The Gitflow Workflow defines a strict branching model designed around the project release. Instead, it assigns very specific roles to different branches and defines how and when they should interact. Forking Workflow The is fundamentally different than the other workflows discussed in this tutorial. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. Guidelines There is no one size fits all Git workflow. In addition to team culture, a workflow should also complement business culture. If your team is using you may want to use branches that correspond with tasks in progress. In addition, some guidelines to consider when deciding on a workflow are: Short-lived branches The longer a branch lives separate from the production branch, the higher the risk for merge conflicts and deployment challenges. Short-lived branches git branch strategy cleaner merges and deploys. A workflow that tests a branch before allowing it to be merged into the master branch is an example. If you plan to release multiple times a day, you will want to keep your master branch stable. If your release schedule is less frequent, you may want to consider using Git tags to tag a branch to a version. Summary In this document we discussed Git workflows. We took an in-depth look at a Centralized Workflow with practical examples. Expanding on the Centralized Workflow we discussed additional specialized workflows.
