A Hacker’s Guide to Git

http://wildlyinaccurate.com/a-hackers-guide-to-git

by sidcool • 12 years ago

372 117 12 years ago

EinLama• 12 years ago

I'd recommend another guide. "Pro Git" by Scott Chacon is excellent and welcomes patches, source for the book and its translations are on GitHub http://www.git-scm.com/book

morsch• 12 years ago

For what it's worth, Pro Git doesn't really need recommendation, it's the first Google hit for half of my git related queries...

benesch• 12 years ago

It's easy to mistake Pro Git as some sort of official Git reference when Googling, since it's hosted at

    http://git-scm.com/book

and looks an awful lot like the online man pages (git-scm.com/docs).

And so, without an explicit recommendation, it's easy to miss out on its well-organized narrative, or its superb ninth chapter, Git Internals, which explains the "why?" of Git and is probably one's best shot at grokking Git. (See parent's sibling comments for evidence.)

jbranchaud• 12 years ago

What is great about Pro Git is that it is approachable by someone new to git, but also eventually takes the reader through an explanation of the internals of git. Definitely a must-read!

collyw• 12 years ago

I appreciate that git is powerful, but should we really need to read a book just to get the best from a source control system? It seems overly complex to me at times (any time I do anything outside of my usual workflow).

Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.

oneandoneis2• 12 years ago

IME the main thing that makes git so hard to understand is the determination to think of it as "distributed subversion" - I find it substantially easier to teach git to people who've never used a VCS before than to people who have years of experience with SVN/CVS/etc.

It can seem a complicated nightmare until you grok how it really works. And if you have preconceptions getting in your way, yes, a book can be a very useful tool to give you that "Aha!" moment.

Once you stop someone thinking "It's a log of patches" and make them understand "It's like VM snapshots logged in a linked list" all the weird difficult stuff just Makes Sense.

egil• 12 years ago

Git was originally created to manage the Linux kernel. It is indeed complex, but it has to be at that scale. Git might not be the best option for every project, but I find it quite easy to use at the trivial scale as well. (How do you beat 'git init' ? No repository setup or anything.)

mschaef• 12 years ago

How do you expect things to work? This expectation that complex tools should be so obvious that they can be used without a book seems pretty odd to me. There aren't many other serious engineering disciplines where people enter it with that kind of mindset.

The source code for a system is one of the more valuable assets produced by a software development team, and managing source code is heavily about managing risk. Losing source code means losing work (money and time). Deploying source code too early means exposing the users of your system to code that might not be adequately tested. In distributed development, accepting unsigned patches means that your system might include untrustworthy code... the list goes on and on.

Part of the reason that git is complex (and this can be said about any serious source code management system) is that it solves complex problems. Fifteen years ago, Jamie Zawinski said this about Mozilla... I think it's also true for git:

"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. "

-- http://www.jwz.org/doc/easter-eggs.html

alwillis• 12 years ago

Yes, Git is powerful, but it’s not the only open source, distributed version control system out there. Google’s comparison between Git and Mercurial is worth reading: https://code.google.com/p/support/wiki/DVCSAnalysis

daigoba66• 12 years ago

This is the book which gave me my "ah-ha!" moment years ago. Everything clicked and suddenly git was, relatively, easy. I think a key to highly successful usage is understanding how git models the world of which this book does a wonderful job teaching.

saosebastiao• 12 years ago

I love the book, but their font colors for code/commands are terrible, almost to the point of unreadable. Most of time I give up on trying to see the impossibly light coloring.

anton_gogolev• 12 years ago

How many more tutorials on Git do we need? It's like article authors find it a "rite of passage" of sorts to explain Content-Addressable Storage, references and all kinds of whacky command-line keys.

erikb• 12 years ago

The way you expressed your concern is not very polite, but otherwise I have to agree. There are already thousands of tutorials about Git's fundamentals. It would be great if people like this article's author would spend their (actually quite good) skills into creating something new or improving the existing material instead of redoing work that is already done in all variations.

boomlinde• 12 years ago

Upvote because I think it's a perfectly valid point, but in my experience a wide range of perspectives on even simple things can be helpful to beginners and professionals alike.

scotch_drinker• 12 years ago

"We" don't need any Git tutorials. We could read the documentation But perhaps people don't write solely because of the audience's need. Writing a tutorial is the fastest way to ensure you more fully understand the subject. It is in fact a rite of passage in any topic when you can explain it to an audience with less understanding. Tutorials don't just serve the audience.

fauria• 12 years ago

I would add "git - the simple guide. just a simple guide for getting started with git. no deep shit ;)": http://rogerdudler.github.io/git-guide/

criswell• 12 years ago

I wish I knew about this months ago. So clear.

huhtenberg2• 12 years ago

Does anyone else find this to be quite hard to read? Just visually. Especially length of the lines and thinness of the font.

kevinpaladin2• 12 years ago

In chrome I changed the font-weight property to bold and width to 70% for the body tag, if you're curious how I managed to read it ;)

J_Darnley2• 12 years ago

No. You mean it uses all (well nearly all) the width of the screen? I am pleased to see that for once rather than stuffing it into some narrow column, the width of which I would have complained about 10 years ago.

huhtenberg2• 12 years ago

How big is your screen?

cabalamat• 12 years ago

I do as well.

augustk• 12 years ago

Yes, the site designer could (should) have used the CSS setting `max-width` for paragraphs (specifying `width` for paragraphs is, however, a big no-no in web design).

SimeVidas• 12 years ago

Here's how to fix it: https://www.youtube.com/watch?v=tIeCs8xwEzo

Steps:

1. max-width: 40em on wrapper element

2. font-weight increase from 300 to 400

3. include @font-face rules for Open Sans 400

Dowwie• 12 years ago

I don't know about you but when I see signs that read, "Do not Enter" I tend to take that into consideration. With that given, a site called "Wildly Inaccurate" may be just that.

kevinpaladin2• 12 years ago

I would recommend this guide here too : http://www.sbf5.com/~cduan/technical/git/

username42• 12 years ago

I like very much this introduction to git. Most of the other tutorials considers git as a magic black box. Here, it explains what is performed internally by most of the commands, without going into tiny useless details. This is probably not a good tutorial for build management processes and not enough to rewrite git, but it fits perfectly well my "hacker" mind. Thank you very much.

mateuszf• 12 years ago

Introduction with very similar approach: search for "Git from bottom up".

juggty_dev• 12 years ago

Worth for pro..

jammycakes5• 12 years ago

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best.

This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as advanced branch manipulation or hunk selection as with git add -p) are considerably harder with the command line than with GUI tools, simply because the command line doesn't give you a full enough picture of what you're doing.

