Git concepts simplified

by whiteshadow • 13 years ago

244 141 13 years ago

dcre4• 13 years ago

I love Git, but I'm pretty sure there's no way to explain it simply.

jordigh• 13 years ago

I have a much easier time explaining Mercurial. And I will keep using Mercurial and keep improving Mercurial until we all realise how much better it is than git because it's easier to explain, it's just as fast, and no less powerful.

jlgreco14• 13 years ago

I don't get this attitude. The DAG is exceedingly simple and I think can be taught reasonably in only a few minutes. From there you really only need to teach a very minor amount of the UI, and teach the user how to perform "I want to do this to the DAG"=>"This is what I type" translations on their own. I've seen all of this done well in sub-hour presentations.

Mercurial on the other hand has a pain in the ass datamodel (so much so that most introductions to it that I have seen do not even approach the topic), so you actually do have to learn all of the UI commands to get an idea of what can be done and what cannot be done. It is far more complex than git.

I really cannot think of a simpler VCS than git. I've used plenty, but never got off the ground faster with anything else.

volaski• 13 years ago

Git is simpler than any other VCS, but VCS itself is not simple concept to understand. That's what he's saying, and I agree. I use git all the time, but it's not easy to understand the whole version control thing as a beginner. Also Git is not just about DAG, you need to be able to understand the decentralized nature, etc. In that sense, some people may find SVN easier to understand.

damncabbage• 13 years ago

I agree with the model being great. The git command itself is abominably baroque in its user interface (inconsistencies and strange defaults abound), but I've gotten over that with more effort than I'd like to admit.

I love Git's plumbing; I just hate its porcelain.

jeltz2• 13 years ago

As soon as you understand that git is just a DAG then it becomes simpler to understand and reason about than any other VCS I have used.

ezquerra• 13 years ago

I find that your comment about mercurial's data model a bit ridiculous.

The reason why most introductions to mercurial do not mention its data model is because it is _not_ important. You really do not need to care about it at all on your day to day use. I've been using mercurial for years and I've never had to ask myself what is mercurial's data model.

IMHO the reason why git forces you to understand its data model is because its UI is terrible. It is a failure of the tool when you need to understand how it works internally to use it. If git's UI were better its awesome data model would be something that only git devs would need to understand.

jheriko2• 13 years ago

really? its not that complicated, it just has lots of bad defaults in my experience

(i use mercurial when i start new projects, not because its fundamentally better - but because it has sensible defaults and i don't need to configure it our get bitten by gotcha x for the nth time - e.g. i can revert a merge without reading a document or configuring anything - a vital feature of source control imo)

ulisesrmzroche• 13 years ago

There's a tree with branches and that's about it.

aeon10• 13 years ago

There seems to be ALOT of 'Git Explained' stuff. The best way to learn Git in my opinion is start using it! Google stuff as you go.

recursive2• 13 years ago

I thought I would try that, but I'm probably still not really thinking in Git. I never branch or merge for example, since I never think of doing that. I understand this isn't really normal git usage.

dsego• 13 years ago

Me neither. But I think I should. Every time I want to try something new, take a new direction in code or add a new feature I should branch, so I can safely add or remove pieces of code. Things not related to that new feature, like bug-fixes, should be done in the main branch and then get pulled into the feature branch. I'm just too messy with my commits to do that, because it requires making frequent smaller commits, instead of huge ones once in a while.

develop74• 13 years ago

Google stuff as you go.

Are you implying git man pages are useless to newcomer?

th3dude• 13 years ago

Useless? No. Overwhelming at times? Absolutely.

I think that Google is probably the best way to go, because not only will you get the man pages as high ranking hits, but you'll also get great hits from sites like StackOverflow and blogs that can explain things better.

zwieback• 13 years ago

True, but even after travelling along the RCS->VSS->CVS->SVN graph for the past 20 years I still find git baffling sometimes. I like it but the question is whether I want to invest my brain resources, which are a scarce resource at age 47, in learning a revision control system that can drive you into a cul-de-sac when using even the most basic workflow.

I think git!=simple but I applaud the effort.

MBCook9• 13 years ago

The model behind Git, the way the repository works/conceptual model, is incredibly simple. The only trick is learning which commands are used to make the changes you want, and that can take a little time (and Googling).

tekp2• 13 years ago

I was expecting this: http://tartley.com/?p=1267

octo_t• 13 years ago

thats my favourite ever git article.

nilkn2• 13 years ago

I really did not expect that. That's one of the best unexpected funny things I've experienced this week. I don't think I would have found it as funny if I had stumbled on it randomly; the discussions here provided the perfect context for this link.

tootie4• 13 years ago

There is an inverse relationship the number articles title "x explained simply" and the actual simplicity of x. I honestly don't understand why the developer community refuses to admit the obvious that git is unholy clusterfuck of a product. It has a nice data structure inside it? Name another end-user product for which you are even vaguely aware of what data structures were used.

angdis• 13 years ago

I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow).

