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.<p>It's possible to build a very successful git workflow using only the following commands:<p><pre><code> git clone git:...
git add path/to/new_file
git commit -a
git pull
git push
</code></pre>
(Yes, commit before pulling, rather than vice versa.)<p>If you want to use branches, you need to add:<p><pre><code> # 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
</code></pre>
This workflow is extremely safe. At worst, you might need to resolve a merge conflict.<p>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.
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.
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).<p>I'd also recommend The Git Parable (<a href="http://tom.preston-werner.com/2009/05/19/the-git-parable.html" rel="nofollow">http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...</a>) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.
No, actually, it's not. And that post proves it.<p>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.<p>Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.
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.
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.<p>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).<p>For those looking for something simpler than git, I recommend <i>eg</i> (EasyGit), a one-file Perl wrapper:<p><a href="http://people.gnome.org/~newren/eg/" rel="nofollow">http://people.gnome.org/~newren/eg/</a>
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.<p>(or maybe the author did mention it and I missed it?)
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.
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.<p>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?
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.
> <i>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.</i><p>Spot on! I really thought I was the only one.
(a bit off-topic)<p>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.
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.
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. :(
<i>I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet.</i><p>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.<p><i>Executive decision</i>? 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: <i>winning the Internet</i>? That's a great reason to look into something. Not a great reason to switch your team to it.<p>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.
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?
The sea parted for me when I caught Scott Chacon explaining git.<p><pre><code> http://www.youtube.com/watch?v=QF_OlomyKQQ
</code></pre>
It really is better in so many ways and once you understand how it works, you may say, like me, "Ahh, YES!"<p>And, yeah, he warns you about rebase.
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.
...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. <a href="http://mac.github.com/" rel="nofollow">http://mac.github.com/</a>