mrcsparker• 12 years ago

What git gui do you recommend?

jammycakes5• 12 years ago

Atlassian SourceTree mainly. Git Extensions is also good if you need Visual Studio integration, though personally I find it visually a bit harsh.

chopin• 12 years ago

I work much with Java and Eclipse, eGit is a good choice here.

I mostly use the history view and the staging view (which lets you add/remove files). For complicated tasks the history view is a very valuable tool which I even use when I prefer to do something on the command line.

timblair• 12 years ago

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface.

I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.

jammycakes5• 12 years ago

Yes, but if you choose to use a CLI for your explanation, you are alienating an even larger portion of your readerbase who can't use/don't want to use the command line. I'm thinking in particular of Windows developers, who have to put up with a CLI experience that borders on the unusable (or at the very least requires a lot of work to get it set up), and a culture that views it as the domain of poseurs and prima donnas into the bargain.

In any case, I'm quite sceptical of the claim that you can teach Git more effectively through the command line alone. Here's why: the two most important concepts to understand before you can properly grok DVCS are (a) that your source history is a key integral part of your workflow and not just a sideshow, and (b) how revisions, changesets and merges relate to each other through the DAG. GUI tools do this very effectively by putting your source history, complete with a graphical view of your revisions, right at the front of your workflow. By contrast, the command line requires you to type git log --graph, effectively relegating it to a sideshow like in the bad old days of Subversion.

