5

I'm fairly new to GIT and I've been trying to find an answer to this question on the internet but so far haven't found anything that speaks to it.

If I understand correctly the purpose of forking a repo is to allow you to play with the code in preparation of making a pull request, and then to make a pull request in order to contribute to the project.

But many times authors have done a fantastic job of creating plug-and-play javascript resources. In those cases I just want to keep a clean, and current, copy available for projects.

Take for example Lea Verrou's prefixfree. This is a brilliant project written by someone who knows a lot more about the vendor prefix mess than I ever will. I'm honestly not likely to be able to contribute to the project.

In this case, is forking the best option or is there a better way to maintain concurrency and storage for downloads?

James A Mohler
  • 11,060
  • 15
  • 46
  • 72
Crispen Smith
  • 513
  • 4
  • 20

2 Answers2

18

You don't need to fork a project. To get the repository, you can just clone it.

Go to the project page on GitHub and use the project URL to clone it:

Github Clone

(clicking the copy to clipboard button, well, copies the URL to the clipboard)

Open git bash and navigate to your desired folder. Then run:

git clone <your clone URL>

which in your case it would be:

git clone https://github.com/LeaVerou/prefixfree.git

Whenever new updates arrive, you can just update your repository using:

git pull origin

If you don't want the entire project history and all you need is the latest snapshot of the source files, you can click the 'Download ZIP' button to download the source files as a zip archive.

You don't even need to have an account on GitHub to perform these tasks.

The "Fork me on GitHub" ribbon is only a sign that tells the world he is using GitHub for collaborations on the project. It just directs you to the project's page.

Mohammad Dehghan
  • 17,853
  • 3
  • 55
  • 72
  • Thank you! This makes a lot of sense and certainly is cleaner than forking every repo that I'm pulling from. If you are using resources from many origins will git pull origin get all of them? – Crispen Smith May 22 '13 at 14:48
  • What do you mean by "many origins"? Do you mean many *remotes*? **origin** is the default name that git gives to the remote that you cloned the project from. See [here](http://git-scm.com/book/en/Git-Basics-Working-with-Remotes) and [here](http://gitref.org/remotes/) for more information on remotes. – Mohammad Dehghan May 22 '13 at 15:20
  • Okay, I think I've got it. So test my understanding, if a project needs reop1, repo2 and repo3 I would do: $ git remote add repo1 [url], $ git remote add repo2 [url] and $ git remote add repo3 [url]. Then periodically (or as needed) I would do $ git pull repo1, $git pull repo2 and $ git pull repo3? – Crispen Smith May 22 '13 at 18:27
  • 1
    @CrispenSmith Yep! :) After 6 years!! :D – Mohammad Dehghan Jan 28 '20 at 07:30
6

On git a project can be forked to:

  • create a new repo containing features that will be eventually pulled into the main repo; this is the common usage in the Linux kernel, where each subtree maintainer keeps his own repo (periodically pulled by Linus Torvalds)

  • create a repo containing some difference with respect to the original project, to offer some extra functionality or a different configuration that are not meant to go upstream.

Claudio
  • 10,614
  • 4
  • 31
  • 71
  • This is fantastic insight, thank you. However as MD.Unicorn had provided a specific better alternative to forking I have to accept his answer. I really appreciate that you took the time to add this level of detail to the understanding of the answer. – Crispen Smith May 22 '13 at 14:46