When authors try to explain how to use git, they often have a very particular workflow in mind and don't necessarily describe exactly what that workflow is. This can cause major problems when somebody tries to apply advice to their own workflow.

I like the graphical approach. It helps to conceptualize what is going on so that someone can apply it to their own situation.

tootie4• 13 years ago

That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly more complexity.

jlgreco14• 13 years ago

Name another end-user product for which you are even vaguely aware of what data structures were used.

Unix.

You are operating primarily on a tree of files and streams of text. To operate on these you have a wide array of utilities that perform simple tasks (and a handful that perform complex tasks as well) that, when composed, allow you to perform any transformation you want. You can get a freshman CS student off the ground with Unix like systems in what, one lecture?

Because the (bleedingly simple) data model is the focus when learning Unix, you don't need to memorize every single little edgecase of the system. Knowledge of the data model alone is enough to tell you what sort of things can or cannot be done, and general knowledge of the sort of thing that a few utilities do is enough bootstrap yourself. If you want to list out some files in some particular way, you may not know immediately what exactly to type, but you probably do know that ls or find is a decent place to start looking.

piratebroadcast• 13 years ago

Git and Linux were both invented by Linus Torvalds.

pjmlp2• 13 years ago

Except there isn't a single version of UNIX, each flavour has its own deviations.

VeejayRampay2• 13 years ago

Word. I have a theory that while git has completely taken over the software industry and most users can "get shit done" with it, very few of them actually understand what the fuck is going on. All those "simple explanations" are really nice theoretical pieces about the merits and design of git itself and most of the time tend to completely ignore (or dodge) the clusterfuck that every day git can be, especially for people starting up with it.

I'm talking about the botched merges, the hour-long rebases with 156 git rebase --skip, the "your branches have diverged" mysteries, the subtle differences between fetch and pull, the fact that all the GUI I've seen so far, far from being a tool, are actually complicating the task with their own little syntax.

If the underlying data structure is so beautiful, then how come there's no UI where I can simply drag branches around, have an actual "OOPS, MISTAKE, LET ME UNDO" button, reorder my commits with the mouse, something that holds my hand and actually cares about ALL git users, not the 1% connoisseur elite?

Don't get me wrong, I have zero doubt that git is in fact an absolutely great tool with a very intelligent design and that the users are to blame for not understanding it, I'm just thinking that if after more than 5 years of git-as-a-dominant-dvcs I keep seeing the same puzzled faces looking at a series of SHA-1 like it's the answer to the universe over and over again, there's something that's not quite right.

That being said, this is indeed one of the most comprehensive articles I've ever read about git.

EdwardDiego4• 13 years ago

the subtle differences between fetch and pull

While I agree with some of your criticisms, as the resident 'Git guy', I've found no difficulty in explaining to people that pull is a convenience alias for 'fetch followed by merge'.

mden• 13 years ago