I can't help getting the impression that learning DVCS through the command line risks you ending up with an understanding of the subject that is fundamentally flawed. You see this in virtually every Git versus Mercurial debate that focuses on which one is better at branching and merging. Most of the arguments that I've seen leave me with the impression that the people who are making them haven't a clue what they're talking about.

mistermann• 12 years ago

Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?

voltagex_2• 12 years ago

Visual Studio Git Tools in 2012 and 2013, and then Atlassian SourceTree for the stuff VS can't do (VS's integration is based on libgit2 and has limitations)

thomaslangston2• 12 years ago

Sourcetree has been my favorite, followed by the default GUI installed from the git-scm.com. I've not been a fan of the VS extension because of performance (a want NCrunch and Resharper to have all my free cycles).

angersock• 12 years ago

TortoiseGit is pretty decent, though it doesn't have VS integration.

gnoway• 12 years ago

A lot of our developers use GitExtensions and like it. I don't personally like or use it, so I am not sure why it is preferred.

wldlyinaccurate2• 12 years ago

Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons:

1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details.

2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover all of them. This just confuses things for people who use GUI X when the guide only talks about GUI Y and Z.

3. It's much easier to write the guide using CLI examples. I wrote this over the weekend; I don't think I would have completed anywhere near as much of it if I had to keep taking screenshots, cropping them, uploading them, etc.

Besides, there are already plenty of other guides that talk about "how to use Git", "how to use GUI X to do Git feature Y". I wouldn't want to detract from the main goal of this guide which is to give people who are already comfortable with Git that extra push to "get" how Git models and interacts with your repository.

thomaslangston2• 12 years ago

Thanks for posting this guide. I hope to read it soon. Some thoughts on your response:

1) Sometimes the GUI illuminates and the console obfuscates. Logs and history are a lot easier for developers to understand in my experience from a GUI.

2) I'd suggest only using the included GIT GUI that comes with the download from git-scm.com. It is simple enough that it should map easily to another GUI, plus if they aren't using an embedded git everyone should already have it installed.

dahart2• 12 years ago

Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI.

But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were.

And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology.

Adding menu options with the names of things git does makes git slightly more discoverable, but not much easier to understand. For better or worse, I think understanding git from the command line point of view is (currently) critical to a deep understanding of git, even if you're using a git GUI.

MattBearman• 12 years ago

I had the opposite experience - coming from tortoise SVN, I tried a few GUIs for Git, but I never really got to grips with git until I started using the command line, and now I can't imagine going back to a GUI.

nahname• 12 years ago

Why not write one?

jammycakes5• 12 years ago

The thought has occurred to me. Just never got round to it, that's all...

grannyg00se• 12 years ago

Try this http://pcottle.github.io/learnGitBranching/?NODEMO

It's command line, but it's interactive and visual.

Start off by typing the command `levels` into the prompt at the bottom left.

seren3• 12 years ago

Quick question for people using git daily : do you push the features branches to a central repo or you simpy merge with --no-ff on a common dev branch ?

