11 ms·

A Hacker’s Guide to Git

372 points by sidcool 12y ago

EinLama 12y 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 http://www.git-scm.com/book
- morsch 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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.)
    - ams6110 12y ago
      I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.
      - BugBrother 12y ago
        Isn't OpenBSD a special case? Most really security conscious organizations seem to use outdated tools, because the new tools haven't been vetted/verified/etc yet. (That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)
      - dspillett 12y ago
        As did Linux before Git, but Linus and the core team around him were finding the process getting too cumbersome and bottlenecked. Linus "scratched the itch" and produced git both specifically to fill that set of needs and with the intention of it being generally useful for other projects they were concerned with. OpenBSD's kernel development is presumably run differently (IIRC there is a much smaller number of people trying to directly feed into it for a start, which was a key problem with Linux at least at the time Git was birthed) so processes and tools that fit their needs will look different. Either they haven't had enough trouble with the older tools/processes that the effort of an infrastructure change is worth sinking time into, or they have other concerns with the alternatives (security, as someone has mentioned above, and code maturity concerns may be involved, though the latter much less now as it has been pretty solid for some time), or maybe they intend to move but just haven't decided on an alternative yet.
- daigoba66 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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/ http://rogerdudler.github.io/git-guide/
- criswell 12y ago
  I wish I knew about this months ago. So clear.
huhtenberg 12y ago
Does anyone else find this to be quite hard to read? Just visually. Especially length of the lines and thinness of the font.
- kevinpaladin 12y 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_Darnley 12y 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.
  - huhtenberg 12y ago
    How big is your screen?
    - dspillett 12y ago
      No so big that resizing a window when content is too wide for comfort stops working... Less facetiously: I wish more pages would give me the choice rather than forcing the content into a fixed-width format unnecessarily, or if they don't mind the extra coding (especially if their design is well thought out enough to make it easy) have a fixed width setting by default with the option to turn it off (I've seen this done by giving the user the option flipping stylesheets via a control at the top of a page) like some support different font size and colour/contrast options.
    - J_Darnley 12y ago
      19 inch
- cabalamat 12y ago
  I do as well.
Dowwie 12y 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.
kevinpaladin 12y ago
I would recommend this guide here too : http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/
username42 12y 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.
deleted 12y ago
[deleted]
mateuszf 12y ago
Introduction with very similar approach: search for "Git from bottom up".
juggty_dev 12y ago
Worth for pro..
jammycakes 12y 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 12y ago
  What git gui do you recommend?
  - jammycakes 12y 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 12y 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 12y 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.
seren 12y 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 12y ago
  Merge feature branches to a common dev branch then we branch off QA builds and RCs from there.
- jimktrains2 12y 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 12y ago
  Every feature branch is pushed to the remote, with a pull request to merge into our integration branch.
- SoftwareMaven 12y 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).
  - seren 12y 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 12y 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.
stephengillie 12y 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.
- j_s 12y 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!
- orkoden 12y 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.
  - stephengillie 12y 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.
kasperset 12y ago
I found this video helpful as a beginner: http://vimeo.com/46010208 http://vimeo.com/46010208
NDizzle 12y 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?!
- peterwwillis 12y 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.
- deleted 12y ago
  [deleted]
- pantalaimon 12y ago
  http://xkcd.com/1053/ http://xkcd.com/1053/
lloeki 12y 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.
- Crito 12y 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 12y 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.
  - SoftwareMaven 12y 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)).
yuribit 12y 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 http://nvie.com/posts/a-successful-git-branching-model
- GUNHED_158 12y ago
  This is my favorite one too.
tieTYT 12y 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.
- wldlyinaccurate 12y 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 12y 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 12y 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 12y 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 12y ago
Really good-looking illustrations. How did you make them?
lwilliamsjr 12y ago
Check out General Assembly's Git instructional, its pretty good: http://www.youtube.com/watch?v=DVDLoe_2MBc http://www.youtube.com/watch?v=DVDLoe_2MBc

372 points by sidcool 12y 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 http://www.git-scm.com/book

morsch 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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.)
  - ams6110 12y ago
    I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.
    - BugBrother 12y ago
      Isn't OpenBSD a special case? Most really security conscious organizations seem to use outdated tools, because the new tools haven't been vetted/verified/etc yet. (That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)
    - dspillett 12y ago
      As did Linux before Git, but Linus and the core team around him were finding the process getting too cumbersome and bottlenecked. Linus "scratched the itch" and produced git both specifically to fill that set of needs and with the intention of it being generally useful for other projects they were concerned with. OpenBSD's kernel development is presumably run differently (IIRC there is a much smaller number of people trying to directly feed into it for a start, which was a key problem with Linux at least at the time Git was birthed) so processes and tools that fit their needs will look different. Either they haven't had enough trouble with the older tools/processes that the effort of an infrastructure change is worth sinking time into, or they have other concerns with the alternatives (security, as someone has mentioned above, and code maturity concerns may be involved, though the latter much less now as it has been pretty solid for some time), or maybe they intend to move but just haven't decided on an alternative yet.
daigoba66 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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/ http://rogerdudler.github.io/git-guide/

criswell 12y ago
I wish I knew about this months ago. So clear.

huhtenberg 12y ago

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

kevinpaladin 12y 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_Darnley 12y 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.
- huhtenberg 12y ago
  How big is your screen?
  - dspillett 12y ago
    No so big that resizing a window when content is too wide for comfort stops working... Less facetiously: I wish more pages would give me the choice rather than forcing the content into a fixed-width format unnecessarily, or if they don't mind the extra coding (especially if their design is well thought out enough to make it easy) have a fixed width setting by default with the option to turn it off (I've seen this done by giving the user the option flipping stylesheets via a control at the top of a page) like some support different font size and colour/contrast options.
  - J_Darnley 12y ago
    19 inch
cabalamat 12y ago
I do as well.

Dowwie 12y 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.

kevinpaladin 12y ago

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

username42 12y 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.

deleted 12y ago

[deleted]

mateuszf 12y ago

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

juggty_dev 12y ago

Worth for pro..

jammycakes 12y 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 12y ago
What git gui do you recommend?
- jammycakes 12y 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 12y 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 12y 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.

seren 12y 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 12y ago
Merge feature branches to a common dev branch then we branch off QA builds and RCs from there.
jimktrains2 12y 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 12y ago
Every feature branch is pushed to the remote, with a pull request to merge into our integration branch.
SoftwareMaven 12y 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).
- seren 12y 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 12y 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.

stephengillie 12y 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.

j_s 12y 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!
orkoden 12y 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.
- stephengillie 12y 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.

kasperset 12y ago

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

NDizzle 12y 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?!

peterwwillis 12y 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.
deleted 12y ago
[deleted]
pantalaimon 12y ago
http://xkcd.com/1053/ http://xkcd.com/1053/

lloeki 12y 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.

Crito 12y 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 12y 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.
- SoftwareMaven 12y 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)).

yuribit 12y 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 http://nvie.com/posts/a-successful-git-branching-model

GUNHED_158 12y ago
This is my favorite one too.

tieTYT 12y 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.

wldlyinaccurate 12y 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 12y 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 12y 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 12y 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 12y ago

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

lwilliamsjr 12y ago

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