130

I'm honestly not clear on the semantics here. They're all about copies/variants of a code+history unit, but past that I'm not sure I could say. Is this logical structure explained somewhere?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Eric Anderson
  • 1,968
  • 2
  • 15
  • 19
  • 5
    I would recommend reading the first couple chapters of the Pro Git book (http://progit.org/book/). – ewall May 26 '10 at 21:15
  • 61
    +1. A lot of the git tutorials show you how to perform certain tasks without explaining what certain words mean or how git works. Asking for a resource that addresses those topic is a legitimate question. – Daniel Stutzbach May 26 '10 at 21:36
  • 14
    Wish I could +1 Daniel's comment more. While the meaning of some of the terms (e.g. repository) should be obvious, their relationship isn't always (branch vs. fork), and the real meaning is easily misinterpreted by someone used to a centralized VCS. Besides, look at Pro Git's "what is a branch?" section - does a basic user really want to know about blobs and trees, or do they just want to know qualitatively what a branch is? – Cascabel May 27 '10 at 12:27
  • 1
    @DanielStutzbach it is possible to submit comments about things that are not clear in the book. (I don't know the correct terminology to say that.) I have done that, I have said that the book needs to define what a repository is. I agree that it is quite difficult to get conceptual material from people that understand something very well. That book (currently) talks about databases without defining what they are in this context and says nothing about what repositories are. – Sam Hobbs Nov 02 '18 at 23:20

3 Answers3

147

A repository is simply a place where the history of your work is stored. It often lives in a .git subdirectory of your working copy - a copy of the most recent state of the files you're working on.

To fork a project (take the source from someone's repository at certain point in time, and apply your own diverging changes to it), you would clone the remote repository to create a copy of it, then do your own work in your local repository and commit changes.

Within a repository you have branches, which are effectively forks within your own repository. Your branches will have an ancestor commit in your repository, and will diverge from that commit with your changes. You can later merge your branch changes. Branches let you work on multiple disparate features at once.

You can also track individual branches in remote repositories. This allows you to pull in changes from another individual's branches and to merge them into a branch of your own. This may be useful if you and a friend are working on a new feature together.

There are lots of great git books online. Have a look at ProGit and Git Magic to get started, as well as the official tutorials and community book.

twasbrillig
  • 17,084
  • 9
  • 43
  • 67
nfm
  • 19,689
  • 15
  • 60
  • 90
  • Of course reading the F manuals and tutorials is fundamental. But this seems to me a great summary of the whole stuff. Much appreciated! – brasofilo Jun 02 '12 at 11:29
  • Note that you can switch your local working directory to a new branch ("git checkout "). In this case, the files of your local working directory are REPLACED by the content of branch you're switching to. But you don't loose your work: Git stores all the commited changes ("git commit") you made on the previous branch in the Git "database" (hidden .git folder) and will let you switch back your files. – KrisWebDev Jun 24 '13 at 12:57
  • 3
    I think it requires special mention that historically, regardless of which VCS you used, forking and branching were considered two separate things. Branching was considered favorable and implied agreement between developers. Forking was more serious as it implied that the developers working on a project did not agree on some things and decided to part ways. Successful forks then were typically merged back into one project later after both sides came to an agreement. Since then, Git (and GitHub) have blurred these terms and both terms basically represent the same idea but in different ways. – redteam316 Jan 27 '14 at 14:39
  • So a repository does not have the files for the project in it? You say _a place where the history of your work is stored_. Is that all? Just the history of files but not the files themselves? – Sam Hobbs Nov 02 '18 at 23:27
13

I'm going to answer my own question with an RTFM.

But, read this fine manual. As the author puts it:

“The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

“Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.”

Community
  • 1
  • 1
Eric Anderson
  • 1,968
  • 2
  • 15
  • 19
  • This introduction seems to have been moved to http://www.sbf5.com/~cduan/technical/git/. The original URL still works for now. – Eric Anderson Jun 12 '12 at 15:19
  • 1
    This is true within context. If you need to be productive right away or really just check code in, its okay not to have a deep understanding of how git works. The tutorials are fine. This is how I got into git. However, if or when you need to be more advanced like create branches, fork, rebase, and other more advanced tasks, then you have to know how git works, especially if you your background is in a centralized source control. – Phil Oct 29 '15 at 17:29
3

This GoogleTechTalk is a fantastic introduction to Git to learn what is actually happening behind the scenes while learning the language also. It was given by a very early contributor to Git and he gave this talk in 2007 as a way of introduction into Git. If you watch this talk you will not only know what each word is, like repository, fork, branch, etc., but you will also know what is occurring behind the scenes when each of these are made, merged, etc.

The address is long but very informative. It also contrasts Git to other Version Control Systems so you get insight into why Git was created the way it was and what the comparative advantages of it are over other control systems. Even though the talk is old it is very helpful to get up and running. I would watch this before I jumped into the manuals. Things will make much more sense as a result, I believe.

Matt
  • 381
  • 4
  • 13