Four Common Git workflow comparisons

by Dong ([email protected])

This is a translation based on the original text (by Atlassian). All content on the page is shared by the knowledge sharing-attribution (CC by 2.5 AU) Agreement unless otherwise noted.

A wide variety of workflows makes it difficult to choose when implementing Git in your project. This tutorial provides a starting point to investigate the most common git workflows for enterprise teams.

When reading, keep in mind that workflow should be a specification rather than a golden rule. We want to show you all the workflows to get you in the same direction.

This tutorial discusses the following four types of workflows:

• Centrally-structured workflows
• Workflow based on feature branch
• Gitflow Workflow
• Fork Work Flow

Centrally-structured workflows

Transitioning to a distributed sub-version control system may seem like a daunting task, but you don't have to change your existing workflow to take advantage of the benefits of Git. Your team can still develop projects in previous SVN ways.

However, using Git to drive your development workflow shows some of the benefits that SVN does not have. First, it allows each developer to have a copy of their local full project. The isolated environment makes each developer's work independent of other modifications to the project-they can add commits in their own local repositories, ignoring upstream development at all times, until they are needed.

Second, it gives you access to Git's robust branching and merging models. Unlike SVN, the Git branch is designed as a failsafe mechanism for consolidating code and sharing changes between warehouses.

How it works

As with subversion, the centralized workflow takes the central repository as the only entry for all modifications in the project. and trunk different, the default development branch is called master , and all changes are committed to this branch. This workflow does not need to be master outside of other branches.

The developer clones the central repository locally and starts working. In their copy of the local project, they can modify files and commit changes like SVN, but these new commits are saved locally -they are completely isolated from the central repository. This allows developers to defer synchronization with upstream to their convenience.

To make changes to the official project, developers master "push" their local branch to the central repository. This step svn commit is equivalent to, except that git adds all the local commits that are not master on the central branch.

Managing conflicts

The Central warehouse represents the official project, so its submission history should be regarded as sacred and immutable. If the developer's local commits and the central repository are forked, Git will refuse to push their changes because it will overwrite the official submissions.

Before developers can release their functionality, they need to fetch updated central submissions, rebase their own changes on top of them. It's like: "I want to add my changes on top of other people's work." "It produces a perfectly linear history, just like a traditional svn workflow.

If the local and upstream commits conflict, Git pauses the rebase process, giving you the opportunity to manually resolve the conflicts. The great thing about git is that it will git status be git add used with commands to generate commits and resolve merge conflicts. This makes it easy for developers to manage their mergers. In addition, if they change something wrong, git makes it easy to quit the rebase process and try again (or ask for help).

Chestnuts

Let's take a closer look at how a common small team works with this workflow. We have two developers, John and Mary, who are developing two functions that share code through a centralized repository.

One of them initialized the central warehouse.

First, someone needs to create a central repository on the server. If this is a new project, you can initialize an empty repository. Otherwise, you'll need to import a git or SVN project that already exists.

The central repository should always be a bare repository (no working directory) and can be created like this:

ssh [email protected] git init --bare /path/to/repo.git

But make sure that the SSH user name you use user , host the domain name or IP address of the server, and the address of the storage warehouse /path/to/repo.git are valid. Note that .git it is customary to appear behind the warehouse name, indicating that it is a bare repository.

All people clone the warehouse to a local

Next, each developer creates a copy of the complete project locally. Use the git clone command:

git clone ssh://[email protected]/path/to/repo.git

When you clone a repository, Git automatically adds a origin remote connection named "parent" to the repository so that you can exchange data with the repository later.

John is developing his features.

In his local repository, John can submit process development features with standard GIT: edit, Cache, commit. If you are not familiar with the buffer, you can also not record each change in the working directory. So you create a highly centralized commit, even if you've made a lot of changes locally.

git status # 查看仓库状态git add <some-file> # 缓存一个文件git commit # 提交一个文件</some-file>

Remember, these commands create a local commit, and John can repeat the process over and over, regardless of the central repository. This feature is useful for large functions that need to be cut into simpler, atomized fragments.

Mary is developing her features.

At the same time, Mary develops her features in her own local repository using the same editing/caching/submission process. Like John, she doesn't have to care about the progress of the Central warehouse , and she doesn't care about what John does in his own warehouse, because all the local warehouses are private.

John has released his features.

