Git Is Simpler Than You Think (opens in new tab)

A thousand times this. For my first year to year and a half of using git, I didn't even know that you could re-write your history. I just started out with a personal repo on my own machine, where I'd init, add, rm, commit, and look at logs. Then I learned how to start working with someone else's repo, which introduced me to cloning, pulling, pushing, fetching, and all that jazz. As the project sizes grew, I realized how useful branches were, so I became more familiar with tracking things upstream, merging, and some more advanced workflows. Finally I started poking around in the git object model, and learning how I can clean up my local history before a push. It was baby steps all the way.

Trying to use rebase the same week or month that you learn git (or version control period), while doable for some, is just crazy for everyone else. You don't jump into riding a bike before you learn to walk.

I really don't like "git commit -a". I've seen people new to git add every file in the project directory without checking what files are there. This includes merge conflicts, SQL dumps and random backups.

If you do a "git status" immediately before then "git commit -a" can be a slight time saver; though It's better to use "git add -u", which stages all files that are in the repo and ignores any new files. Personally, I like adding files either 1 or 2 at a time or even with "git add -p".

While I'm at it, lots of people seem to have poor (single line) commit messages, stemming from the use of "git commit -m". Whilst this is OK on some occasions, commit messages are often better thought of as an email with a subject and a body.

(Yes, I know sometimes a single line commit is all you need and you can write multi-line commits directly on your shell but some people don't know this and it limits their ability to write a good commit message.)

Feel better getting that out my system. Now I need to tell my co-workers.

If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".

You're kindly assuming people never enter the wrong command by accident.

Undoing a commit, for example, is very common and necessary, especially for beginners.

Good advice. I would add the following use case:

    # Oh no! Those changes should have been on their own branch, not dev...
    git stash
    git checkout -b changes_on_their_own_branch
    git stash apply
    git commit -a

Couldn't agree more! I have lead quite a successful 'git life' without using any complex commands and therefore have never found git hard!

Why the -u on push?

To checkout an existing branch, you need only do 'git checkout new_branch_name' - if the branch exists on the remote, git will automatically create a local version and set it to track the upstream version.

If you wanted to use git in this situation, rather than svn, I'd recommend using git-annex (http://git-annex.branchable.com/). It avoids those binaries bloating the history while still letting branches "contain" specific versions of them. You can set up a centralized annex that is eg, a bup repository (or a rsync server, or use S3) and git-annex pulls down the binaries from there on request.

What is the disk footprint of the existing SVN repository? "100s of GBs"? git's worst case repository size is equal to or slighly larger (few % probably) compared to an SVN repository.

Git will deduplicate all of your binaries across branches (and if you are clever, across repositories, but that's another story) so worst case you will only have one copy of any binary file no matter how many times it appears in your history.

That is not to say that git may be a poor fit for your current project+organization for other reasons but a blanket assumption of ("repository would be too huge") is not generally accurate.

Can you maybe separate the binaries and use git for only sources?

You're being downvoted for not using an HN approved workflow. Your workflow is inconceivable and therefore wrong.

But have you actually tried it? You might be surprised.

Two words: git submodules.

Git repositories are quite a bit smaller than svn's[1], but hundreds of GB is pretty huge.

[1] http://www.contextualdevelopment.com/logbook/git/large-proje...

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.

git-clone --depth 1

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.

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

with

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.

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.

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.

The worst thing in Git (comparing to Mercurial/other DVCSes) is that it is "more mainstream", thanks to GitHub. Everyone is assumed to have an account on GitHub (and such an account is even requested in the YC application form!), even if one is a Python programmer fond of Mercurial, or a Haskellista using darcs for everything around.

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?

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

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.

i found the pro git book a very good reading to understand git for the first time http://progit.org/book/

I've struggled with helping others learn git as well; you can see some of my thinking at (http://think-like-a-git.heroku.com/#1) and (http://confreaks.net/videos/612-cascadiaruby2011-think-like-...). Currently working on a longish standalone website for those who (like me) can't stand to slow down enough to sit through an entire 20-minute video. ;>

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'".

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.

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.

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.

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.

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

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

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

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.

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.

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

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.