(There is no necessarily a right answer, but I'd like to know what is more usual)

krisgee• 12 years ago

Merge feature branches to a common dev branch then we branch off QA builds and RCs from there.

jimktrains2• 12 years ago

Push the feature branch if they existed for more than a day or so. They would be cleaned up by the merger/pull request verifier once in master.

bleuarff• 12 years ago

Every feature branch is pushed to the remote, with a pull request to merge into our integration branch.

SoftwareMaven2• 12 years ago

Feature branches are pushed to remote, where code reviews can take place. Once the code is reviewed and approved, the submitter rebases it onto master. We run a batched continuous integration, so once it's on master, it is expected it could be pushed into production at any time (batched because somebody has to do the push manually, usually after merging the code).

seren3• 12 years ago

Interesting because you'll get the cleanest history possible, however have you ever had an issue when the rebasing post code review would have had unintended effect (and not caught by a reviewer) ?

yxhuvud• 12 years ago

Neither. We rebase feature branches on top on master or release branch and enforce --only-ff. This assures a straight and clean history except for the cases when there are several release branches.

stephengillie7• 12 years ago

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.

We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe it's because we use MS technologies (IIS, .NET, MSSQL) but we were on TFS in a matter of weeks while Git still confused us after a month of use.

Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Several also think it's a waste of time. I don't disagree with them. I supported Git because I saw it on here. This solution doesn't our solve problems in our situation.

orkoden• 12 years ago

We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.

You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.

stephengillie7• 12 years ago

What backup? You mean we have to manually back up this system? Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source?

EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.

pyre5• 12 years ago

This:

This solution doesn't our solve problems in our situation.

is a far cry from:

Many of my coworkers feel it's a "piece of Git" (if you get my expletive).

Just sayin'. It's the same attitude that once caused an obnoxious movie-goer to get all hot and bothered (yelling at the screen, trying to explain it to his date, etc) over seeing a Mac on-screen because "it would have gone a lot faster if he was using a PC."

stephengillie7• 12 years ago

What are you just saying? I used both of those statements in the same paragraph to express my sentiment.

And some anecdote about some movie-goer being upset in front of his date? Are you accusing me of fanboyism for saying one solution didn't solve my team's problem, while the other does?

eddiedunn2• 12 years ago

We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command.

What?

1) You can configure your repo so only select users may use destructive commands on certain branches.

2) It's a _distributed_ content versioning system. Even if someone wiped out the main, "central", repository, all users will have a full local copy, a backup in effect.

Git has a horrible UI in many ways, but your apparent dislike of it smells more of incompetence and a naive buy-in of the full Microsoft ecosystem than anything else.

BTW, I didn't know what TFS was before checking on Wikipedia, but -- somewhat ironcially given your gripe -- TFS seems to have decent support for Git[1].

[1] https://en.wikipedia.org/wiki/Team_Foundation_Server#Git

[EDIT]: formatting

stephengillie7• 12 years ago

1. Some of this does look like ignorance on the part of my coworker who set up both. But why isn't that a default setting? Why give that permission to all users?

2. This is true only if other users keep local copies of the main repository, keep it updated, and don't mix it in with their code. You're making a lot of assumptions.

j_s• 12 years ago

Thank you for taking the time to share your anecdote, even if it is an unpopular one here. I hope Hacker News readers are understanding enough to recognize the need for buy-in from developers, and the necessity of a reasonable level of expertise when leading the switch to a distributed source control system. Sorry things didn't work out for your team; TFS branching and merging is so much more painful!

kasperset• 12 years ago

I found this video helpful as a beginner: http://vimeo.com/46010208

NDizzle• 12 years ago

Try not to take this as snark, but aren't hackers early adopters that do things on their own?

What's the point of a hackers guide to a thing that has been a thing for years?!

peterwwillis3• 12 years ago

I was writing something almost identical to this recently, for the general public but also for my co-workers who don't seem to understand the internals of Git at all. I'm sick of being "the Git guy" so this should help a lot.

pantalaimon• 12 years ago

http://xkcd.com/1053/

lloeki2• 12 years ago

Every tutorial I read falls in two camps:

1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add)

2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

Both equally fail at making people get git.

Having explained git an inordinate number of times to various people, I started writing here all I ever needed to introduce people to git in a few minutes†, but it takes longer to write than to explain hands-on and face to face. I'll complete this and make a gist out of it.

† For varying definitions of "few" and possibly "minutes", but honestly much less than people make it sound about git being a horrendous, unlearnable, complex system with a broken UI. It's simple, it's brilliant, you just have to set the bar right in between 1. and 2. when teaching it.