Once John has completed his function, he should publish the local submission to the central repository so that other project members can access it. He can use git push commands, just like:

git push origin master

Remember, origin it's the remote connection that John points to when he clones the central repository. masterparameter tells Git to try to origin master branch the master same as his local branch. The central warehouse has not progressed since John cloned, so this push, as he wished, did not create a conflict.

Mary is trying to publish her features

John has successfully posted his changes to the central repository to see what happens when Mary tries to push her functionality to the top. She can use the same push command:

git push origin master

However, her local history and central repository are forked, and Git rejects the request and displays a lengthy error message:

error: failed to push some refs to ‘/path/to/repo.git‘hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Merge the remote changes (e.g. ‘git pull‘)hint: before pushing again.hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.

git prevents Mary from overwriting official changes. She needs to pull the update from John to her warehouse, merge with her local modifications, and try again.

Mary on John's submission rebase

Mary can use it git pull to incorporate the upstream modifications into her warehouse. This command svn update is much like-it pulls the entire upstream commit history to Mary's local repository and integrates with her local submission:

git pull --rebase origin master

--rebaseOption tells Git to move all of Mary's commits to the top of the branch after synchronizing the changes to the central repository master , as shown in:

If you ignore this option, the pull will also succeed, except that you will have a "merge commit" every time you synchronize with the central repository. In this workflow, rebase is always a better choice than generating a merge submission.

Mary resolves a merge conflict

Rebase's job is to transfer each local commit to the updated master branch. In other words, you can resolve merge conflicts individually, rather than in a large merge submission. It will keep you focused on each commit and get a clean project history. On the other hand, you are more likely to find out where the bug was introduced and, if necessary, roll back the changes at the lowest cost.

If Mary and John develop features that are not associated, the rebase process is unlikely to conflict. However, if there is a conflict, git pauses rebase at the current commit, outputting the following information, and some related instructions:

CONFLICT (content): Merge conflict in <some-file>

The advantage of git is that everyone can solve their own merge conflicts. In this example, Mary git status can find out what the problem is just by running it. Conflicting files appear in the non-consolidated path:

# Unmerged paths:# (use "git reset HEAD <some-file>..." to unstage)# (use "git add/rm <some-file>..." as appropriate to mark resolution)## both modified: <some-file>

Next, modify the files. If she is satisfied with the result, cache the files as usual and then let git rebase the next work be done:

git add <some-file>git rebase --continue

That's it. Git will continue to check the next commit and repeat the process for conflicting commits.

If you find that you don't know what you've done, don't panic. Just run the following command, and you'll go back to the state before you started:

git rebase --abort

Mary successfully released her branch.

After she synchronizes with the Central warehouse, Mary can successfully post her changes:

git push origin master

What to do next

As you can see, it is also possible to replicate a set of traditional subversion development environments using a drop-and-drop git command. This is great for teams that have changed from SVN, but it doesn't take advantage of the nature of Git's distribution.

If your team is accustomed to a centralized workflow, but wants to improve collaboration efficiency, the benefits of exploring feature branching workflows are completely worth. Each feature is carried out on a dedicated independent branch, which enables in-depth discussions around the new changes before the code is incorporated into the official project.

Workflows for feature branches

Once you have mastered the use posture of a centralized workflow, adding a functional branch to your development process is an easy way to facilitate communication between collaboration and developers. This encapsulation allows multiple developers to focus on their functionality without disturbing the main codebase. It also guarantees that the master branch will never contain corrupt code, which is a great benefit to the continuous integration environment.

The development of the encapsulation function makes it possible to use pull request to start a discussion around a branch. It gives other developers the opportunity to participate in the decision before they are able to function and master the project. Or, if you're in the middle of developing a feature, you can start a pull request and ask a colleague for advice. The point is that pull request makes it very easy for your team to comment on other people's work.

How it works

The feature branch workflow also uses a central warehouse, which master also represents the official project history. However, instead of submitting the local master branch directly, the developer creates a new branch each time the new work is done. The feature branch should contain descriptive names, such as animated-menu-items (menu item animations) or issue-#1061 . Each branch should have a clear, highly focused purpose.

Git is technically indistinguishable master and functionally branching, so developers can edit, cache, and commit on feature branches just as they do in a centralized workflow.

In addition, the feature branch can (and should) be pushed to the central repository. This allows you to share this functionality with other developers without changing the official code. Since master it is only a "special" branch, storing multiple feature branches in a central warehouse does not elicit any problems. Of course, this is also a good way to back up each developer's local submissions.