I think in many ways it comes down to the way people think about and use the product. For me svn and perforce are way more of unholy messes than git is and I find them considerably more frustrating to use.

davvolun• 13 years ago

That argument doesn't really make sense. If x were fundamentally simple, why would I need a simple explanation for it? Clearly git is, or can be, complex, and a simple, simpler or simplified explication would be helpful.

None of that implies that "git is [an] unholy clusterfuck of a product," it means that git is complicated. For 99% of the work you do with git, it isn't even that complicated and you don't need to be aware of the data structure. As for the last 1%, well, that's what separates git from other (D)VCSs. Git gives me the power to do a lot, and incidentally, it gives me the power to shoot my foot off too...I still prefer it over say svn or hg, my personal opinion.

jlgreco14• 13 years ago

It is simple because a simple explanation is possible. Simple doesn't mean "intuitive to proverbial grandmother".

Git is clever, moderately novel and therefore unfamiliar (depending on your background), and simple. There are not many concepts present, and the concepts that are there are not difficult to understand, but those concepts need brief introduction because they are concepts that many will be unfamiliar with.

If you buy a checkers board it will come with a (very simple) rulebook. You aren't born with some sort of natural checkers ability, you have to learn it. Nobody would claim that checkers isn't simple though.

stephengillie• 13 years ago

After reading the post (and many others), I think I'm starting to get it:

-You have a directory/folder (data store) where all of the files are stored

-Some files (blobs) are data files

-Some files (trees) are hierarchy - they specify the structure of the data (blob) files, and how they connect to each other (like a database)

-Some files (commits) are snapshots (think VM snapshot) of the arrangement of the blobs on the trees (data file structure)

-Some files (tags) hold metadata about the data files (blobs)

And it's all tied together by SHAs (GUIDs) which are just a random number that's so huge it's probably unique.

You can use URLs to point to any of these files, so you can tie together files from different locations at once.

jheriko2• 13 years ago

a lot of this is generally (d)vcs and applies equally to mercurial or even svn...

also if you think x pages of anything is a simple explanation then you missed a trick or two.

e.g if you have to explain why your arrows are pointing backwards you are doing it wrong, instead of using the standard notation for graphs and lists and stuff which are not generally well known, use what most people will understand on inspection.

Jugurtha2• 13 years ago

I prefer the Fox News tutorial on the subject.

'Repo' means 'reciprocity' or 'reposotory' if you didn't know.

Jugurtha2• 13 years ago

Wow! Did people forget what sarcasm looks like ?

grapeot• 13 years ago

http://static4.businessinsider.com/image/52330e4deab8eaef7ac...

I also wanted to post this screenshot and then saw your comments...

MBCook9• 13 years ago

I'm... slightly afraid. I can't wait to send this to my coworkers.

ezrasuki• 13 years ago

Yeah right.

WestCoastJustin• 13 years ago

Gitolite (where this is hosted) is actually pretty cool too. For those who don't know what gitolite is, it is software to works in tandem with git-daemon, that basically allows you to run a centralized git sever with access rules.

I created a screencast about it @ http://sysadmincasts.com/episodes/11-internal-git-server-wit...

aylons• 13 years ago

Moreover, if you integrate gitolite with redmine (easy to do with a plugin [1]), you get a great corporate-leve, self-hosted, easy-to-use team management tool for programmers and alike.

[1]https://github.com/ivyl/redmine-gitolite

beagle33• 13 years ago

There's also gitlab, which is a github style app you can run locally. It used to use gitolite internally for access control, but it is now using its own access control system.

csense• 13 years ago

I've used both. Gitolite does everything on the command-line, including access management.

Gitlab is essentially an open-source clone of Github's web UI. Of the two projects, I think Gitlab is harder to deploy and far more resource-intensive on the server, but easier for users.

EdwardDiego4• 13 years ago

And there's also gitosis, which IIRC is considered superceded by gitolite, but it's still working well for us.

btbuildem• 13 years ago

