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?

  • committing to the same branch with git
  • Merging branch to multiple branches in Git
  • Is they a way to set push.default to `current` only for the current push
  • How to share a large git merge amongst team members
  • Difference in GIT betw. branch, clone and snapshot
  • TFS Branching & Merging Strategies
  • Heroku deployment with active_admin
  • Is there any way to semi-automatically commit?
  • Is there a way to get a `git diff`, but only include commits from a specified committer?
  • Staging again files during pre-commit hook?
  • How to make Git honor a cancelled merge that was not asked for?
  • Git - Best practice: How to switch very often between branches and avoid multiples commits?
  • 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.