A Hacker’s Guide to Git
wildlyinaccurate.com
wildlyinaccurate.com
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.
The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.
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.
See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...
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.
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.
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.)
Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.
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.
(That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)
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.
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.
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.)
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. "
"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!
It is hard to come up with two systems that implement source control and are more different.
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.
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 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.
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.
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!
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.
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) 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.
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.
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.
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.
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.
It's command line, but it's interactive and visual.
Start off by typing the command `levels` into the prompt at the bottom left.
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.
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
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.
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.
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.
[1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
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).
It's a version control system, not a backup solution, in the same way that RAID-5 is not a backup solution.
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.
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?
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.
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.
- 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]
> 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."
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?
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
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. 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.
Great suggestion about --onto, thanks! That is a tough one to explain in a concise way, but I'll give it my best shot.
(There is no necessarily a right answer, but I'd like to know what is more usual)
What's the point of a hackers guide to a thing that has been a thing for years?!