A Hacker’s Guide to Git(wildlyinaccurate.com)
wildlyinaccurate.com
A Hacker’s Guide to Git
http://wildlyinaccurate.com/a-hackers-guide-to-git
22 comments
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.
The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.
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.
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)).
The way I see it, the CLI stuff is a distraction, when you "want to learn git", what you really want to do is understand how a DAG can be used for version control. Git is the idea. The standard/stock CLI is just one of many imperfect realizations of the idea that is git. Getting the handle of that particular realization of git is an unfortunate distraction that is needlessly weird in some cases.
Think of it like the difference between learning how an engine works, and learning how [some particular engine, in some particular car] works. The first is pretty simple and illuminating. The second has lots of annoying details and imperfections. If you want to work with cars, you learn the former first.
Think of it like the difference between learning how an engine works, and learning how [some particular engine, in some particular car] works. The first is pretty simple and illuminating. The second has lots of annoying details and imperfections. If you want to work with cars, you learn the former first.
Your second paragraph hits the nail on the head. It's the Feynman Technique for learning.
See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...
See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...
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.
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.
+1
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.
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.
Definitely interested in seeing your notes, even though there are a staggering number of git tutorials around.
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
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...
It's easy to mistake Pro Git as some sort of official Git reference when Googling, since it's hosted at
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.)
http://git-scm.com/book
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.)
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!
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.
Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.
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.
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.
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.)
I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.
The BSDs use massive monolithic repos that would be difficult to move entirely over to git. Instead of putting separate projects in separate repos, they consider all of their different projects to actually be "one project". These ludicrously massive repos have no business being in git; they would need to restructure their projects to effectively migrate.
This is not a scheme that should be emulated. Compartmentalization/modularization is not only useful at the micro-level in code, all of it's benefits are available when applied at a project/organization level.
For another point of view, consider this page: https://wiki.freebsd.org/GitDrawbacks I think nearly everything on that page is misleaded/misleading, or flat out incorrect, and they failed to identify the technical limitations with git that would apply to them. Other viewpoints are nevertheless useful.
(Actually the BSDs use a handful of massive monolith repos, but that is just nitpicking/)
(Disclosure, I work at a company that uses git at a _much_ larger scale than the BSDs use CVS. Many many times larger than all the OpenBSD repos combined (http://www.openbsd.org/cvsync.html). The trick? We don't have a handful of repos for the company, we have a handful of repos for each team. Each project gets it's own repo. Our build systems, deployment systems, and dev environments are tooled for this. One of the things it even allows is different teams using different VCS, if you're on a team with a bunch of luddites you can still use SVN for your code, and you will be able to build against other code and other code will still be able to build against yours.)
This is not a scheme that should be emulated. Compartmentalization/modularization is not only useful at the micro-level in code, all of it's benefits are available when applied at a project/organization level.
For another point of view, consider this page: https://wiki.freebsd.org/GitDrawbacks I think nearly everything on that page is misleaded/misleading, or flat out incorrect, and they failed to identify the technical limitations with git that would apply to them. Other viewpoints are nevertheless useful.
(Actually the BSDs use a handful of massive monolith repos, but that is just nitpicking/)
(Disclosure, I work at a company that uses git at a _much_ larger scale than the BSDs use CVS. Many many times larger than all the OpenBSD repos combined (http://www.openbsd.org/cvsync.html). The trick? We don't have a handful of repos for the company, we have a handful of repos for each team. Each project gets it's own repo. Our build systems, deployment systems, and dev environments are tooled for this. One of the things it even allows is different teams using different VCS, if you're on a team with a bunch of luddites you can still use SVN for your code, and you will be able to build against other code and other code will still be able to build against yours.)
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.
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.
Linux was using BitKeeper, a commercial DVCS. The raison d'etre for git was because the company behind BitKeeper revoked the license for the Linux guys to use it.
http://en.wikipedia.org/wiki/BitKeeper
Ah, I forgot that step.
They moved to a DVCS to solve some of the workflow issues, then Linus created git in large part because of the licensing issues.
Another detail missed in my previous post: If I remember rightly there were a couple of F/OSS DVCS's in development at the time, but he chose to write his own as some of them were not yet near stable and the others didn't quite work the way he wanted. I dimly recall some criticism for choosing a commercial product prior to git, and that decision was for much the same reasons git was created instead of using one of the other available options.
They moved to a DVCS to solve some of the workflow issues, then Linus created git in large part because of the licensing issues.
Another detail missed in my previous post: If I remember rightly there were a couple of F/OSS DVCS's in development at the time, but he chose to write his own as some of them were not yet near stable and the others didn't quite work the way he wanted. I dimly recall some criticism for choosing a commercial product prior to git, and that decision was for much the same reasons git was created instead of using one of the other available options.
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.)
(That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)
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
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
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
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.
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.
"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!
"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!
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.
It is hard to come up with two systems that implement source control and are more different.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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."
I heavily disagree with this.
When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the article points out), being able to actually see the various branches merging into each other, it all just made my life easier.
When I used to explain git to our new employees, it was in the CLI, but I quickly moved to explaining it GUI-first because I could teach all the concepts much more quickly and they clearly understood better that way.
I heavily disagree with this.
When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the article points out), being able to actually see the various branches merging into each other, it all just made my life easier.
When I used to explain git to our new employees, it was in the CLI, but I quickly moved to explaining it GUI-first because I could teach all the concepts much more quickly and they clearly understood better that way.
I don't disagree with you. ;)
Its a fair point that visualizing branches makes a big difference to people learning git. One reason that all git intro articles have these A->B->C diagrams.
FYI, the git CLI can give you branch visuals, e.g., 'git log --graph'. I was honestly thinking beyond basic branching when I wrote the above, but its worth remembering that the basics matter, and I also wouldn't even disagree with someone who claimed a GUI branch graph is easier to look at than a CLI branch graph, even though there may be no informational difference.
Still, I think the larger points I was trying to make stand:
- There is no git GUI that can replace the git CLI. There are many GUIs that give you pieces of git's workflow, but none complete enough to be a true one-stop-git-shop -- especially when it comes to more advanced workflows & repo administration.
- Git was not designed for a GUI, it was designed for a command line, and it shows in many ways. The CLI is the only place you can use all of git's power and understand all of git's features. It's also, as wildlyinaccurate was trying to explain, the lowest common denominator interface, hence the easiest to start basic explanations with. All people who have git have a CLI interface. Written with any GUI in mind, and a git tutorial immediately loses the majority of its potential audience.
Its a fair point that visualizing branches makes a big difference to people learning git. One reason that all git intro articles have these A->B->C diagrams.
FYI, the git CLI can give you branch visuals, e.g., 'git log --graph'. I was honestly thinking beyond basic branching when I wrote the above, but its worth remembering that the basics matter, and I also wouldn't even disagree with someone who claimed a GUI branch graph is easier to look at than a CLI branch graph, even though there may be no informational difference.
Still, I think the larger points I was trying to make stand:
- There is no git GUI that can replace the git CLI. There are many GUIs that give you pieces of git's workflow, but none complete enough to be a true one-stop-git-shop -- especially when it comes to more advanced workflows & repo administration.
- Git was not designed for a GUI, it was designed for a command line, and it shows in many ways. The CLI is the only place you can use all of git's power and understand all of git's features. It's also, as wildlyinaccurate was trying to explain, the lowest common denominator interface, hence the easiest to start basic explanations with. All people who have git have a CLI interface. Written with any GUI in mind, and a git tutorial immediately loses the majority of its potential audience.
I agree with your larger points.
But I would point out that the "advanced" functionality of git that you're talking about is something 99.9% of people will never use. Hell, even branches is something that most people don't use.
But I would point out that the "advanced" functionality of git that you're talking about is something 99.9% of people will never use. Hell, even branches is something that most people don't use.
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.
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.
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.
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.
But this isn't really a newbie's guide to using Git, as far as I can tell. There are probably other texts that are more suitable for that purpose. This text was pretty useful for me as a refresher-type thing to clarify the basic data types and inner workings of Git.
There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful!
I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!
There are many, many people who have no problems with using the command line, and who in fact by default prefer it to GUI tools. The guide itself provides graphs and visual means of understanding, and explains how these representations relate to the CLI tools. Very helpful!
I don't really agree with your complaint, because it seems like you're just saying "I would prefer to read a different kind of article," which is fine, but it's not a criticism. The argument about "alienating an even larger portion of your reader base" seems spurious; the author can write to whatever target audience they want!
My problem isn't with this article specifically. In fact I'll probably find it quite useful myself: it's one of the clearest presentations of Git's internals that I've seen so far. I personally have no problem with the CLI tools either: I myself use PowerShell (with Posh-Git), Git Bash, vim, you name it, and for most things I actually prefer it.
But the fact of the matter is that the Git community is churning out articles such as this one left, right and centre, while ones at a more readily accessible level are being neglected, and therein lies the problem. While there are many, many people who do not have any problems with the command line tools, there are also many, many people who do -- especially in the Windows and .NET world. The fact that we have a glut of command-line focused low-level Git tutorials and a dearth of more readily accessible ones, combined with the common attitude in the Gitosphere of "if you're using GUI tools you're doing it wrong," paints a picture of Git to people such as these of an ecosystem that is elitist, arrogant and user-hostile.
It's nothing to do with the kind of article I'd like to read. It's everything to do with bad marketing.
But the fact of the matter is that the Git community is churning out articles such as this one left, right and centre, while ones at a more readily accessible level are being neglected, and therein lies the problem. While there are many, many people who do not have any problems with the command line tools, there are also many, many people who do -- especially in the Windows and .NET world. The fact that we have a glut of command-line focused low-level Git tutorials and a dearth of more readily accessible ones, combined with the common attitude in the Gitosphere of "if you're using GUI tools you're doing it wrong," paints a picture of Git to people such as these of an ecosystem that is elitist, arrogant and user-hostile.
It's nothing to do with the kind of article I'd like to read. It's everything to do with bad marketing.
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.
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.
It's command line, but it's interactive and visual.
Start off by typing the command `levels` into the prompt at the bottom left.
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?
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)
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).
TortoiseGit is pretty decent, though it doesn't have VS integration.
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.
Why not write one?
The thought has occurred to me. Just never got round to it, that's all...
What git gui do you recommend?
Atlassian SourceTree mainly. Git Extensions is also good if you need Visual Studio integration, though personally I find it visually a bit harsh.
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.
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.
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/
I wish I knew about this months ago. So clear.
I would recommend this guide here too : http://www.sbf5.com/~cduan/technical/git/
Introduction with very similar approach: search for "Git from bottom up".
Does anyone else find this to be quite hard to read? Just visually. Especially length of the lines and thinness of the font.
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.
How big is your screen?
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.
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.
19 inch
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
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
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 ;)
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).
I do as well.
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.
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.
> 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
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
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.
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.
1. When I set up Git on my Linux server only the user that initiated the repo had access to it. It was too locked down, seeing as external users didn't even have read/cloning permission. (A minimal amount of googling solved all my problems, though.) Your problem sounds to me as another PEBCAC on the part of your coworker.
2. I'm not making all the assumptions you claim. First of all, as soon as you clone a repo you have a local copy. You need this clone in order to be able to even work with the code, so it would be quite weird if employees deleted their clone after editing, committing, and pushing their changes. I'm not even sure what you mean with "mix it in with their code". It's a VCS -- if you don't like a change reverting it is trivial.
All in all, I understand why users might have problems with Git. It has a steep learning curve. I think it has a horrible command line UI. It might not have worked well for your company, even if you had a competent admin set up the repos. However, I would prefer if you could argue your point based on the actual merits and faults of Git, rather than based on ignorance.
2. I'm not making all the assumptions you claim. First of all, as soon as you clone a repo you have a local copy. You need this clone in order to be able to even work with the code, so it would be quite weird if employees deleted their clone after editing, committing, and pushing their changes. I'm not even sure what you mean with "mix it in with their code". It's a VCS -- if you don't like a change reverting it is trivial.
All in all, I understand why users might have problems with Git. It has a steep learning curve. I think it has a horrible command line UI. It might not have worked well for your company, even if you had a competent admin set up the repos. However, I would prefer if you could argue your point based on the actual merits and faults of Git, rather than based on ignorance.
Your second statement shows a complete lack of understanding of VCS in general.
>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.
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.
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.
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.
What backup? You mean we have to manually back up this system?
I am aghast at hearing you say this. Yes, of course you have to run backups. Like with everything else important on your systems.
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?
You don't have to spend 'hours' backing up a git repository. We typically use a bare git repo for the central point that is pushed to / pulled from by the individual developers. It is just a bunch of files, and so can be backed up easily.
You really don't sound like you know what you are doing.
I suggest you hire an experience system administrator (not just another devops) that understands the importance of backups.
I am aghast at hearing you say this. Yes, of course you have to run backups. Like with everything else important on your systems.
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?
You don't have to spend 'hours' backing up a git repository. We typically use a bare git repo for the central point that is pushed to / pulled from by the individual developers. It is just a bunch of files, and so can be backed up easily.
You really don't sound like you know what you are doing.
I suggest you hire an experience system administrator (not just another devops) that understands the importance of backups.
So,
- You have picked a new piece of technology
- You have no single person who understands it
- You expect it to work the same way the existing tech worked
- You don't have a backup system in place
- You imagine what the security settings should be for your specific use-case and then assume they are already in effect
- You switched to the new system before understanding it
I don't think software is the issue here.
[Edit: formatting]
- You have picked a new piece of technology
- You have no single person who understands it
- You expect it to work the same way the existing tech worked
- You don't have a backup system in place
- You imagine what the security settings should be for your specific use-case and then assume they are already in effect
- You switched to the new system before understanding it
I don't think software is the issue here.
[Edit: formatting]
I understand your gripe (though I don't agree with it; TFS comes out of the box with permissions that only allow administrators to force push in a way that rewrites history, but more importantly, this data was never lost, you would only need to look in the reference log to find this), but surely you're not seriously suggesting that one not backup their TFS server? Please do back that up, even if you're using TFVC moving forward!
Are you telling me that you don't backup anything? You just expect the version control system to (e.g.) magically recover itself from a hardware failure on your server?
It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.
It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.
It's a version control system that doesn't include backup functions? It's like a RAID-5 where you have to tell it to rebuild a new disk.
"Backup" is not a component of revision control software. If one has such 'backup functions' they're just window dressing.
What you must be talking about (well, I hope anyway) is the capability of a revision control system to be backed up on the fly, similar to the tools used to backup a live subversion repo without causing corruption. Git has such functionality; simply do a fetch from a remote repo, then backup the result.
If you're expecting revision control systems to include some sort of "backup suite", sorry, this is *NIX, not Microsoft. The tools do a particular job and it's up to you to plug that into your infrastructure, including your pre-existing backup infrastructure, which i'm sure your company must have. It would be laughable if they didn't have backup infrastructure already.
What you must be talking about (well, I hope anyway) is the capability of a revision control system to be backed up on the fly, similar to the tools used to backup a live subversion repo without causing corruption. Git has such functionality; simply do a fetch from a remote repo, then backup the result.
If you're expecting revision control systems to include some sort of "backup suite", sorry, this is *NIX, not Microsoft. The tools do a particular job and it's up to you to plug that into your infrastructure, including your pre-existing backup infrastructure, which i'm sure your company must have. It would be laughable if they didn't have backup infrastructure already.
I've seen a company with contracts guaranteeing 100% uptime, while running things off of a single MS server with no backups. It's entirely possible for software companies to be this stupid.
> It's like a RAID-5 where you have to tell it to rebuild a new disk.
Well, you do have to give it a new disk first, right? Or do you expect the RAID-5 array to automate the process of purchasing and installing a replacement disk?
Well, you do have to give it a new disk first, right? Or do you expect the RAID-5 array to automate the process of purchasing and installing a replacement disk?
> Also if you do wipe your repository, restore it form your backup.
Git is distributed. The "backup"† is another dev doing a git push -f. Also, git reflog. The argument just does not hold water. (Also, do backup your VCS server anyway.)
If you want to keep rogue devs in check, set up a Gitlab instance, and use protected branches and merge requests.
† Read me correctly, it's not a backup, it's just part of the resiliency of git. Proper backups should be made il all cases.
Git is distributed. The "backup"† is another dev doing a git push -f. Also, git reflog. The argument just does not hold water. (Also, do backup your VCS server anyway.)
If you want to keep rogue devs in check, set up a Gitlab instance, and use protected branches and merge requests.
† Read me correctly, it's not a backup, it's just part of the resiliency of git. Proper backups should be made il all cases.
git is a distributed system. Everyone else has a full copy of the repository. therefore everyone actually has a backup.
Everyone else only has a full copy of the repository if they actually check out a copy and keep it local. That's apparently not how my coders do their workflow.
The most usual way to work with git is to pull a local copy of the whole server using "git clone"[1]. The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
What?!?
Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
Going by the rest of this thread, I wouldn't rule out the possibility that they are doing something insane like committing multi-gigabyte objects regularly, and then only checking out with a low clone depth.
I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).
I've seen people attempt that before; without fail people who are deeply in centralized version control land and do not bother to understand git before attempting to switch to it (because it is trendy, or because people under them won't stop complaining about using svn in 2014).
> Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control?
You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
Before TFS, we didn't even have everything in Visual Source Safe.
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!
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."
> 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."
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?
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?
I'm saying that "doesn't solve my problems" != "a piece of 'git'"
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.
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
This is my favorite one too.
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.
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.
Great suggestion about --onto, thanks! That is a tough one to explain in a concise way, but I'll give it my best shot.
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)
(There is no necessarily a right answer, but I'd like to know what is more usual)
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.
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).
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) ?
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.
Every feature branch is pushed to the remote, with a pull request to merge into our integration branch.
Merge feature branches to a common dev branch then we branch off QA builds and RCs from there.
Check out General Assembly's Git instructional, its pretty good: http://www.youtube.com/watch?v=DVDLoe_2MBc
I found this video helpful as a beginner: http://vimeo.com/46010208
[deleted]
Really good-looking illustrations. How did you make them?
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.
"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.
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.
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.
Worth for pro..
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.
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?!
What's the point of a hackers guide to a thing that has been a thing for years?!
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]
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.