The 90's called, they want their bitmaps back..

bb0wn• 13 years ago

I found the git book to be more than adequate enough for explaining the structures and practice patterns of git.

http://git-scm.com/book

gbog• 13 years ago

Nice. I'd love to see more details about the index, the way to see differences between branches with log and diff, and I think stash should be mentioned.

b0z0• 13 years ago

Very nice, and to see it in action, this is also really cool: http://pcottle.github.io/learnGitBranching/?demo

Pxtl4• 13 years ago

... that is not simple. But I'm figuring it out anyways.

I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled.

Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Origin into my branch. So I fetch the changes from origin/master and then rebase or merge my repo on top of that. That's my "Get Latest" command, basically, right? Assuming I'm working on "master", I fetch then rebase or merge origin/master.

To check in, I tell the origin server to take my stuff and then rebase or merge its master with that.

I still feel like this is a rather baroque approach to the problem... managing oodles of local commits separate from rebase/merges seems bizarre, above and beyond the decentralized approach that makes my own repo, my peer, and the "origin's" stuff all equivalent.

The decision of when to merge vs. rebase is still confusing to me.

tbatterii• 13 years ago

The decision of when to merge vs. rebase is still confusing to me.

i always thought it was "never rebase commits you have pushed" at least you know about rebase though. :)

MBCook9• 13 years ago

That is certainly the rule 99.99999% of the time. It's possible, but it can be a mess for everyone else.

Before you push, you can choose to do it either way.

dcre4• 13 years ago

One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally.

Regarding merge vs. rebase, here's my approach: rebase to keep history a straight line when it's just your changes and it's just a few commits. If it's too many commits you tend to have more conflicts and it's usually easier to merge.

Pxtl4• 13 years ago

One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally.

But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doing my local merge/rebase. That sounds like it would lead to a "last-one-wins" conflict-resolution or a complete reversion of the origin if I publish without rebasing on the origin's version first.

MBCook9• 13 years ago

The decision of when to merge vs. rebase is still confusing to me.

I'll take a stab at this. When you merge, you're merging their branch into yours. At the end of you have both pieces of code, but all the history is still there. You can see that their branch started 20 commits ago, that two things were done in parallel, and that they came back together with the merge.

Rebase is a different. Rebase changes history. Rebase is like this:

    1. Find the common ancestor between the branches
    2. Extract each commit from their branch, turn it into a patch (named patch*N*)
    3. Switch back to your branch
    4. Apply patch1, patch2, ... patch*N* in order

Now it looks like all the work was done at the end of your brach, like it was based on your latest commit. Instead of being based on the common ancestor commit, it is now based on your commit. It's been rebased.

It makes sense if you think about Git coming from kernel development. Developers tended to work in patch sets, a long series of patches to a common base. Rebaseing is just applying that series of patches to a different base.

Merging merges branches, but rebase is more like moving branches.

stormbrew4• 13 years ago

A suggestion for anyone hoping to write accessible tutorials:

Hg folks should read this section carefully. Among various crazy notions Hg has is one that encodes the branch name within the commit object in some way. Unfortunately, Hg's vaunted "ease of use" (a.k.a "we support Windows better than git", which in an ideal world would be a negative, but in this world sadly it is not) has caused enormous takeup, and dozens of otherwise excellent developers have been brain-washed into thinking that is the only/right way.

If this is one of the most important concepts, starting it off with a slew of negativity about things the reader may be currently using (windows, hg) is probably not the best way to get them to keep reading.

ender72• 13 years ago

There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.

ranman• 13 years ago

out of curiosity could you enumerate some of the poor design choices in git?

pessimizer• 13 years ago

This did it for me: http://www.sbf5.com/~cduan/technical/git/

wiremine• 13 years ago

Git's learning curve feels similar to the learning curve of a programming language like Python.

Once you understand you're not going to pick it all up in an afternoon (just like a language) and that there will be lots more to learn down the road (like a language), git feels great.

