In this post I’m going to write about the fork-clone-pull that we’ve been using for some time now at work.
And why do that?
- You don’t need to give everyone write access to the central repository
- It keeps the central repository “clean” (arguable..) by not polluting it with developers' feature branches
- Developers can form subteams (by adding other dev’s clone as a
remote) (useful for collaborating, pair-programming etc.)
- Enforce review guidelines by limiting direct write access
- Very useful for remote teams (personal experience..)
Convinced? nice! read ahead to know more about how to implement..
- Organsiation admins  (or users with write access) start by creating the central repository (the
- Members than fork the upstream under their own account (the
originfor that dev)
- The developers than start by cloning their respective
origin(each dev has complete access over their forks) and add the upstream remote
git clone [email protected]:user/repo git remote add upstream [email protected]:organisation/repo
- One can then follow the git branching workflow that they are already familiar with.
git checkout -b feature/the-next-big-stuff
- Once they’ve started working on the feature, they can push it up to their fork.
git push -u origin HEAD
- Once they’ve pushed the code to
origin, they can then open a Pull Request to the
upstreamwhere the project owner / maintainer can review the code and merge it (or suggest any changes)
Keeping the code in sync
When multiple developers are working on a project it’s very likely that the
upstream would move much faster than the devs'
origin. In that case, the dev would need to periodically (ideally, they should do it daily) sync their
To do that, devs need to execute following (on their local machine) -
# fetch upstream and all branches > git fetch upstream # checkout local or own develop > git checkout develop # get the changes from the upstream and merge to your local. > git merge upstream/develop # push the code to the develop branch of your fork > git push origin develop
The devs should also execute ☝️ once they’ve their PR merged.
And that’s it! you’ve got a scalable git workflow model that would work well even for remote teams (we’ve used it quite extensively!)..
And just to make it clear.. we are not the first ones who’ve used this or anything like that 😛.. this flow is used extensively in open-source world where generally there is a central
upstream canonical repository (where all issues are made and project is released) and each contributor has his/her own “fork” of that repository. The beauty of this flow is that it scales so well even for a highly distributed open source project!