What are the core concepts of git, github, fork & branch. How does git compare to SVN?

Question

I\'ve been using Github for sometime now but I\'m getting a bit confused about some key concepts behind Git.

My background with VCS started with Source Safe and then

Answer 1

Unlike CVS and SVN which are file based, Git is commit based. The commits live in the repository as a tree of commits. There are 3 main sections to a git repository, the working directory the stage and the repository directory.

Git has no binding concept of a central repository. Every clone of a repository holds the full history of commit and commits of the repository it copied.

A fork is merely a clone or copy of another repository. The changes you make on your copy of the repository will not affect the repository that was forked (clone). To apply your changes on the original repository you would need to 'push' them or have the repository owner 'pull' any new commits you have added. Likewise others fork your fork (i.e. make a copy of your copy). And, any changes to their repository will not affect your repository unless you pull those changes in.

Git is an amazing tool. It serves not just as a way to version control work, but also makes collaboration and experimentation a lot easier. And there is so much more too it.

I highly recommend ProGit Book to help you get more acquainted with how and what Git is about.

Answer 2

Tinkertoys, the perfect modelling tool for a Directed Acyclic Graph Node

Git For Ages 4 And Up is a fun talk on Git and provides surprisingly useful visualizations using Tinkertoys.

Answer 3

Here's how to understand Git:

1. Forget everything you know about other VCSs (temporarily!)
2. Read The Git Parable. Really read it though, if you skim, you'll miss stuff and just try to fill in the gaps with your existing SCM knowledge, which is what's throwing you off. In fact, if you really want to understand, read that blog post aloud.

At its core, Git is just a way to save and restore snapshots. Each snapshot has an "ID" (the SHA1), and may have one or more "refs" (pointers) to it. A branch? Just a friendlier name for a particular snapshot. Tags? Same thing. HEAD? That's just a "pronoun" for the current snapshot. Conveniently, these snapshots each come with a description of what changed - this description is the commit message.

Answer 4

There is a nice talk about the internals of Git by Scott Chacon.

A slideshow with voiceover: http://blip.tv/scott-chacon/git-talk-4113729
The slides again: http://www.slideshare.net/chacon/getting-git
A live recording of the talk: http://vimeo.com/1099027

Answer 5

Git is a DVCS (Distributed Version Control system)

Git (locally) has a directory (.git/) at the project root to which you commit your files.

Git is a DVCS (Distributed Version Control sytem) that enables you to save copies ('versions') of files frequently with the ability to merge work done by more than 1 person and you also have the ability to work offline.

Git differs from more traditional CVS (Code Versioning Systems) like SVN (Subversion) or CVS which do have branches, but no 'local and remote' concept (your commits are directly to the remote). With git you commit to your local repository first and then push those changes to the remote. This encourages more frequent commit and work being done in smaller chunks. It also support off-line work much better as you can commit while offline and then sync and pull/push when next online.

Git stores each change to a file by saving the entire file. It's different from svn in that respect and you can go to any individual version without 'recreating' it through delta changes.

Git doesn't 'lock' files and require exclusive lock for an edit (older systems like pvcs come to mind). It actually does an amazing job of merging file change (within the same file!) together during pulls or fetches. The only time you need to do a manual change is if two changes involve the same line(s) of code.

---

Branches

This is when you want to preserve the main code, make a copy (branch) and then work within that branch. When you've finished you merge the branch back in to the master repository. One example of this might be if you are working on an upgrade to a new version.
Some shops and individuals do all work, whether its a feature, bug fix or chore, in separate branches, with a separate process and/or designated person to merge these branches into master.
So with a branch you are managing the branch, whereas with a fork someone else controls accepting the code back in. That's the standard usage anyway.

Github

github (a remote) is a remote source that you normally push and pull those committed changes to if you have (or are added to) such a repository.
So local and remote are actually quite distinct.

When you 'fork',, i.e click on - , say on github, you create a copy of the code in your github account. It can be a little subtle first time you do it, so keep making sure you look at whose repository a code base is listed under - either the original owner or 'forked from' and you, e.g.

Once you have the local copy, you can make changes as you wish (by pulling and pushing them to a local machine). When you are done then you submit a 'pull request' top the original repository owner/admin (sounds fancy but actually you just click on this:- )and they 'pull' it in.

Cloning

More common for a team working on code together is to 'clone' the repository (click on the 'copy' icon on the repository's main screen). Then, locally type git clone [paste] This will set you up locally and you can push and pull directly to the shared github location.

Visualization

I don't have a visualization of the core concepts, but if you want to see how the changes are working, you can't beat the visual tool gitg (gitx for mac) with a gui that I call 'the subway map' (esp. London Underground), great for showing who did what, how things changes, diverged and merged, etc. You can also use it to commit and manage your local changes...