guard-of-terra3• 13 years ago

Programming language is 80% of my work effort but version control is more like 5%. It should be an utility, I don't want it to be a world of its own right, I don't have needs for insanely powerful version control system because my needs are sane and limited - and that's where git is not so cool.

Perseids4• 13 years ago

You can use the same argument about debuggers, dependency managers, editors, etc.

If you are happy with whatever tool you are using, why change?

EdwardDiego4• 13 years ago

Git's learning curve is far worse than Python's, simply due to the limitations of its abstractions - e.g., a branch isn't really a first class entity in Git, yet most people using the centralized server model for Git will tend to think about their daily Git work in terms of branches.

The problem only manifests when you're trying to do things like "show me only commits from branch <X>". Or, "show me when branch <X> was created from master."

delinka• 13 years ago

See also Git for Computer Scientists at http://eagain.net/articles/git-for-computer-scientists/

0xdeadbeefbabe• 13 years ago

It's possible, at least after I see the concepts this way, that git has the simple design Hoare was talking about when he said:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C.A.R. Hoare

mrcactu5• 13 years ago

   git init
   git add .
   git commit ":-)"
   git push origin master

6 months later I still look it up... this tutorial is for me!

anandabits• 13 years ago

This is very nice as a review of Git, but probably best in that context rather than an initial presentation of the concepts. I really enjoyed the Source Control Made Easy series by Jim Weirich. It presents the same information in an easily digestible, step-by-step approach. Highly recommended for those trying to understand how Git works and how to best make use of it.

http://pragprog.com/screencasts/v-jwsceasy/source-control-ma...

obilgic• 13 years ago

Can someone please convert this into a nice pdf? Chances are I will do this type of reading when I am offline...

acqq3• 13 years ago

I don't use Git and would like to know how the following problem is solved in Git.

Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is obsolete, as soon as some bugs are reported in v1 you have to fix them in v1, v2 and v3. And every bigger version is "newer" but some features can be added in v2 and v3 some just in v3 etc.

How can you work on such a big project and have a single repository where all three versions are present, and work on these three versions in parallel (having sources which are compiled in different base directories)?

taspeotis2• 13 years ago

(having sources which are compiled in different base directories)

With my nascent Git understanding, I think you would just have multiple branches for v1, v2... and then clone the repository multiple times so you have multiple working copies.

Check out v1 in the first one, v2 in the second one.

Although changing between related branches is usually quite quick in Git. Also, a fresh checkout of ~100mb is not a lot. At least for an SSD.

This also relies on having a centralised Git repository for you to push/pull changes to. But I believe Git allows you to synchronise multiple repositories on disk.

You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?

MBCook9• 13 years ago

and then clone the repository multiple times so you have multiple working copies.

This is probably not what you want. First, you should know that switching between branches in Git is insanely fast. In general, it won't get in your way.

If you clone the repository, each one is a full git repository. That means you'll triple the storage on the disk. Worse, you'll have to do 3x as many pulls to keep all 3 repositories up to date.

You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?

It often comes up, but that's what we do. We may have a dozen branches on our machines (the thing(s) we're working on, recent things we worked on, the one that's been sitting for a while we're waiting on an answer to pick up again) and we can switch our project within a second or two on a simple rotating hard drive.

beagle33• 13 years ago

What does "take version out of the repository first" mean?

You can do a "git checkout" to get a copy out. On a modern drive, checking out a hundred meg history takes a few seconds.

You do not need multiple copies on the disk at the same time - "git checkout v1" when you are working on v2 will do only the changes necessary to make your directory into "v1", and then you can do "git checkout v2" or "git checkout v3" to get another version.

Alternatively, you can just mount your git repo as a filesystem, e.g. https://github.com/davesque/gitfuse (there are other projects - this came up on search, never used it myself).

And anecdotally, my git repos with tens of branches tend to take much less space than one checkout. git is super efficient about storage.

jlgreco14• 13 years ago

