What do these words mean in Git: Repository, fork, branch, clone, track?

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?

  • Rebasing a branch including all its children
  • Xcode 6.0.1 crashes when merging 2 branches
  • Make another branch default?
  • Safely delete a TFS branch project
  • Can I make fast forwarding be off by default in git?
  • Pull all commits from a branch, push specified commits to another
  • Git merge -s theirs: Simply?
  • Trouble merging upstream changes back into my branch
  • What to stage after a pre-commit hook was run?
  • Why does 'git merge' add files ending with tilde?
  • Git; code disappeared after merge
  • Git/SVN for asp.net development instead of VSS?
  • 3 Solutions collect form web for “What do these words mean in Git: Repository, fork, branch, clone, track?”

    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.

    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.”

    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.

    Git Baby is a git and github fan, let's start git clone.