16 ms·

Git Is Simpler Than You Think

609 points by nfarina 15y ago

wccrawford 15y ago
No, actually, it's not. And that post proves it. You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases. Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.
- fsniper 15y ago
  Yes I'm with you with this wccrawford. Git is not simple. Git internals may be simple hacks for hackers but git usage is another story. It does have neither understandable nor compatible terminology. Because it's simple bash scripts but distributed and decentralised it has a steep learning curve. No, no git is not simple. It's really complicated.
  - jrockway 15y ago
    Git is mostly not bash scripts anymore: [~] 0 (jon@snowball2) $ file /usr/lib/git-core/git-status /usr/lib/git-core/git-status: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped
    - fsniper 15y ago
      Thank you. I was misdirected by the article. And I have not peeked at the git source ever.
- masnick 15y ago
  I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated. The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model. FWIW, compare: http://www.google.com/search?q=what%20is%20in%20.svn%20folder http://www.google.com/search?q=what%20is%20in%20.svn%20folde...? with http://www.google.com/search?q=what%20is%20in%20.git%20folder http://www.google.com/search?q=what%20is%20in%20.git%20folde...? All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.
  - masklinn 15y ago
    > All the results for the svn search are about getting rid of these folders -- nothing explaining their contents. That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel). Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong. Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy. edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway) [0] http://svnbook.red-bean.com/en/1.1/ch07s02.html http://svnbook.red-bean.com/en/1.1/ch07s02.html [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/ http://svn.apache.org/repos/asf/subversion/trunk/subversion/ [2] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/ http://svn.apache.org/repos/asf/subversion/trunk/subversion/...
  - kemayo 15y ago
    A better comparison would be between an explanation of the contents of .git and the contents of your actual SVN repo on the server. Since that's what the equivalency is.
  - masnick 15y ago
    My point is that to a naive user googling to figure out what is going on, the dotfile element of svn is inscrutable.
- js2 15y ago
  Git is conceptually simple, but has a baroque interface. It's nearly impossible to form a proper mental model of what's going on under the hood from its CLI. The point of this article is that if you take the time to learn how git is actually constructed, the CLI becomes a lot more bearable, and is less likely to leave you in distress when Something Unexpected Happens.
  - nfarina 15y ago
    I wish I had written your first line!
  - bugsbunnyak 15y ago
    I struggled for several hours last night to fix the history of a git-svn repo that had fallen out of sync. Eventually I started to grok it and the fix took all of two commands. I think that this semi-obfuscation may have been an intentional attempt to improve the SNR of kernel contributions - by putting in place a mild cognitive obstacle...
- jasonkostempski 15y ago
  Well, to be fair, the title is not 'Git Is Simple'. I'm just starting to really use Git and after reading this it seems a little simpler to me. Personally, I think Git is relatively simple as far as version control systems go, it's forgetting 5 years worth of knowledge of SVN and the nice visual tools that support it that is hard.
  - pivo 15y ago
    I thought it was a little odd that he (seems to be) comparing the svn GUI with the git command line experience even though there are GUI tools for git as well. Have you tried Tower (http://www.git-tower.com/ http://www.git-tower.com/)? I used it briefly for a small project and thought it was nice, but didn't really have time to get to know it that well.
  - geeksam 15y ago
    I make daily use of GitX for visualizing the state of a repo, and it's got a pretty nice UI for building commits as well. (It's Mac-only, though.) Apparently there are several forks that have added new functionality on top of the version I use, but I'm comfortable enough at the command line now that I haven't bothered checking any of them out.
masnick 15y ago
Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git). I'd also recommend The Git Parable (http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.
- eLod 15y ago
  i found the pro git book a very good reading to understand git for the first time http://progit.org/book/ http://progit.org/book/
  - re_todd 15y ago
    Great book. It really helped me overcome git's learning curve.