Just make a branch for each v1,v2,v3. Instead of having a single main, you have three. Unless you are literally typing with both hands on two different keyboards, you just checkout whichever branch you want to work on at the moment. That is a very lightweight operation.

Note that 100MB is not really big in Git; you don't really run into issues until you are in the low GB range (at which point you should probably be considering if perhaps you actually have multiple different projects in the same repository. If so, that is where tools like 'repo' can step in: http://en.wikipedia.org/wiki/Repo_%28script%29)

MBCook9• 13 years ago

A Successful Git Branching Model [1] is a very common way to deal development in a good sized project. You could consider the bug fixes to v1, v2, and v3 to be hot fixes. You could choose to keep a single running branch (the equivalent of master in the model given) for each of the older versions if you keep adding occasional features.

I know I've seen guides online of how to deal with the exact problem you're describing, but I can't remember where to find any of them right now.

[1] http://nvie.com/posts/a-successful-git-branching-model/

lisper3• 13 years ago

Great article. Just one rather glaring omission: only a single mention of the index, and that only in passing. I have used git for years, and I still don't understand what the fleeping index is supposed to be for. What can you do with the index that you can't do with a branch? And why is it called the index? (And why is it git add -a but git commit -A? Or maybe it's the other way around?)

Cyranix2• 13 years ago

Not to be cruel, but I don't understand how you've used Git for years without understanding what the index is. There's more than a few learning resources for Git online to satisfy your curiosity. Anyway, to give an abbreviated explanation:

The index is a staging area for your commits. When you use `git add`, changes in the working directory are staged (prepared) for the next commit. If you pass the `-a` flag to `git commit`, Git will stage all changes to files that it is already aware of. (Recall that new files are untracked and must be manually added to the index the first time they're committed; `-a` won't add those files because Git doesn't already know about them.)

Why have a staging area instead of just creating a commit directly from all the changes in the working directory? It's basically a sanity measure for organizing commits if you're ever anything less than a perfect developer. If you make a bunch of changes and later realize that there's more than one "unit of work" represented in those changes (however you choose to define those units), you can selectively add files to the index to create commits that make sense. You can even use the interactive mode of `git add` to selectively stage changed sections within a single file. If you care about the benefits of sensible commits -- bug hunting with bisection, ability to run `git revert` to undo a logical unit of work -- then the index is your friend.

A few random pages on the index that I pulled up:

[0] http://www.gitguys.com/topics/whats-the-deal-with-the-git-in...

[1] http://git-scm.com/book/en/Git-Tools-Interactive-Staging

lisper3• 13 years ago

Well, I'm being a little facetious. I do understand what the index is and what it's used for (but not why it's called the "index" instead of, say, the "stage"). What I don't understand is why the index exists as a separate abstraction. You could have the exact same effect by, for example, doing a git stash, and then popping changes out of the stash into your (now clean) working directory. The WD in effect plays the role of the index, and you get the same result, but with fewer abstractions, fewer commands, and less confusion.

But I hold Linus in high enough regard to take very seriously the possibility that the index is a reflection of some deep wisdom that I have missed. That's the real reason I raise this every now and again.

forrestthewoods• 13 years ago

If your "simple" explanation of how to use something is 27 pages then it is many things and simple isn't one of them.

My favorite thing about Git is how it's forced Perforce to add features and lower price. Thanks Git!

andrewflnr• 13 years ago

This has been danced-around in the comments, so I'm just going to say it: I don't need the concepts of git simplified, I need a better explanation of how git's bizarre command set maps onto the obvious DAG/filesystem operations.

ams61102• 13 years ago

Seconded. And, at 30 printed pages, I'd hate to see the non-simplified explanation (no, I didn't actually print it).

Sir_Cmpwn• 13 years ago

It's the stuff behind the curtain that makes me love git. It doesn't just seem like version control software - it seems like the software is an interface to a much more powerful version control engine. Git just makes sense under the covers.

Git concepts simplified

Related Stories