Pull Request

In addition to isolating feature development, branching makes it possible to discuss changes through pull request. Once someone has completed a feature, they won't immediately incorporate it master . They push the feature branch to the central server and release a pull request to incorporate their modifications master . This gives other developers the opportunity to review before revising and taking to the code base.

Code reviews are the main benefits of pull request, but they are in fact designed to be a common place to discuss code. You can think of pull request as a discussion version that focuses on a branch. That means they can be used before the development process. For example, if a developer needs help with a feature, he simply initiates a pull request. The interested partner will automatically receive a notification to see the issue in the relevant submission.

Once pull request is accepted, the behavior of the release function is the same as the centralized workflow. First, make sure that your local master and upstream are master already synchronized. The feature branch is then incorporated master to push the updated master pushes back to the central warehouse.

Chestnuts

The following?? Demonstrates the pull request used by code review, but remember that pull request has multiple uses.

Mary has started a new feature

Before she started developing a feature, Mary needed a separate branch. She can create a new branch with the following command:

git checkout -b marys-feature master

A branch based on master , named, marys-feature will be checkout, and the -b tag tells Git to create it when the branch does not exist. On this branch, Mary edits, caches, commits changes as usual, and builds this feature with enough commits:

git statusgit add <some-file>git commit

Mary went to dinner.

Mary added some commits to her function in the morning. It's a good idea to push her branch to the central warehouse before she goes to lunch. This is a handy backup, but if Mary works with other developers, they can see her initial submission as well.

git push -u origin marys-feature

This command is marys-feature pushed to the central repository ( origin ), which -u marks the branch that added it as a remote trace. After the branch of the trace has been set up, Mary calls her function without any arguments git push to push her.

Mary has done her job.

When Mary came back after lunch, she finished her function. Before merging master , she needed to release a pull request to let other team members know what she was doing. But first, she should ensure that the central repository contains her latest submissions:

git push

Then she initiates a pull request on her git interface, the request is marys-feature merged master , and the team members receive automatic notifications. The benefit of pull request is that comments appear just below the relevant submission, making it easy to discuss specific changes.

Bill received pull request.

Bill received the pull request and reviewed it marys-feature . He decided to make minor changes before merging into the official project, communicating with Mary through pull request.

Mary made a change.

To make these changes, Mary repeats the same process that was created before, and she edits, caches, commits, pushes updates to the central repository. All of her activities are shown in pull request, and Bill can always comment.

If Bill wants to, he can pull it marys-feature to his own local warehouse and continue working. Any subsequent submissions will be displayed on the pull request.

Mary has released her features.

Once bill is ready to accept the pull request, someone (either bill or Mary) needs to incorporate the functionality into a stable project:

git checkout mastergit pullgit pull origin marys-featuregit push

First, regardless of who is performing the merge, make sure that their master branch is up to date. Then, run git pull origin marys-feature a copy of the consolidated Central Warehouse marys-feature . You can also use simple git merge marys-feature but previous commands to ensure that you pull down the latest version of the feature branch must be. Finally, the update master needs to be pushed back origin .

This process resulted in a merge submission. Some developers like it because it is a sign of functionality and the rest of the code merge. However, if you want to have a linear history, you can rebase the function to the top of the branch before executing the merge master , resulting in a quick forward merge.

Some interfaces automate the process of accepting pull request, just click on "Merge pull request". If you don't, it should be able to close the pull request automatically at least after the merge.

Meanwhile, John works the same way.

Mary and Bill were developed together, and marys-feature John was developing his own feature branch while discussing the pull request. By isolating features from different branches, everyone can work independently, but it's easy to share changes with other developers.

What to do next

To get a thorough understanding of the feature branches on GitHub, you should review the chapter using branching. Now you should have seen that functional branching greatly enhances the role of a single branch within a centralized workflow master . In addition, the feature branch facilitates the use of Pull request and discusses specific commits directly on the version control interface. Gitflow workflow is a common pattern for managing feature development, release readiness, and maintenance.

Gitflow Workflow

The following Gitflow Workflow section originates from the author Vincent Driessen on the Nvie website.

The Gitflow workflow defines a strict branching model around the project release. Some places are more complex than functional branching workflows, providing a robust framework for managing large projects.

