
Git Is Simpler Than You Think - nfarina
http://nfarina.com/post/9868516270/git-is-simpler
======
ekidd
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
Why the -u on push?

~~~
shennyg
It allows you to use `git pull/push' without specifying the remote. see:
<http://mislav.uniqpath.com/2010/07/git-tips/> Section "Push a branch and
automatically set tracking"

------
barrkel
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.

~~~
adobriyan
git-clone --depth 1

~~~
prodigal_erik
Shallow clones are essentially read-only, they can't push nor be fetched from.
Unless you're prepared to regress to emailing patches around, a shallow git
clone is actually less useful than a svn checkout.

------
masnick
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.htm...](http://tom.preston-
werner.com/2009/05/19/the-git-parable.html)) for anyone who hasn't read it.
Different focus, but also helpful for understanding git's philosophy.

~~~
schleyfox
I found git to make a lot more sense personally after reading
<http://eagain.net/articles/git-for-computer-scientists/> . The git parable is
also very good.

~~~
watmough
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
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

~~~
watmough
Thanks, obviously I'm missing some concept somewhere.

~~~
rahoulb
The checkout command moves you off the experimental branch and back onto the
master branch.

The merge command then takes the commits in experimental that aren't in master
and puts them into master.

~~~
watmough
Thanks, I think I may have been misusing

    
    
        git branch [some name]
    

I'll take a look at some of the suggested tutorials again. Thanks all. That
said, I pretty much do straight-ahead main-line development, so this isn't a
huge problem right now. I do most of my development after midnight, so there
isn't a huge cognitive headroom left...

------
wccrawford
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.

~~~
masnick
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%20folde...](http://www.google.com/search?q=what%20is%20in%20.svn%20folder)?

with

[http://www.google.com/search?q=what%20is%20in%20.git%20folde...](http://www.google.com/search?q=what%20is%20in%20.git%20folder)?

All the results for the svn search are about getting rid of these folders --
nothing explaining their contents.

~~~
masklinn
> 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>

[1] <http://svn.apache.org/repos/asf/subversion/trunk/subversion/>

[2]
[http://svn.apache.org/repos/asf/subversion/trunk/subversion/...](http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/)

------
vailripper
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
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
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.

------
cpeterso
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/>

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

------
Lewisham
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
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).

------
projectileboy
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
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
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
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
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.

------
skrebbel
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?

------
oacgnol
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
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).

------
skrebbel
> _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.

------
chriseidhof
(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.

------
par
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.

~~~
mikeash
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
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
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.

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

~~~
js2
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.

------
VilleSalonen
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
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.

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

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

------
famousactress
_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.

------
psychotik
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?

~~~
gks
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.

------
stretchwithme
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
For me it really clicked when I watched: <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.

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

------
splicer
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.

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

------
i386
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.

------
Kwpolska
...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/>

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

