Reputation: 181
I work for another project lately, including about 15 developers.
We use GitLab as our source control server.
What confused me is that we fork the original remote repo first, then clone the forked repo to local repo.
When we want to push some code, we push code to our own remote repo, then make a merge request to the original remote repo.
Why not just clone the remote repo to local repo directly?
I think a feature branch can also work. What's the difference?
Is there a standard?
========================================================================
origin remote repo -> own remote repo -> local repo
origin remote repo -> local repo
Upvotes: 0
Views: 230
Reputation: 488203
Why not just clone the remote repo to local repo directly?
You could indeed do that. But then how would you make a pull request?
Pull requests are not a Git feature. Instead, they are an add-on, provided by various web hosting providers such as Bitbucket and GitHub. (Compare with the email messages from git request-pull
; git request-pull
is a Git feature. You can run git request-pull
locally.
Note that because they are an add-on, each adder-on-er (is that an actual word?) may have a few tweaks of their own, that the other doesn't, but there's something pretty common here: A GitHub pull request can only be created using the GitHub web site. Unless you can write directly to the original GitHub repository, this requires creating a GitHub fork. A Bitbucket pull request can only be created using the Bitbucket web site. Unless you can write directly to the original Bitbucket repository, this requires creating a Bitbucket fork.
Assuming this pattern holds for GitLab—I have not used GitLab and can't say for sure, but it seems awfully likely—that would explain why you have to create a GitLab fork.
Upvotes: 1
Reputation: 142114
Why not just clone the remote repo to local repo directly?
Usually, a fork is used for the following purpose: (i don't know if it's your case or not, I can only assume)
Whenever you have your own repository in which you don't want others to "touch" the code directly but you still allow others to contribute or to fix bugs, you achieve it by a fork.
The original repository is a READ-ONLY for you since you are not a contributor, the fork, on the other hand, is under your account so you have full permissions to read/write.
On your fork, you develop your changes and when you are done you are "asking" the owner of the original repository to add (merge) your changes back to his repository, you do it using pull request.
This is the logic behind the fork.
In your case, I can only assume that the "main" repository need to be monitored for all changes, why? maybe it is the main repository for distribution, might be automation manipulating this repo, and so on.
To make it short - the fork is used when the original repo is read-only to you while allowing you to contribute back to it.
Upvotes: 1