This workflow does not add any new concepts or commands compared to the functional branching workflow. It assigns specific roles to different branches and defines how and when they should communicate. In addition to the feature branch, it also uses separate branches for preparing publications, maintaining publications, and documenting publications. Of course, you can also enjoy all the benefits of a functional branching workflow: Pull request, isolated experimentation, and more efficient collaboration.

How it works

The Gitflow workflow still uses the central repository as the center of Communication for developers. Like other workflows, developers work locally and push branches to a central repository. The only difference is the branching structure of the project.

History Branch

Unlike a separate master branch, this workflow uses two branches to record the project history. masterBranch stores the official release history of branches develop used to integrate functional branches. At the same time, this also facilitates the master release of all submissions on the branch to the version number label.

The remainder of the workflow revolves around the differences between the two branches.

Function Branch

Each new feature is placed in its own branch and can be pushed to the central repository when backing up/collaborating. However, instead of merging to master , the feature branch will develop the branch as the parent branch. When a feature is complete, it will be merged back develop . Functions should never master interact directly on the top.

Note that feature branching plus develop branching is what we talked about as functional branching workflows. However, the Gitflow workflow is more than that.

Publishing Branch

Once develop the new features of the branch are sufficient to publish (or the pre-determined release date is coming), you can fork from the develop branch to a publishing branch. The creation of this branch begins the next release cycle, and only tasks related to publishing should be done in this branch, such as fixing bugs, generating documents, and so on. Once the release is ready, the publishing branch is merged into the master label with the version number. In addition, it should be merged back develop , which may have made new progress after the launch.

Use a dedicated branch to prepare the release to ensure that one team is perfecting the current release, and that other teams can continue to develop the next release feature. It also establishes a clear development phase (for example, "We are going to release 4.0 releases this week" and we can see this in the structure of the warehouse).

Usually we agree:

