3

I'm pretty new to programming but I feel I'm getting the hang of it and I'm trying to learn as much as I can. I keep reading that Git is absolutely vital to a programming project, but I can't seem to figure out what it actually does. Google doesn't want to tell me either. The website says it is "a distributed version control system." Er... huh?

Could someone please explain to the neophyte what this thing is and why it's so vital?

Spanner
  • 73
  • 2
  • 1
    On the DVCS front: http://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917 and http://stackoverflow.com/questions/2704996/describe-your-workflow-of-using-version-control-vcs-or-dvcs – VonC Dec 06 '10 at 17:02
  • This should not be a StackOverflow question, it should be a search engine query – Dan Grossman Dec 07 '10 at 01:33
  • @Dan: I personally disagree, but once you reach the necessary reputation, you're welcome to vote to close it as "not a real question" for that reason. I still don't think you need to post a less helpful answer in order to prove that point, though. – Cascabel Dec 07 '10 at 02:52
  • http://en.wikipedia.org/wiki/Revision_control – Dan Grossman Dec 06 '10 at 15:45

5 Answers5

5

The website says it is "a distributed version control system."

Let's start with the idea of a version control system. It's exactly what it says - it's a way to store and manage various versions of something. This is extremely important in programming, because a project is going to be changed many, many times as you develop it, and it will frequently be useful to have access to more than the current version. It's also going to be changed by multiple people; there has to be some way to combine everyone's changes.

The simplest possible version control would be to simply back up your entire project now and then, and pass either these snapshots or patches around between various developers. Obviously you would start running into difficulties eventually with such a naive approach; that's where dedicated version control systems come in.

A version control system will keep track of all of your history in an intelligent way, and allow you to browse that history, seeing everything about the changes: what they were, who made them, and why. Slightly more complex, they'll often have some notion of branching (creating divergent lines of development, perhaps for multiple developers) and merging (bringing those branches back together). Most version control systems will provide a lot of higher-level functionality on top of all this too. Just for a single example, git has a tool called "bisect" which will let you do a binary search through your history to find when a particular bug was introduced. Neat stuff.

There are two broad classifications of version control: centralized and distributed. In a centralized system, there is one central repository. It contains all of the history of the project, and anyone who wants to interact with that history has to go through that central repository. A distributed system like git, on the other hand, gives everyone that history. Each developer will end up with a copy (called a clone, in git) of the repository, which is completely self-sufficient. There's no need to interact with a public central repository except as a practical matter, a way of publishing content for others to see. This makes it much simpler for multiple people to work on the same project at the same time, possibly without having internet access, and also gives each of those people the full power of the version control system within their own repository, instead of the limited public functionality of the central repository.

For a great qualitative read on how you'd end up with a system like git, starting from the basics of wanting to remember history, try the git parable.

For more general information on the topic, try wikipedia: revision control.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • Tom compliment this excellent article I'd also recommend the opening chapter of http://progit.org/book/ch1-1.html – Dan Diplo May 11 '11 at 16:31
3

Git is backup. Backup is a concept that should be familiar to everyone who uses computers -- backup is safety for your data. Git is backup for your thoughts. (The usual caveats apply to both backups and Git -- if you don't know that it works, and that you can use it effectively, then it's as good as useless.)

Git is a revision control system - it manages patches or changesets between different versions of the same file. It might be easiest to think about it as an alternative to having four files in a folder named my_file, my_file_test, my_file_test2 and my_file_retired20030411 along with a file called my_file_changes.log where you record what changed between each of the four versions of the file, and why you changed them. (Though Git is much more than this.)

Git is the enabler of the principle of subsidiarity in software development. It enables changes to made by multiple people to the same file at the same time and for those people to collaborate with each other effectively (eliminating the need for tedious hours to be spent pouring over code just to make sure that you can merge the two versions together without overwriting each others changes.)

And Git is even more than that ...

Sean Vieira
  • 155,703
  • 32
  • 311
  • 293
1

Start at Wikipedia: git.

Basically version control systems help you manage and organise software projects, by tracking the various files. They allow you to "step backwards in time" and retreive on-demand any older version of a file, create multiple parallel "branches" for things like bug fixing, feature development, and so on.

They're awesome, and git seems to be an awesome example of a version control system.

unwind
  • 391,730
  • 64
  • 469
  • 606
1

There is an introduction to Git for neophyte here:

http://articles.sitepoint.com/article/version-control-git

CharlesB
  • 86,532
  • 28
  • 194
  • 218
1

watch what Linus Torvald has to say about git in a savvy talk (Google Tech Talks series)

this is so Linus: "I am a very cynical and untrusting person, I think most of you are completely incompetent." - to a room full of Googlers

matcheek
  • 4,887
  • 9
  • 42
  • 73
  • What I hate about that talk is the implication that git is a distributed VCS and thus it is not a centralized VCS -- i.e. that *the* git workflow is totally distributed. Of course that's not true at all. You can easily have a single git repo that is your centralized one, and several others that all push to it. Just want to point that out since this question is for git newbies. – Tyler Dec 07 '10 at 07:58