Crito4• 12 years ago

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me.

The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

skywhopper• 12 years ago

Agreed. I sorta knew the details before, but this article laid out the meaning of refs, trees, branches, and tags in a way that finally clicked for me. Would it have helped me get started with git back in the day when I only grokked Subversion? I can't say for sure now, but reading it today it clicked in a major way.

SoftwareMaven2• 12 years ago

This is true, if you actually care. Many people don't want to have to know the inner guts of how every tool they use works and just want to get their work done. It's unfortunate that git seems to (almost) require it (most likely because of its inconsistent UI (which has gotten better)).

todd8• 12 years ago

Your second paragraph hits the nail on the head. It's the Feynman Technique for learning.

See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...

voltagex_2• 12 years ago

Definitely interested in seeing your notes, even though there are a staggering number of git tutorials around.

ab• 12 years ago

I'd love to see your notes.

I found that when I was learning git there were two concepts that were crucial: understanding the staging area, and understanding the very basics of the DAG (not talking about tree objects, only spending just enough time to learn how to merge and rebase).

I have to say I was a little disappointed this tutorial didn't even mention the word staging, since it's pretty important to being able to use the interface.

Goladus• 12 years ago

2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

While true, there's also a category of git users who are no longer really "newcomers" but still use git primarily as a subversion emulator and want to learn more.

yuribit• 12 years ago

After learning Git, it is important to follow a branching model, I really appreciate the one proposed here http://nvie.com/posts/a-successful-git-branching-model

GUNHED_158• 12 years ago

This is my favorite one too.

tieTYT• 12 years ago

I've got the right level of understanding of Git to grok this article. I really liked how you talked about cherry picking before you talked about rebaseing. I'd like to request you include a section on why/when you need the rebase --onto argument.

wldlyinaccurate2• 12 years ago

I think the cherry-picking example borders on being too long and complex, but I'm hoping it still gives that "aha" moment when you realise that you've just done a rebase the hard way.

Great suggestion about --onto, thanks! That is a tough one to explain in a concise way, but I'll give it my best shot.

wmt• 12 years ago

"Once you start talking about branching, merging, rebasing, multiple remotes, remote-tracking branches, detached HEAD states… Git becomes less of an easily-understood tool and more of a feared deity. Anybody who talks about no-fast-forward merges is regarded with quiet superstition, and even veteran hackers would rather stay away from rebasing “just to be safe”."

"That’s why trying to understand Git in this way is wrong. Git doesn’t work like Subversion at all. Which is pretty confusing, right?"

These kind of assumptions of the reader can be quite off-putting. If you don't relate to assertions like this in the introduction, you start to wonder if the rest of the article is based on these assumptions.

I user SVN happily for years before moving to Git a number of years back, and the conceptual migration felt really smooth. It was just like SVN, but with some nice new native branching tools and features, like in SVN you were forced to merge trunk changes to feature branches, whereas in Git you also have the option to "move" i.e. rebase the branch onto a newer commit.

The rest of the article was very good!

aidenn0• 12 years ago

You are the very first person I have run into in any forum to say that moving from SVN to Git had a smooth conceptual migration (at least among people who have ever done anything more complicated than "git commit -a" which I assume you have if you've been using git for a number of years).

It is hard to come up with two systems that implement source control and are more different.

avinash240• 12 years ago

My biggest issue with git is it's CLI design. It's absolutely inconsistent. I don't believe the internals are an issue. If you really want to make git better, destroy the CLI and build a new one. Instead there are a million of these tutorials(the fact that there are a million tutorials should already hint at something being wrong), talking about internals.

alarra9• 12 years ago

Really good-looking illustrations. How did you make them?

lwilliamsjr• 12 years ago

Check out General Assembly's Git instructional, its pretty good: http://www.youtube.com/watch?v=DVDLoe_2MBc

A Hacker’s Guide to Git

Related Stories