• From develop creating a branch
• Merging into master branches
• Naming conventionsrelease-* or release/*

Maintenance Branch

Maintenance or "Emergency repair" branches are used to quickly patch the release of a product. This is the only branch that can be forked from the master top. Once the fix is complete, it should be merged master and develop branched (or the current release branch) and master should be labeled with the updated version number.

There is a dedicated bug fix development line that allows your team to handle issues without interrupting other workflows or waiting for the next release cycle. You can consider a maintenance branch as master a temporary publishing branch that works on a branch.

Chestnuts

The chestnuts below demonstrate how this workflow can be used to manage the release cycle. Let's say you've created a central repository.

Create a development Branch

The first step you have to make is to master create a complementary branch for the default branch develop . The simplest way is to create an empty develop branch locally and push it to the server:

git branch developgit push -u origin develop

This branch will contain all the history of the project and master will contain the incomplete version. Other developers should clone the central repository locally and create a branch to track the develop branch:

git clone ssh://[email protected]/path/to/repo.gitgit checkout -b develop origin/develop

Now everyone has a local copy of the history branch.

Mary and John started a new feature

Our chestnuts begin with the work of John and Mary on different branches. They all have to create separate branches for their own functions. Their functional branches should be based on develop , rather than master :

git checkout -b some-feature develop

They all use the general conventions of "edit, Cache, commit" to add commits to a feature branch:

git statusgit add <some-file>git commit

Mary has done her function.

After adding some commits, Mary is confident that she is functional and ready for the job. If her team uses pull request, it is now a good time to start pulling requests and request that her functionality be incorporated into the develop branch. Otherwise, she can merge it into a local develop branch and push it to the central repository as follows:

git pull origin developgit checkout developgit merge some-featuregit pushgit branch -d some-feature

The first command ensures that the branch is up to date before attempting to incorporate a feature branch develop . Note that functionality should never be directly incorporated master . Conflicts are handled the same way as a centralized workflow.

Mary starts preparing to publish

When John was still working on his functional branch, Mary began preparing for the first official release of the project. As with development features, she created a new branch to encapsulate the preparation of the release. This is also a step in the release version number creation:

git checkout -b release-0.1 develop

This branch is used to organize submissions, fully test, update documents, and prepare for upcoming releases. It's like a branch of functionality specifically designed to improve the release.

Once Mary creates this branch and pushes it to the central repository, the functionality of this release is locked. Features that are not develop in the branch are deferred to the next release cycle.

Mary finished her release.

Once the release is ready, Mary merges it into master and develop then deletes the publishing branch. Merging back develop is important because there may already be critical updates added to the publishing branch, and new features need to be developed. Similarly, if Mary's team values code review, it will now be the perfect time to launch the pull request.

git checkout mastergit merge release-0.1git pushgit checkout developgit merge release-0.1git pushgit branch -d release-0.1

The publishing branch is develop the transition phase between feature development () and public release (master). Whenever a submission is incorporated master , you should make a handy reference tag for the submission:

git tag -a 0.1 -m "Initial public release" mastergit push --tags

GIT provides a number of hooks, which are scripts that are executed when a particular event occurs in the warehouse. When you push master a branch or tag to a central warehouse, you can configure a hook to automate the build public release.

End user has found a bug

After the official release, Mary returned to work with John to develop features for the next release. At this point, an end user opened a issue complaining that there was a bug in the current release. To resolve this bug,mary (or John) from master Creating a maintenance branch, fix the issue with several commits, and then merge back directly master .

git checkout -b issue-#001 master# Fix the buggit checkout mastergit merge issue-#001git push

As with the publishing branch, the Maintenance branch contains the develop important updates that are needed in, so Mary also needs to perform this merge. Next, she can delete this branch:

git checkout developgit merge issue-#001git pushgit branch -d issue-#001

What to do next

Now, hopefully you're already familiar with the centralized workflow, feature branching workflow, and Gitflow workflow. You should already be able to catch the unlimited potential of local repositories, push/pull modes, and git robust branching and merging models.

Keep in mind that the workflow presented in the tutorial is only a viable practice-not the golden rule of working with Git. So, take the essence of it and go to its dregs. The constant is to make git work for you, not the other way around.

Fork Work Flow

The fork workflow differs from the other workflows discussed in the tutorial. Instead of using a unique server-side repository as a "central" codebase, it gives each developer a server-side repository. This means that each contributor has two git repositories instead of one: a private local repository and a public service-side repository.

The main advantage of the fork workflow is that contributions can be easily integrated into the project without requiring everyone to push to a single central repository. Developers are pushed to their own service-side repositories, and only project managers can be pushed to the official warehouses. This allows the manager to accept any developer's submissions without having to give them permission to the central repository.

The conclusion is that this distributed workflow provides a secure way of collaborating for large, organized teams, including untrusted third parties. It is also an ideal workflow for open source projects.

How it works

As with other git workflows, the fork workflow begins with an official public project stored on the server. But when new developers want to participate in the project, they don't clone the official project directly.

Instead, they fork an official project and create a copy on the server. This new copy is used as their private public repository-no other developers can push it, but they can pull the changes from above (we'll discuss why this is important later on). After they have created the server-side copy, the developer performs the git clone operation and copies a copy on their local machine. This is their private development environment, just as in other workflows.

When they are ready to publish a local submission, they will submit the commit to their own public repository--not the unofficial repository. They then launch a pull request to the main repository to let the project maintainers know that an update is ready to merge. Pull request can be used as a convenient discussion version if there is any problem with the contributed code.

In order to incorporate the functionality into the official code base, the maintainer pulls the contributor's changes to their local repository, ensures that the changes do not break the project, merges it into the local master branch, and master pushes the branch to the official repository on the server. Contributions are now part of the project, and other developers should pull and synchronize their local repositories from the official repositories.

Central Warehouse

It is important to understand that the concept of "official" warehouses is only a contract in the fork workflow. From a technical point of view, Git does not see the difference between a developer and an official public repository. In fact, the only official reason for official warehouses is that it is the repository for Project maintainers.

Forks in the fork workflow

The public repositories of all these individuals are just a convention to share branches between developers. Each person can still use the branch to isolate functionality, just as in the functional branching workflow and the Gitflow workflow. The only difference is how these branches start. In the fork workflow, they are pulled from another developer's local repository, and they are pushed to the official repository at the function branch and Gitflow branch.

Chestnut Project Maintainer initializes the central warehouse

As with any git-based project, the first step is to create an official repository on the server that can be accessed by all project members. In general, this warehouse is also a public repository for project maintainers.

The public repositories should always be bare, whether or not they represent the official code base. So the project maintainer should run the following command to set up the official repository:

ssh [email protected]git init --bare /path/to/repo.git

GitHub also provides a graphical interface to replace the above operation. This is exactly the same process as the other workflow settings Central warehouse in the tutorial. If necessary, the project maintainer should push the existing code base into the repository.

Developer Fork Warehouse

Next, all developers need to fork the official warehouse. You can use SSH to the server, run git clone it to copy it to the server another address--fork is actually only the service side clone. But again, on GitHub, developers can fork the warehouse with just a little bit of a button.

After this step, each developer should have their own service-side repository. Like the official warehouses, all these warehouses should be bare warehouses.

The developer clones the fork's warehouse to a local

Next, developers need to clone their own public repositories. They can use familiar git clone commands to complete this step.

Our chestnuts assume that they use GitHub to host warehouses. Remember, in this case, each developer should have their own GitHub account and should clone the server repository with the following command:

git clone https://[email protected]/user/repo.git

Other workflows in the tutorial use a single origin remote connection, point to the central warehouse, fork the workflow requires two remote connections, one is the central repository, and the other is the developer's personal service-side repository. You can give these remote names any name, and the Convention is to be origin used as the remote end of your fork (run git clone is automatically created) and upstream as an official project.

git remote add upstream https://github.com/maintainer/repo

You need to use the command above to create a remote connection to the upstream repository. It makes it easy to keep your local warehouses and official warehouses in sync. Note If your upstream repository is certified (for example, it does not have open source), you need to provide a username, like this:

git remote add upstream https://[email protected]/maintainer/repo.git

It requires the user to provide a valid password before cloning or pulling from the official code base.

Developers to develop their own

In their newly cloned local repository, developers can edit code, commit changes, and create branches as in other branches:

git checkout -b some-feature# 编辑代码git commit -a -m "Add first draft of some feature"

All of their changes are completely private until they are pushed to the public repository. Moreover, if the official projects have progressed forward, they can be used to git pull obtain new submissions:

git pull upstream master

Because developers should develop in specialized functional branches, this typically results in a quick forward merge.

Developers to post their features

Once developers are ready to share their new features, they need to do two things. First, they have to push the code of contribution to their own public repositories, which other developers will have access to. Their origin far end should have been set up, so they only need:

git push origin feature-branch

This differs from other workflows in that the origin remote point points to the developer's personal service-side repository instead of the master code base.

Second, they need to inform the project maintainers that they want to incorporate the functionality into the official code base. GitHub provides a "New pull Request" button that jumps to a Web page that lets you indicate the branch you want to take to the repository. In general, you want to incorporate functional branching into the branches of the upstream remote master .

Project Maintainers integrate their capabilities

When Project maintainers receive pull request, their job is to decide whether to incorporate it into the official code base. They can use one of the following two ways:

1. Check the code directly in pull request
2. Pull the code to the local warehouse and merge manually

The first option is simpler, allowing the maintainer to see the differences before and after the changes, commenting on them, and then performing the merge through the graphical interface. However, if pull request causes a merge conflict, the second option is necessary. In this case, the maintainer needs to fetch the function branch from the developer's server repository, merge it into their local master branch, and then resolve the conflict:

git fetch https://bitbucket.org/user/repo feature-branch# 检查修改git checkout mastergit merge FETCH_HEAD

Once the modification is integrated into the local master , the maintainer needs to push it to the official repository on the server so that other developers can access it:

git push origin master

Remember, defenders point to origin their public repositories, which are the official code repositories of the project. The developer's contribution is now fully integrated into the project.

Developers and central warehouses stay in sync

Because the main code base has made new progress, other developers should synchronize with the official repositories:

git pull upstream master

What to do next

If you are migrating from SVN, the fork workflow looks like a big change. But don't be afraid-it just introduces a layer of abstraction on top of the feature branching workflow. The contributed code is published to the developer on the server's own repository, rather than directly sharing the branch in the only central repository.

This article explains how a code contribution has flowed from one developer to the official master branch, but the same approach can be used to integrate code contributions into any repository. For example, if some of your team members collaborate on a specific feature, they can share the changes with their own agreed behavior-without changing the main repository.

This makes the fork workflow a very powerful tool for loose teams. Any developer can easily share changes with other developers, and any branch can be efficiently incorporated into the master code base.

This article is part of "Git-recipes" , click on the catalogue to view all chapters.

If you find the article helpful, please click Star or Forkin the top right corner.

If you find an error, or want to join a collaboration, see Wiki collaboration instructions.

Four Common Git workflow comparisons