Menu
I'm using several GitHub repositories. The procedure I've been using so far, is to fork the original repository, and then clone my branch. If I make some changes, I just push them into my remote branch.
My concern is: In the projects I probably won't make any modifications/commits, should I fork the original project and clone my branch, like I have done before, or clone the original one? And what if those projects involve a bunch of files which have to be customized (thus, my local project is different from the original one)?
804
It is a better option to fork before clone if the user is not declared as a contributor and it is a third-party repository (not of the organization). Forking is a concept while cloning is a process. Forking is just containing a separate copy of the repository and there is no command involved.
Developers who work on a shared codebase will want to clone a repository, while a fork will create an independent codebase that is completely separate from the original, forked repo.
Most commonly, forks are used to either propose changes to someone else's project to which you do not have write access, or to use someone else's project as a starting point for your own idea. You can fork a repository to create a copy of the repository and make changes without affecting the upstream repository.
Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.
It doesn't really matter.
If you think, you don't make any changes, you can safely clone the original repository directly, what has the benefit, that you can directly update your local clone via git pull. Once you realize you want to make changes you can fork it on github and add the fork as additional remote
On the other side if you think you will make changes to the remote you can fork it. Once you realized, that you were wrong and you don't need to make changes, add the original repository as remote and remove the fork.
I for myself prefer to always add both the fork and the original one as remote, thus I can update my local clone via (e.g.) git pull original master and after that I can update my fork with git push origin (origin is my private fork here. The names doesn't really matter too). If I don't need the fork or don't need it anymore, I get rid of it. If I need it (again), I (re-?)create it.
As a sidenote: You don't need a fork on github to make changes, because your local clone is a full repository too and if it's sufficient to keep your changes there, it's ok.
165
If you don't intend to make changes to code, clone but don't fork. Forking is intended to host the commits you make to code, while cloning is perfectly fine for copying the content and history of the project.
If you later change your mind and want to publish commits you made to the cloned repository, you can always fork and push your commits from your original clone to the forked repo, it's just a matter of adding your fork's URL to the repo's remotes.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
