ext each developer needs to clone their own public repository. They can do with the familiar git clone command.
Our example assumes the use of Bitbucket to host these repositories. Remember, in this situation, each developer should have their own Bitbucket account and they should clone their server-side repository using:
\ngit clone https://user@bitbucket.org/user/repo.gitWhereas the other workflows in this tutorial use a single originremote that points to the central repository, the Forking Workflow requires two remotes—one for the official repository, and one for the developer’s personal server-side repository. While you can call these remotes anything you want, a common convention is to use originas the remote for your forked repository (this will be created automatically when you run git clone) and upstream for the official repository.
git remote add upstream https://bitbucket.org/maintainer/repoYou’ll need to create the upstream remote yourself using the above command. This will let you easily keep your local repository up-to-date as the official project progresses. Note that if your upstream repository has authentication enabled (i.e., it‘s not open source), you’ll need to supply a username, like so:
\ngit remote add upstream https://user@bitbucket.org/maintainer/repo.gitThis requires users to supply a valid password before cloning or pulling from the official codebase.
\nDevelopers work on their features
\n\n
![\"Forking](\"https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/forking-workflow/05.svg\")
\n
In the local repositories that they just cloned, developers can edit code, commit changes, and create branches just like they did in the other workflows:
\ngit checkout -b some-feature\n# Edit some code\ngit commit -a -m \"Add first draft of some feature\"All of their changes will be entirely private until they push it to their public repository. And, if the official project has moved forward, they can access new commits with git pull:
git pull upstream masterSince developers should be working in a dedicated feature branch, this should generally result in a fast-forward merge.
\nDevelopers publish their features
\n\n
![\"Forking](\"https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/forking-workflow/06.svg\")
\n
Once a developer is ready to share their new feature, they need to do two things. First, they have to make their contribution accessible to other developers by pushing it to their public repository. Their originremote should already be set up, so all they should have to do is the following:
git push origin feature-branchThis diverges from the other workflows in that the origin remote points to the developer’s personal server-side repository, not the main codebase.
Second, they need to notify the project maintainer that they want to merge their feature into the official codebase. Bitbucket provides a “Pull request” button that leads to a form asking you to specify which branch you want to merge into the official repository. Typically, you’ll want to integrate your feature branch into the upstream remote’s master branch.
The project maintainer integrates their features
\n\n
![\"Forking](\"https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/forking-workflow/07.svg\")
\n
When the project maintainer receives the pull request, their job is to decide whether or not to integrate it into the official codebase. They can do this in one of two ways:
\n- \n
- \n
Inspect the code directly in the pull request
\n \n - \n
Pull the code into their local repository and manually merge it
\n \n
The first option is simpler, as it lets the maintainer view a diff of the changes, comment on it, and perform the merge via a graphical user interface. However, the second option is necessary if the pull request results in a merge conflict. In this case, the maintainer needs to fetchthe feature branch from the developer’s server-side repository, merge it into their local master branch, and resolve any conflicts:
git fetch https://bitbucket.org/user/repo feature-branch\n# Inspect the changes\ngit checkout master\ngit merge FETCH_HEADOnce the changes are integrated into their 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 masterRemember that the maintainer's origin points to their public repository, which also serves as the official codebase for the project. The developer's contribution is now fully integrated into the project.
Developers synchronize with the official repository
\n\n
![\"Forking](\"https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/forking-workflow/08.svg\")
\n
Since the main codebase has moved forward, other developers should synchronize with the official repository:
\ngit pull upstream masterWhere To Go From Here
\nIf you’re coming from an SVN background, the Forking Workflow may seem like a radical paradigm shift. But don’t be afraid—all it’s really doing is introducing another level of abstraction on top of the Feature Branch Workflow. Instead of sharing branches directly though a single central repository, contributions are published to a server-side repository dedicated to the originating developer.
\nThis article explained how a contribution flows from one developer into the official master branch, but the same methodology can be used to integrate a contribution into any repository. For example, if one part of your team is collaborating on a particular feature, they can share changes amongst themselves in the exact same manner—without touching the main repository.
This makes the Forking Workflow a very powerful tool for loosely-knit teams. Any developer can easily share changes with any other developer, and any branch can be efficiently merged into the official codebase.
\n