Lee and his developers have the repository set up much like the following:
All developers have write access to the repository, so they are all able to branch from it directly, then make, commit, and push changes back to the repository.
We on the other hand do not have write access. What we can do however is
fork the repository. This is nothing more than creating another online copy of the repository.
Lee's TheComet's
Repository -------- fork --------> Repository
|
|
branch
|
|
v
TheComet's
Computer
(local copy)
This allows me to clone my copy of the repository and check out a branch on my local computer. Because the branch is tracking my repository and not Lee's repository, I have writing permission and can push changes.
When I've finished my modifications to DBP, I can initiate a
merge request. Someone on the DBP team who has writing access to Lee's repository will then clone the changes from my repository, and if everything looks alright, he will push the changes to Lee's repository:
Lee's TheComet's
Repository Repository
^ . |
| . |
| . branch
| . |
| . |
| . v
Lee's TheComet's
Computer Computer
(local copy) (local copy)
There can of course be more than one fork of Lee's repository. This is what's known as a
distributed workflow.