- schleyfox 15y ago
  I found git to make a lot more sense personally after reading http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/ . The git parable is also very good.
  - watmough 15y ago
    So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type: git merge master git branch master from the tip of my experimental branch, and master will be moved up to the tip of the tree?
    - fr0sty 15y ago
      Not at all. Where did you come up with that? That would merge in any commits in master not already in experimental and the next command would fail because a branch 'master' already exists. To do what you are describing you would do this (or something similar: git checkout master; git merge experimental
gms 15y ago
So what was the cause of the original error and how did you fix it?
- js2 15y ago
  There was a conflict while rebasing. In this situation you generally do one of: 1. Resolve the conflict and continue rebasing. 2. Drop the conflicting change and continue rebasing. 3. Abort the rebase operation.
jbredeche 15y ago
Great, entertaining writing style. Probably the most readable intro to Git I've ever read.
- braco_alva 15y ago
  Yes, for someone who has never use Git is a very nice introduction to it.
cpeterso 15y ago
When git was born, many people complained about its poor usability and some people created friendlier "porcelain" scripts. Eventually, git itself became "good enough" and maintaining porcelain scripts became too much work to keep up. Is it too late for an improved git user experience? With so many online tutorials and books, a new porcelain interface would have a tough time capturing much mind share (while still calling itself git). For those looking for something simpler than git, I recommend eg (EasyGit), a one-file Perl wrapper: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/
- macrael 15y ago
  Personally, I think github is trying to become that simpler interface. We'll see how they do, but so far it is promising.
par 15y ago
Love the concept of the article but right out of the gate comparing it to a Model T and saying you must be a mechanic to operate it will likely result in a high bounce rate, and possibly just serve to re-affirm someones belief that git is, indeed, complex.
- martey 15y ago
  Should writers care about the opinions of people who do not read their entire article, but leave after seeing a diagram of a Model T? I think the intended audience of the article are people who are already at least vaguely familiar with Git, but do not know its inner workings. The thesis seems to be "Git is complex, but not as complex as you might fear reading 'man git'".
- mikeash 15y ago
  Git is intended as a tool for programmers, which are precisely those "mechanics" he mentions. Any programmer who's scared away by that doesn't understand what they do.
  - MetaMan 15y ago
    Err - Maybe we just resent having to spend so much time on the mechanics of the tool/s rather than our main activity which is writing code.
    - mikeash 15y ago
      Oh, I agree. But if the net result is something that works better, the fact that it needs some internal tinkering shouldn't scare programmers away.
psychotik 15y ago
I wish the author would've explained the motivation to move from SVN to Git, other than 'it was winning over the web'. Was SVN just not working for them, for some reason? Are there things that he and him company wanted to do that wasn't possible with SVN, but was with Git?
- nfarina 15y ago
  Part of it was that SVN was the last service running on a server I wanted to shut down. The other part was simply momentum. Github (and therefore Git) were too exciting to not want to be a part of. I didn't want to be left behind. That said, SVN was perfectly serviceable, though I don't imagine I'll ever use it again.
- gks 15y ago
  Quite frankly there's no more reason for "why we moved from SVN to Git" topics anymore. It's been beat to death. Better to keep up while the team is small than to try to move even more people over later and turn into mega-corp still using CVS. Learning something new isn't necessarily a bad thing. I question people that are unable to try to learn something new every day. It takes a few minutes of your time and you can learn something. Sure, git might take more than a few minutes… but why not TRY? As for requesting why they switched from subversion to git… yea, as I said, you have a billion articles written out there by now about WHY. There aren't more needed. The benefits are pretty clear if you read any one of those other articles. Of course, this more leads into "why git and not mercurial (or any other DVCS)?" Which again, has a billion other articles written up on it.
deleted 15y ago
[deleted]
chriseidhof 15y ago
(a bit off-topic) Oh no! I now see cognitive dissonance everywhere. I realized that it's the same with git: maybe we like it so much because it took such a hard time to master. I still don't feel like I master it. However, reading some books on git and understanding the philosophy did make it feel simpler.
Lewisham 15y ago
I would have really liked it if the author had mentioned exactly how the co-worker in the beginning had got into the "3-way merge" state, and some how got onto a non-existent branch. I don't know what it means, and I've never got there, so I'd love to know how it happened. (or maybe the author did mention it and I missed it?)
- eslaught 15y ago
  It's the result of a merge conflict (e.g. after attempting a rebase). If you work regularly with other people you end up seeing this a lot (or rather, whenever you both edit the part of the same file at the same time).
ekidd 15y ago
If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull git push (Yes, commit before pulling, rather than vice versa.) If you want to use branches, you need to add: # Showing branches. git branch -a gitk --all # Checking out branches. git checkout some_branch # Creating and pushing a new branch. git checkout -b new_branch_name git push -u origin new_branch_name # Checking out an existing branch. git checkout -b some_branch origin/some_branch # Merging a branch into your current branch. git pull origin some_branch This workflow is extremely safe. At worst, you might need to resolve a merge conflict. But if you start digging around under the hood, and you start editing your commit history, you'd better be prepared to understand what you're trying to do.
- nicky0 15y ago
  Why the -u on push?
  - _ikke_ 15y ago
    It creates a tracking branch, and so git knows how far a branch is relative to a remote branch.
  - deleted 15y ago
    [deleted]
  - Kwpolska 15y ago
    -u, --set-upstream For every branch that is up to date or successfully pushed, add upstr eam (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config (1). --man git-push
  - shennyg 15y ago
    It allows you to use `git pull/push' without specifying the remote. see: http://mislav.uniqpath.com/2010/07/git-tips/ http://mislav.uniqpath.com/2010/07/git-tips/ Section "Push a branch and automatically set tracking"
vailripper 15y ago
Having used Mercurial and Git, I have to say I vastly prefer the interface of Mercurial. It still has its quirks, but overall I find it much easier to use, especially on Windows. Git was very clearly built as a Unix solution first, with Windows support hacked on later.
- andylei 15y ago
  i tried to learn git and hg and i found that hg was so much more friendly to work with. when things go wrong in git, cryptic error messages are spawned and i have no idea what to do. when i do things in hg, error messages are actually helpful. even when things don't go wrong, hg constantly gives me helpful advice at the command line. example: after you do hg pull, it tells me that i need to do hg update. why can't git stuff like that?
  - mtrn 15y ago
    I used both, too. From the mercurial docs: "If you felt uncomfortable dealing with Git's index, you are switching for the better." To be honest, after a few years with git, I feel uncomfortable without the index.
  - vailripper 15y ago
    Agreed - although I will say I've lost count how many times I've had to explain to a junior that "push would create remote heads" just means you need to fetch and then push...
- dcosson 15y ago
  Interesting - haven't ever used Mercurial but as far as Windows ports of Unix-based tools go I love the git interface. I always run it in standalone shell mode, and its shell has enough Unix commands built in that I haven't even had the need to install cygwin on my new PC yet. The "check out line endings as \r\n, check in as \n" feature is a neat touch as well (granted, any decent text editor handles both kinds of line endings, but still).
  - vailripper 15y ago
Kwpolska 15y ago
...and you are an idiot. WHY did you use rebase? If you are a noob, why won't you use the great GitHub for Mac app? It is even prettier than Versions. http://mac.github.com/ http://mac.github.com/
jcromartie 15y ago
I read this, and think: cryptographic hashes are just too damn cool.
barrkel 15y ago
The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with minimal dependencies. I dread to think what the entire history would take - it must be many 100s of GBs at least. It would certainly rule out the whole "working disconnected" idea on laptops, for one.
- danellis 15y ago
  But have you actually tried it? You might be surprised.
  - barrkel 15y ago
    I might give it a bit of a go when I'm on-site in CA in a couple of weeks, rather than trying it over transatlantic VPN - though my MBA only has 256GB SSD, and it's 50/50 Windows 7 and OS X. Still optimistic? :)
- seunosewa 15y ago
  Can you maybe separate the binaries and use git for only sources?
- nfarina 15y ago
  Git actually starts compacting your object database and creating super-efficient delta-compressed packfiles after a bit. You can still throw object files in there afterwards though, and it doesn't change the basic principles of operation.
  - tedunangst 15y ago
    Super-efficient delta-compressed packfiles of zip files are not, in fact, super-efficient.
VilleSalonen 15y ago
I read through the article waiting for the explanation of the "Falling back to patching base and 3-way merge?" line but unfortunately it wasn't explained. Git didn't become any simpler after all. :(
- jrockway 15y ago
  This line is irrelevant debugging information. The problem is that there's a merge conflict. This would happen with any version control system; it's not something unique to Git.
projectileboy 15y ago
Although I love Git, this whole thread exemplifies the way in which Git horribly fails my one success measure for good tools: you don't talk about them very much.
- MetaMan 15y ago
  Totally agree. We switched from SVN to Mercurial around 6 months ago and I have to say I am annoyed that I have to spend so much time messing around with the tool rather than coding.
  - fr0sty 15y ago
    You can say the same with almost any non-trivial development tool. Vim, emacs, Eclipse, VisualStudio, etc all require time spent "messing around with the tool rather than coding. Another fallacy is that "writing code" is the only "useful" thing one can do. Creating clean logical history and good commit messages (or other documentation) does not invole writing code, but that doesn't mean it is not important.
    - MetaMan 15y ago
      Where did I say that that coding is the only useful thing? The point I was trying to make is that tools are productivity aids and if a tool gets in the way and distracts you from your main activity (or activities) too much it can be counter productive. I use both Eclipse and VisualStudio and find those tremendous! A good tool hides unnecessary stuff from you and works in a clear predictable way. A tool is bad for me when it does the opposite.
      - fr0sty 15y ago
        The point I am trying to make is that all "productivity aids" have a learning curve and will require time spent "messing around" before they confer any benefit. In my experience, once you understand how git works it gets out of your way entirely.
oacgnol 15y ago
Git is very powerful and I do like it more than SVN, but I felt like I had more trouble switching to it from SVN than if I had learned git from a clean slate. Switching my mindset from SVN-style centralized repos to decentralized git was the hardest part, as certain things in SVN didn't translate to git. Git is simple, but switching is not.
- dongsheng 15y ago
  There true, it's hard to transform the concept in SVN/CVS to git world. I remember when I was migrating from CVS to git, it's ok to understand cvs update is git fetch & git merge now, committing is the same, additionally I need to push the commits to share with co-workers. The hardest part to understand rebasing and branch management. But it worth to learn all these concepts, it make version control more flexible. It's pretty cool to use git reset and git push -f to modify the commits history (make sure you know what you are doing).
asreal 15y ago
No thanks, I think I will wait for another couple of years until the next fan-boy tool comes along.
stretchwithme 15y ago
The sea parted for me when I caught Scott Chacon explaining git. http://www.youtube.com/watch?v=QF_OlomyKQQ It really is better in so many ways and once you understand how it works, you may say, like me, "Ahh, YES!" And, yeah, he warns you about rebase.
- edavis 15y ago
  For me it really clicked when I watched: http://blip.tv/scott-chacon/git-talk-4113729 http://blip.tv/scott-chacon/git-talk-4113729 (also by Scott Chacon). Once you understand the internals -- I remember being amazed at what .git/objects/ really was -- nearly everything about the git ecosystem becomes measurably easier to understand. Once you understand how your project looks in the eyes of git, it becomes a breeze to manage.
famousactress 15y ago
I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. I ADORE git and can't imagine NOT using it now that I've switched, but the little sentence above packs a whole lotta lame in it. Executive decision? Gross. There are good reasons for them, but not many. If you can't win your team over you probably don't have a good argument for the change... which brings me to the next problem I have with that sentence: winning the Internet? That's a great reason to look into something. Not a great reason to switch your team to it. Also, no. It's not simpler. It's pretty much just as complicated as You think it is. It's actually kind of a big pain in the ass to start using git.. but boy is it worth it.
i386 15y ago
If only promoters of Git put as much effort into fixing Gits usability as they do posturing about how everyone is wrong and how easy Git is, we'd have a better tool.
splicer 15y ago
This article was EXACTLY what my little brother needed! I've been trying to convince him to jump over to git for nearly a year now.
skrebbel 15y ago
> If you’re anything like me, you probably wondered why you were the only stupid person on the planet who didn’t intuitively get Git already. Spot on! I really thought I was the only one.
nrml 15y ago
There is a mac app that is relevant to this article: http://mac.github.com/ http://mac.github.com/
skrebbel 15y ago
I wonder what would happen if we'd take the git object model, totally as-is, and redesign a coherent set of commands to manipulate them. With simple and consistent switches, good command names (if at all possible), closely related to the concepts in the object model. Would that be very different from what git is now? My underbelly says yes, but really I'm not knowledgeable enough to tell. Any ideas?
pacomerh 15y ago
Nice, you'd be surprised of how many people would start using Git because these kind of articles. No complications.

609 points by nfarina 15y ago

No, actually, it's not. And that post proves it. You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases. Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.

fsniper 15y ago
Yes I'm with you with this wccrawford. Git is not simple. Git internals may be simple hacks for hackers but git usage is another story. It does have neither understandable nor compatible terminology. Because it's simple bash scripts but distributed and decentralised it has a steep learning curve. No, no git is not simple. It's really complicated.
- jrockway 15y ago
  Git is mostly not bash scripts anymore: [~] 0 (jon@snowball2) $ file /usr/lib/git-core/git-status /usr/lib/git-core/git-status: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped
  - fsniper 15y ago
    Thank you. I was misdirected by the article. And I have not peeked at the git source ever.
masnick 15y ago
I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated. The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model. FWIW, compare: http://www.google.com/search?q=what%20is%20in%20.svn%20folder http://www.google.com/search?q=what%20is%20in%20.svn%20folde...? with http://www.google.com/search?q=what%20is%20in%20.git%20folder http://www.google.com/search?q=what%20is%20in%20.git%20folde...? All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.
- masklinn 15y ago
  > All the results for the svn search are about getting rid of these folders -- nothing explaining their contents. That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel). Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong. Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy. edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway) [0] http://svnbook.red-bean.com/en/1.1/ch07s02.html http://svnbook.red-bean.com/en/1.1/ch07s02.html [1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/ http://svn.apache.org/repos/asf/subversion/trunk/subversion/ [2] http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/ http://svn.apache.org/repos/asf/subversion/trunk/subversion/...
- kemayo 15y ago
  A better comparison would be between an explanation of the contents of .git and the contents of your actual SVN repo on the server. Since that's what the equivalency is.
- masnick 15y ago
  My point is that to a naive user googling to figure out what is going on, the dotfile element of svn is inscrutable.
js2 15y ago
Git is conceptually simple, but has a baroque interface. It's nearly impossible to form a proper mental model of what's going on under the hood from its CLI. The point of this article is that if you take the time to learn how git is actually constructed, the CLI becomes a lot more bearable, and is less likely to leave you in distress when Something Unexpected Happens.
- nfarina 15y ago
  I wish I had written your first line!
- bugsbunnyak 15y ago
  I struggled for several hours last night to fix the history of a git-svn repo that had fallen out of sync. Eventually I started to grok it and the fix took all of two commands. I think that this semi-obfuscation may have been an intentional attempt to improve the SNR of kernel contributions - by putting in place a mild cognitive obstacle...
jasonkostempski 15y ago
Well, to be fair, the title is not 'Git Is Simple'. I'm just starting to really use Git and after reading this it seems a little simpler to me. Personally, I think Git is relatively simple as far as version control systems go, it's forgetting 5 years worth of knowledge of SVN and the nice visual tools that support it that is hard.
- pivo 15y ago
  I thought it was a little odd that he (seems to be) comparing the svn GUI with the git command line experience even though there are GUI tools for git as well. Have you tried Tower (http://www.git-tower.com/ http://www.git-tower.com/)? I used it briefly for a small project and thought it was nice, but didn't really have time to get to know it that well.
- geeksam 15y ago
  I make daily use of GitX for visualizing the state of a repo, and it's got a pretty nice UI for building commits as well. (It's Mac-only, though.) Apparently there are several forks that have added new functionality on top of the version I use, but I'm comfortable enough at the command line now that I haven't bothered checking any of them out.

masnick 15y ago

Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git). I'd also recommend The Git Parable (http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.

eLod 15y ago
i found the pro git book a very good reading to understand git for the first time http://progit.org/book/ http://progit.org/book/
- re_todd 15y ago
  Great book. It really helped me overcome git's learning curve.
schleyfox 15y ago
I found git to make a lot more sense personally after reading http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/ . The git parable is also very good.
- watmough 15y ago
  So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type: git merge master git branch master from the tip of my experimental branch, and master will be moved up to the tip of the tree?
  - fr0sty 15y ago
    Not at all. Where did you come up with that? That would merge in any commits in master not already in experimental and the next command would fail because a branch 'master' already exists. To do what you are describing you would do this (or something similar: git checkout master; git merge experimental

gms 15y ago

So what was the cause of the original error and how did you fix it?

js2 15y ago
There was a conflict while rebasing. In this situation you generally do one of: 1. Resolve the conflict and continue rebasing. 2. Drop the conflicting change and continue rebasing. 3. Abort the rebase operation.

jbredeche 15y ago

Great, entertaining writing style. Probably the most readable intro to Git I've ever read.

braco_alva 15y ago
Yes, for someone who has never use Git is a very nice introduction to it.

cpeterso 15y ago

When git was born, many people complained about its poor usability and some people created friendlier "porcelain" scripts. Eventually, git itself became "good enough" and maintaining porcelain scripts became too much work to keep up. Is it too late for an improved git user experience? With so many online tutorials and books, a new porcelain interface would have a tough time capturing much mind share (while still calling itself git). For those looking for something simpler than git, I recommend eg (EasyGit), a one-file Perl wrapper: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/

macrael 15y ago
Personally, I think github is trying to become that simpler interface. We'll see how they do, but so far it is promising.

par 15y ago

Love the concept of the article but right out of the gate comparing it to a Model T and saying you must be a mechanic to operate it will likely result in a high bounce rate, and possibly just serve to re-affirm someones belief that git is, indeed, complex.

martey 15y ago
Should writers care about the opinions of people who do not read their entire article, but leave after seeing a diagram of a Model T? I think the intended audience of the article are people who are already at least vaguely familiar with Git, but do not know its inner workings. The thesis seems to be "Git is complex, but not as complex as you might fear reading 'man git'".
mikeash 15y ago
Git is intended as a tool for programmers, which are precisely those "mechanics" he mentions. Any programmer who's scared away by that doesn't understand what they do.
- MetaMan 15y ago
  Err - Maybe we just resent having to spend so much time on the mechanics of the tool/s rather than our main activity which is writing code.
  - mikeash 15y ago
    Oh, I agree. But if the net result is something that works better, the fact that it needs some internal tinkering shouldn't scare programmers away.

psychotik 15y ago

I wish the author would've explained the motivation to move from SVN to Git, other than 'it was winning over the web'. Was SVN just not working for them, for some reason? Are there things that he and him company wanted to do that wasn't possible with SVN, but was with Git?

nfarina 15y ago
Part of it was that SVN was the last service running on a server I wanted to shut down. The other part was simply momentum. Github (and therefore Git) were too exciting to not want to be a part of. I didn't want to be left behind. That said, SVN was perfectly serviceable, though I don't imagine I'll ever use it again.
gks 15y ago
Quite frankly there's no more reason for "why we moved from SVN to Git" topics anymore. It's been beat to death. Better to keep up while the team is small than to try to move even more people over later and turn into mega-corp still using CVS. Learning something new isn't necessarily a bad thing. I question people that are unable to try to learn something new every day. It takes a few minutes of your time and you can learn something. Sure, git might take more than a few minutes… but why not TRY? As for requesting why they switched from subversion to git… yea, as I said, you have a billion articles written out there by now about WHY. There aren't more needed. The benefits are pretty clear if you read any one of those other articles. Of course, this more leads into "why git and not mercurial (or any other DVCS)?" Which again, has a billion other articles written up on it.

deleted 15y ago

[deleted]

chriseidhof 15y ago

(a bit off-topic) Oh no! I now see cognitive dissonance everywhere. I realized that it's the same with git: maybe we like it so much because it took such a hard time to master. I still don't feel like I master it. However, reading some books on git and understanding the philosophy did make it feel simpler.

Lewisham 15y ago

I would have really liked it if the author had mentioned exactly how the co-worker in the beginning had got into the "3-way merge" state, and some how got onto a non-existent branch. I don't know what it means, and I've never got there, so I'd love to know how it happened. (or maybe the author did mention it and I missed it?)

eslaught 15y ago
It's the result of a merge conflict (e.g. after attempting a rebase). If you work regularly with other people you end up seeing this a lot (or rather, whenever you both edit the part of the same file at the same time).

ekidd 15y ago

If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull git push (Yes, commit before pulling, rather than vice versa.) If you want to use branches, you need to add: # Showing branches. git branch -a gitk --all # Checking out branches. git checkout some_branch # Creating and pushing a new branch. git checkout -b new_branch_name git push -u origin new_branch_name # Checking out an existing branch. git checkout -b some_branch origin/some_branch # Merging a branch into your current branch. git pull origin some_branch This workflow is extremely safe. At worst, you might need to resolve a merge conflict. But if you start digging around under the hood, and you start editing your commit history, you'd better be prepared to understand what you're trying to do.

nicky0 15y ago
Why the -u on push?
- _ikke_ 15y ago
  It creates a tracking branch, and so git knows how far a branch is relative to a remote branch.
- deleted 15y ago
  [deleted]
- Kwpolska 15y ago
  -u, --set-upstream For every branch that is up to date or successfully pushed, add upstr eam (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config (1). --man git-push
- shennyg 15y ago
  It allows you to use `git pull/push' without specifying the remote. see: http://mislav.uniqpath.com/2010/07/git-tips/ http://mislav.uniqpath.com/2010/07/git-tips/ Section "Push a branch and automatically set tracking"

vailripper 15y ago

Having used Mercurial and Git, I have to say I vastly prefer the interface of Mercurial. It still has its quirks, but overall I find it much easier to use, especially on Windows. Git was very clearly built as a Unix solution first, with Windows support hacked on later.

andylei 15y ago
i tried to learn git and hg and i found that hg was so much more friendly to work with. when things go wrong in git, cryptic error messages are spawned and i have no idea what to do. when i do things in hg, error messages are actually helpful. even when things don't go wrong, hg constantly gives me helpful advice at the command line. example: after you do hg pull, it tells me that i need to do hg update. why can't git stuff like that?
- mtrn 15y ago
  I used both, too. From the mercurial docs: "If you felt uncomfortable dealing with Git's index, you are switching for the better." To be honest, after a few years with git, I feel uncomfortable without the index.
- vailripper 15y ago
  Agreed - although I will say I've lost count how many times I've had to explain to a junior that "push would create remote heads" just means you need to fetch and then push...
dcosson 15y ago
Interesting - haven't ever used Mercurial but as far as Windows ports of Unix-based tools go I love the git interface. I always run it in standalone shell mode, and its shell has enough Unix commands built in that I haven't even had the need to install cygwin on my new PC yet. The "check out line endings as \r\n, check in as \n" feature is a neat touch as well (granted, any decent text editor handles both kinds of line endings, but still).
- vailripper 15y ago

Kwpolska 15y ago

...and you are an idiot. WHY did you use rebase? If you are a noob, why won't you use the great GitHub for Mac app? It is even prettier than Versions. http://mac.github.com/ http://mac.github.com/

jcromartie 15y ago

I read this, and think: cryptographic hashes are just too damn cool.

barrkel 15y ago

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with minimal dependencies. I dread to think what the entire history would take - it must be many 100s of GBs at least. It would certainly rule out the whole "working disconnected" idea on laptops, for one.

danellis 15y ago
But have you actually tried it? You might be surprised.
- barrkel 15y ago
  I might give it a bit of a go when I'm on-site in CA in a couple of weeks, rather than trying it over transatlantic VPN - though my MBA only has 256GB SSD, and it's 50/50 Windows 7 and OS X. Still optimistic? :)
seunosewa 15y ago
Can you maybe separate the binaries and use git for only sources?
nfarina 15y ago
Git actually starts compacting your object database and creating super-efficient delta-compressed packfiles after a bit. You can still throw object files in there afterwards though, and it doesn't change the basic principles of operation.
- tedunangst 15y ago
  Super-efficient delta-compressed packfiles of zip files are not, in fact, super-efficient.

VilleSalonen 15y ago

I read through the article waiting for the explanation of the "Falling back to patching base and 3-way merge?" line but unfortunately it wasn't explained. Git didn't become any simpler after all. :(

jrockway 15y ago
This line is irrelevant debugging information. The problem is that there's a merge conflict. This would happen with any version control system; it's not something unique to Git.

projectileboy 15y ago

Although I love Git, this whole thread exemplifies the way in which Git horribly fails my one success measure for good tools: you don't talk about them very much.

MetaMan 15y ago
Totally agree. We switched from SVN to Mercurial around 6 months ago and I have to say I am annoyed that I have to spend so much time messing around with the tool rather than coding.
- fr0sty 15y ago
  You can say the same with almost any non-trivial development tool. Vim, emacs, Eclipse, VisualStudio, etc all require time spent "messing around with the tool rather than coding. Another fallacy is that "writing code" is the only "useful" thing one can do. Creating clean logical history and good commit messages (or other documentation) does not invole writing code, but that doesn't mean it is not important.
  - MetaMan 15y ago
    Where did I say that that coding is the only useful thing? The point I was trying to make is that tools are productivity aids and if a tool gets in the way and distracts you from your main activity (or activities) too much it can be counter productive. I use both Eclipse and VisualStudio and find those tremendous! A good tool hides unnecessary stuff from you and works in a clear predictable way. A tool is bad for me when it does the opposite.
    - fr0sty 15y ago
      The point I am trying to make is that all "productivity aids" have a learning curve and will require time spent "messing around" before they confer any benefit. In my experience, once you understand how git works it gets out of your way entirely.

oacgnol 15y ago

Git is very powerful and I do like it more than SVN, but I felt like I had more trouble switching to it from SVN than if I had learned git from a clean slate. Switching my mindset from SVN-style centralized repos to decentralized git was the hardest part, as certain things in SVN didn't translate to git. Git is simple, but switching is not.

dongsheng 15y ago
There true, it's hard to transform the concept in SVN/CVS to git world. I remember when I was migrating from CVS to git, it's ok to understand cvs update is git fetch & git merge now, committing is the same, additionally I need to push the commits to share with co-workers. The hardest part to understand rebasing and branch management. But it worth to learn all these concepts, it make version control more flexible. It's pretty cool to use git reset and git push -f to modify the commits history (make sure you know what you are doing).

asreal 15y ago

No thanks, I think I will wait for another couple of years until the next fan-boy tool comes along.

stretchwithme 15y ago

The sea parted for me when I caught Scott Chacon explaining git. http://www.youtube.com/watch?v=QF_OlomyKQQ It really is better in so many ways and once you understand how it works, you may say, like me, "Ahh, YES!" And, yeah, he warns you about rebase.

edavis 15y ago
For me it really clicked when I watched: http://blip.tv/scott-chacon/git-talk-4113729 http://blip.tv/scott-chacon/git-talk-4113729 (also by Scott Chacon). Once you understand the internals -- I remember being amazed at what .git/objects/ really was -- nearly everything about the git ecosystem becomes measurably easier to understand. Once you understand how your project looks in the eyes of git, it becomes a breeze to manage.

famousactress 15y ago

I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. I ADORE git and can't imagine NOT using it now that I've switched, but the little sentence above packs a whole lotta lame in it. Executive decision? Gross. There are good reasons for them, but not many. If you can't win your team over you probably don't have a good argument for the change... which brings me to the next problem I have with that sentence: winning the Internet? That's a great reason to look into something. Not a great reason to switch your team to it. Also, no. It's not simpler. It's pretty much just as complicated as You think it is. It's actually kind of a big pain in the ass to start using git.. but boy is it worth it.

i386 15y ago

If only promoters of Git put as much effort into fixing Gits usability as they do posturing about how everyone is wrong and how easy Git is, we'd have a better tool.

splicer 15y ago

This article was EXACTLY what my little brother needed! I've been trying to convince him to jump over to git for nearly a year now.

skrebbel 15y ago

> If you’re anything like me, you probably wondered why you were the only stupid person on the planet who didn’t intuitively get Git already. Spot on! I really thought I was the only one.

nrml 15y ago

There is a mac app that is relevant to this article: http://mac.github.com/ http://mac.github.com/

skrebbel 15y ago

I wonder what would happen if we'd take the git object model, totally as-is, and redesign a coherent set of commands to manipulate them. With simple and consistent switches, good command names (if at all possible), closely related to the concepts in the object model. Would that be very different from what git is now? My underbelly says yes, but really I'm not knowledgeable enough to tell. Any ideas?

pacomerh 15y ago

Nice, you'd be surprised of how many people would start using Git because these kind of articles. No complications.