Skip

Git For Grown-ups
February 11, 2014 5:35 PM   Subscribe

You are a clever and talented person. You create beautiful designs, or perhaps you have architected a system that even my cat could use. Your peers adore you. Your clients love you. But, until now, you haven’t *&^#^! been able to make Git work. It makes you angry inside that you have to ask your co-worker, again, for that *&^#^! command to upload your work. It’s not you. It’s Git. Promise.
posted by jenkinsEar (97 comments total) 64 users marked this as a favorite

 
I give it about 3 years before everyone decides that some new version control system is better, and that Git just won't do anymore.
posted by thelonius at 5:38 PM on February 11 [8 favorites]


I learned a new vocabulary word, andragogy.
posted by larrybob at 5:41 PM on February 11 [3 favorites]


ctrl-f DAG
ctrl-f directed acyclic graph
phrase not found

I too labored under confusion, as I wanted to learn git but found all these sources telling me about init, add, commit and so on, or describing these specific overhyped workflows, without explaining what was going on, but then I found this site explaining how git was a tool to manipulate a DAG, and I understood. I haven't even gotten proficient with practical git usage yet as I'm only on it for small personal projects and forced to use SVN for work, but now I understand what is going on.
posted by save alive nothing that breatheth at 5:47 PM on February 11 [16 favorites]


Oooh. This is relevant to my interests.
posted by brundlefly at 5:50 PM on February 11 [2 favorites]


Dang, I was just getting the hang of Subversion.

I do a lot of Drupal work and Git is fairly important, but I am having such a terrible time and the Windows clients are just awful. I shouldn't have to install CYGWIN or run a *NIX variant just for version control. Git is from the devil and I think I'll just keep swapping out database dumps.
posted by cedar at 5:51 PM on February 11 [1 favorite]


I love git, but git is definitely not the last source control system we will use, and thank god for that because I also hate it. My recipe for the ultimate source control system: Smoothly whisk git into perforce, then pour a float of usability.

Google's got it's own source control system, and I would like for them to someday open source it.
posted by jjwiseman at 5:52 PM on February 11


Google's got it's own source control system, and I would like for them to someday open source it.

Sorry to disappoint you, but Perforce and git. The fiddly bits may be custom, but the UI is pretty stock.
posted by GuyZero at 5:59 PM on February 11 [2 favorites]


I don't get the hate people have for git. I mean, it's not that complicated to use, is it? And it always seems to work perfectly, in my experience. Certainly compared to Subversion, which was constantly fucking me up. And don't get me started on Microsoft's horrible source code control system(s).
posted by JeffL at 6:02 PM on February 11 [8 favorites]


save alive nothing that breatheth - I thought I was the only one who had that aha moment!

cedar - check out SourceTree.
posted by djb at 6:04 PM on February 11 [2 favorites]


Wow, I recognize the majority of the individual words in this post, and yet have no. Earthly. idea. what's going on.

Weird weird feeling.
posted by hearthpig at 6:07 PM on February 11 [7 favorites]


jjwiseman - are you thinking of Mondrian, Google's Perforce-based code review system? It begat Rietveld, which was forked into Gerrit.
posted by djb at 6:10 PM on February 11 [1 favorite]


I've liked SourceTree for free clients, but on my work Win7 box I can't get it to launch without crashing. On a Mac it's great though.

The thing about Git is that it's exceptionally powerful and flexible. Which makes it a great power tool that can either save your ass or lop your hand off. If your team leadership isn't fluent in Git and doesn't have a good branching strategy, and I've worked on teams like that, you can wind up in a considerable amount of chaos.

It's like that Git game that was posted here a while back. It's good training, but some of the examples were so complicated and tangled that I wanted to nuke the repo and start over from the last trusted branch commit.

It'd be great to have out-of-the-box locked down Git systems to mitigate that. Identify whether you're making a feature branch or a hot fix or whatever, the client makes the branch for you, and it is locked out of merging anywhere other than where it's supposed to go.

I mean, it's not that complicated to use, is it?

The basic commands are not, no. But even on a small team, you can wind up with complicated situations where pushing stuff back up comes with some anxiety. I've seen changes disappear in a puff of smoke.

That talk Clay Shirky gave awhile back on laypeople using Git was more than a wee bit optimistic. Non-tech people have trouble understanding SharePoint. Forking and branching and what-the-fuck-does-rebase-mean is too much to ask of them.
posted by middleclasstool at 6:11 PM on February 11 [6 favorites]


Seconding SourceTree. It doesn't make sense unless you grasp the rudiments of version control in general (and of Git in particular). Which becomes a kind of circular problem. But it's pretty great.

And, since there are no really great SVN clients for Mac (and the good-enough ones are payware), it kind of makes Git the default version control system in offices with majority Mac users. If there was something like Tortoise SVN available for Macs, I don't think Git would have nearly the traction it does among web devs. Tortoise is really great.
posted by ardgedee at 6:14 PM on February 11 [1 favorite]


Perhaps also of interest, especially if you ever find yourself needing to create patches, esp. if you need to make several related patches at once, is Stacked Git. Stacked git lets you keep a lot of balls in the air all at once, and to "polish" commits so that anyone looking at your commit history will think you're some kind of superhuman genius who almost never makes mistakes (you can use it on top of a subversion working directory, if you add '.svn/' to your .gitignore) Users proficient at git may wonder what use stacked git is, but you can easily use stacked git to manage a set of patches without really knowing git very well. If you've ever used something like quilt for making patches, stacked git is a lot like that, but quite a lot better.
posted by smcameron at 6:17 PM on February 11 [3 favorites]


Okay seriously, this is like reading a Mornington Crescent thread.
posted by hearthpig at 6:17 PM on February 11 [25 favorites]


architected
posted by Flashman at 6:18 PM on February 11


I was thinking of git + perforce + g4 + for sure Mondrian, plus the filesystem magic that gives a read-only view of the stuff you didn't check out merged seamlessly with the stuff you did check out. Plus whatever else I assume they've done in the year or two since I've been there.
posted by jjwiseman at 6:22 PM on February 11


I've been using git everyday for about two years. I love it but easily understand why others hate it. It's very unix-y in that it's very powerful and user friendly but choosy about its friends. Confusing answers about it on sites like Stack Overflow don't help.

The proof is in the pudding: I have lost exactly zero work to git. I can't say that about subversion or (shudder) mercurial.
posted by double block and bleed at 6:22 PM on February 11 [5 favorites]


Uhhh, hey everyone. Programmers spend a lot of time comparing text files line by line to see where the bad juju got in. When they do this they like to avoid looking at the WHOLE file, instead just a "diff," being a list of lines that are different between them. This is also sometimes called a "patch" but only when you're going to use that list of differences to turn one file into another file.

A version control system is a tool for managing patches. Many of them prevent you from having to work with the patches yourself, instead you're like, I wonder what changed between last Thursday and today? and it will show you.

Git is one such creature.

Being that the choice of a version control system influences a lot of things about your workflow, programmers get CURIOUSLY ATTACHED to the one that works for them.
posted by LogicalDash at 6:23 PM on February 11 [16 favorites]


I love git and can't imagine going back to svn. Most of us are always juggling two or three things and keeping good feature branches makes things so much easier. In a team approach, it's often easier to have one person responsible for merging up the develop and master branches.

Also, I think life is easier if you skip using pull and use fetch and merge instead. Make merging an everyday task and it won't seem as scary later.
posted by advicepig at 6:25 PM on February 11 [4 favorites]


git is microcosm of everything that's glorious and terrible about programming all in one example. Robust, powerful, and elegant, with an obnoxious learning curve and arcane UI as a barrier to entry.
posted by captaincrouton at 6:27 PM on February 11 [4 favorites]


I like git, and use it for all my personal dev. I tried to use mercurial but there wasn't any compelling reason (imo) to choose over git which is way more popular these days. And for some reason, git just feels more solid than mercurial ever did. Git is loverly - I've never had an issue with it - pretty rock solid (as you'd hope/expect ;-).

But - last dev team I worked with, we started with git and decided to instead to switch "back" to using subversion, as it's simpler to some folks and we found the tools integration (eg. Tortoise as noted above but also to IntelliJ, etc.) to be superior/simpler.
posted by parki at 6:28 PM on February 11


RCS 4 LYFE.

I wanted to like that link, but I'm a sysadmin, not a coder, and apparently even in an article about understanding your needs, nobody understands my needs. I have never needed to branch or fork ever, and I might have merged...once? Subversion works for my team really, really well. I'd love to learn what it is that people love about git, but I suspect I'm just blinded to its appeal because it wasn't made for people like me and nobody understands that non-coders need version control too.

(Related: Totally was messing around yesterday looking for a way to get RCS to edit keywords inside Microsoft Word documents, so I could marry my sysadmin sensibilities with my living-in-corporate-America reality. Got about three whole commits in before it trashed the file. It's hard out there for a nerd.)
posted by sldownard at 6:29 PM on February 11 [4 favorites]


I've never thought that Git was all that arcane at least as compared to Perforce. I used Perforce for seven years and never really internalized the syntax.

Lets see if I can do it from memory:

>p4 integ -t //source_branch/.../myfile.foo //target_branch/...

I think that's right but I may have gotten the source and target flipped.
posted by octothorpe at 6:31 PM on February 11 [1 favorite]


Since we're here, I'll share my favorite trick. This lists all of the files that you've changed since you branched from master:

git diff --name-only `git merge-base origin/master HEAD`

So, of course you can do something like this:

git diff --name-only `git merge-base origin/master HEAD` | xargs mvim -p

to open them all in tabs in mvim

I don't know how to do that as a one-liner in Subversion. In fact, I don't know how to do that at all in Subversion.
posted by double block and bleed at 6:32 PM on February 11 [7 favorites]


Also if you are scared by "directed acyclic graph" a "graph" is a bunch of circles connected by lines, "directed" means the lines have arrows, "acyclic" means you can't get back to where you started if you obey the arrows. Easy peasy.
posted by save alive nothing that breatheth at 6:33 PM on February 11 [4 favorites]


I use git for our lab's open source projects. I can't wrap my head around the GUI, but feel mostly okay with the basics on the command line. Every time I commit, though, I feel a pang of uncertainty about the process. Somehow it works and my commits go where they are supposed to.
posted by Blazecock Pileon at 6:34 PM on February 11 [1 favorite]


....A version control system is a tool for managing patches. Many of them prevent you from having to work with the patches yourself, instead you're like, I wonder what changed between last Thursday and today? and it will show you.....


Thanks for the explanation LogicalDash. I was with Hearthpig. I even googled to try to find out what it was exactly and didn't understand what I found either.

Now it all makes sense enough to follow the general conversation.
posted by Jalliah at 6:35 PM on February 11 [1 favorite]


All of this stuff makes my brain hurt.

I liked programming more when it was solitary.
And if my computer crashed, it was an opportunity to rewrite my craptastic code.

(the above statements are lies. I just HATE having religious arguments, and nerds are CRAZY zealots about everything source control)
posted by DigDoug at 6:37 PM on February 11 [3 favorites]


Yay! The author of the article is a friend of mine. I have one of her woodblock prints up on the wall of my office.

> RCS 4 LYFE.

Word. And regarding your MS Word problem, if you're using docx, put something in your workflow to unzip the file and perform version control on the document content xml file, then zip it back up into a docx. You're welcome.
posted by scruss at 6:39 PM on February 11 [3 favorites]


Git's "plasticity" makes it a lot easier to have the revision logs tell the story you want them to tell, which makes the history more readable and gives developers more license to experiment (without fear of their failure being etched in stone for all time).

But in my experience, that same feature becomes a liability when people start to step on each others' toes around the "main" branches. In a world where not every committer knows all the quirks, it becomes very hazardous to be hiding or deleting history.

Mercurial certainly has its issues; my shop names the branches after the JIRA bug they're associated with, which leads to a lot of branches, and Mercurial historically has performance issues when dealing with many different branches. Nevertheless, it's comforting to know that it's really hard for someone to do something in Hg that loses them more than a day or two of work, or requires a Ph.D. in graph theory to reverse.

Tools come and go, but I think the best legacy of Git and Hg will be how they can be used as "reference" repositories. Your team can use Diffy.js™ or whatever the sexiest VCS will be in 2017, but it'll have an adapter to be able to push to a Git or Hg (or similar) repository losslessly, and in a way that fits your Web 7.0 development style into the branching conventions that everyone else understands.

The pinnacle will be when your local system can apply advanced merge logic ("Oh, you're merging changes between two files in your Java source directory? I'll check to see if anything you modified affects the semantics of the other person's changes.") without putting that burden on the "main", dull-as-dishwater Git repo.

I see the same future for Maven, incidentally, based on how phenomenal it's been as a "reference" implementation for dependency definition/management, and yet how atrocious it is at building anything but JAR files and paint-by-numbers webapps.
posted by Riki tiki at 6:41 PM on February 11 [1 favorite]


So apparently I'm a heathen for loving mercurial? I've never had a problem with it until SourceTree, which had some revision which bonked my shit, and I eventually had to recode some stuff, but ever since the update to it, it seemed fine.

That said, I liked TortoiseHG better than SourceTree. I just like that feeling of leanness and how easy to just right-click and choose what I want from a submenu. Git does admittedly terrify me.
posted by symbioid at 6:43 PM on February 11 [1 favorite]


I like git, and specifically I like git better than mercurial, which makes you go extra lengths to be able to perform mundane tasks and even then is kind of grumbly about it ("what do you want named branches for? Just clone the repo and there's your branch! What's a stash?"), but I always kind of assume that anyone who loves git without qualification is either still traumatized by SVN, hasn't been using git long enough, or is a zealot. Someone said to me the other day, concerning git's inconsistent syntax between commands: "just imagine each git command is a separate program!" There's no reasoning with someone like that. Not to mention git's prickly refusal to accept truncated commands just feels like a fuck you rather than a reasoned policy decision, like someone who's right in front of you on a cold day as you're entering a building and looks you in the eye as they go in but then doesn't hold the door for you.

Small things, yeah, and after a while they stop bothering you for the most part, but I can see why beginners get a bad taste in their mouth.
posted by invitapriore at 6:43 PM on February 11 [5 favorites]


A good reason to not accept truncated commands is that it complicates adding new commands.
posted by scatter gather at 6:46 PM on February 11


Perhaps also of interest, especially if you ever find yourself needing to create patches, esp. if you need to make several related patches at once, is Stacked Git.

This is what I use Git for, applying and creating patches. It kills me that I spend more time fighting with version control than I do writing the code. Most times the patches are trivial, but the commit process is difficult (for me).

... check out SourceTree.

I can't keep it running on a high end Windows 7 machine. I love the concept, it's like FTP for Git, but not stable for me.

Every time I commit, though, I feel a pang of uncertainty about the process.

This. Frankly, it terrifies me.
posted by cedar at 6:47 PM on February 11


We're still stuck on CVS at work because of like 10 years of history in it and your normal large-corporation institutional resistance to change. It's probably my least favorite thing about my job.
posted by valrus at 6:47 PM on February 11


It's nice that everyone is using this as an opportunity to air their opinions about git and SCM in general, but is it just me or is TFA kind of ... useless?
posted by murphy slaw at 6:50 PM on February 11 [2 favorites]


I thought it was okay, but I tend to agree with one commenter on the site that "in order to be able to design a workflow, one must already have some idea of Git’s capabilities and conceptual model."
posted by scatter gather at 6:53 PM on February 11


I wouldn't send the article to someone who didn't understand Git, but t do like that Gitflow diagram.
posted by michaelh at 6:55 PM on February 11


I wanted to like that link, but I'm a sysadmin, not a coder, and apparently even in an article about understanding your needs, nobody understands my needs. I have never needed to branch or fork ever, and I might have merged...once?

I'm a sysadmin and I use git everyday. Puppet? Git. Nagios? Git. Site code? Git. Internal tools? Git. Dotfiles? Git. Router confs? Git. Everything is git. I branch and merge like a motherfucker all day long.

I can't imagine going back to SVN. Git is the single most important tool I have. I call myself sysadmin too... but in modern times, we're all coders.
posted by tracert at 6:55 PM on February 11 [6 favorites]


I just feel like the interface to git is needlessly hard to use. Mercurial does something very similar with much more attention paid to user interface, consistency, and discoverability.
posted by grouse at 7:00 PM on February 11 [2 favorites]


valrus, I hope you at least know about cvsps. I used to use cvs a lot a long time ago (even contributed some patches to it circa 2000 or so.)
posted by smcameron at 7:02 PM on February 11


If you'd ever been forced to use CMVC, you'd never complain about any other source control system.
posted by octothorpe at 7:03 PM on February 11 [4 favorites]


I dislike git and the git approach. For some reason many of my colleagues attempt to use it on top of Perforce in some weird source-control cosplay mode.

That said, I don't actually care who else uses it. I only think about it because sometimes people will get too excited about it and propose moving the whole company over or something and if I was actually forced to use it my day-to-day happiness would drop. As long as its some optional thing for fetishists I don't care :)

But the reason people get excited about it one way or the other is it does have a slightly different philosophy to many other systems. That, and like your editor, source control is a daily tool for a programmer and so you get attached to it. (While I don't want to use git, I'd be far less upset being forced to use git over Perforce than I would being forced to use Eclipse or vim over emacs, for example).
posted by wildcrdj at 7:08 PM on February 11 [1 favorite]


I feel so much less scared of doing anything with git because it seems simple enough to repair anything, whereas with svn I too often end up cp'ing out relevant files and nuking the working copy.

I also run Linux at home, it has a tendency to break itself in odd ways and you end up losing some random functionality until you can figure out how to fix it, so I basically went fuck that shit and all my config files / gconf dumps and whatever else I figure needs it git got regularly these days.
posted by save alive nothing that breatheth at 7:11 PM on February 11 [1 favorite]


I'm a sysadmin and I do some coding. Almost all of the stuff I code is on my own, so I'm not merging anyone else's code. I've tried to make it a habit of crating a repository and some of my scripts are in git, but it always feels like overkill. For my scripts, git seems like a nice idea but I have yet to notice much benefit, personally.
posted by Loudmax at 7:15 PM on February 11


Hmm. I use git daily and constantly, and still don't understand half of it. The syntax is... I won't say capricious, but solipsistic.

It's also an unending and consistent source of joy in my daily workflow, even after years of use. It's extraordinarily good at what it does, and no matter what strange corner I paint myself into, there's always a lovely git solution a quick google search away, even if I have to look up the strange syntax every single time.

(I've tried a bunch of times to give SourceTree, Tower et al a fare shake – but I always feel like it's a completely useless layer. I'd love to understand what people find faster / easier about using them.)
posted by ~ at 7:18 PM on February 11 [1 favorite]


As a dev-ops person dragging my team into git, I had high hopes for this article. As someone in higher ed, it was clear that the article fails to scaffold the argument. If you had struggled to learn git and finally pushed through, it sorta makes sense. If you haven't figured it out, it seems useless.

LogicalDash's post above was the best explanation I've seen in a while. I like to think of feature branches as stories. What happened to which things? Merging takes these stories and tries to make a consistent account of these stories. Most of the time, you hold your breath and it somehow works. After years of svn, you never believe it can work, but it does. Now and then, it doesn't and you have to go in and make sense of conflicting stories. After you figure it out, you commit it.

If you keep googling, you'll find all kind of secrets that people swear are the key. Ignore all these. These shortcuts are what make learning git hard. You really want to know how to clone or init. Learn about branching, checking out, and merging. Never commit -a or pull. If you branch or tag often, you can always go back. Use them like save points in a video game.
posted by advicepig at 7:21 PM on February 11 [1 favorite]


I have been stuck with accurev for the last few years and I'm honestly surprised that I haven't thrown myself off a bridge yet.
posted by Hairy Lobster at 7:22 PM on February 11


And yes, git could use a cleanup on using consistent language, but like English, you learn the rules of grammar and forget you ever had to learn them.
posted by advicepig at 7:22 PM on February 11 [1 favorite]


It wasn't clear to me that anything in the article was a distinctive problem with git or with teaching people git. I think the article makes more sense if you recognize that git is just the popular version control system of the moment and so it's become expected that you're familiar with it, and so the article is aimed at people who have some degree of discomfort with the whole idea of version control.

Basically it's aimed that the people you don't want to hire.
posted by Kwine at 7:22 PM on February 11


Hahaha CMVC was the worst. I know I've consoled myself with the thought "at least it's not CMVC" when using Bugzilla, Jira, Perforce, CVS, Subversion, Mercurial, and Git.
posted by scatter gather at 7:26 PM on February 11 [1 favorite]


This article's stance on "grown-ups" is offensively condescending. I'm a grown-up. I may also be a virtual neckbeard hacker who sort of lives and breathes all the weird command line badness of git, but I'm still an adult. I think her real point is that git is pointy and awkward and unpleasant to learn, particularly if you've got other work to do. Totally agree. But no need to phrase it in such belittling language.

git's amazing largely because of GitHub. In retrospect, a social network for coders was an obvious thing to build. Strange it took 15 years for someone to get it right. (I'm frowning disappointedly at you, SourceForge). I wish Mercurial had won out over git in the DVCS wars, but git's the winner, and it's OK.

Google's Perforce install is so idiosyncratic I think it's fair to call it a separate VCS. Even when I left some seven years ago the g4 wrapper to p4 was already indispensable and Google was paying people full time just to keep the Perforce servers running. I can't imagine where it's gone now.
posted by Nelson at 7:26 PM on February 11 [6 favorites]


My other complaint about the article is that it assumes you can make heads or tails of the workflow stuff she throws up at the end. I love gitflow, but I wouldn't try to gain anyone's buy in by just throwing that down. Then she throws in a completely decontextualized deployment workflow with some stick figures and says, see it's humanizing and easy!
posted by advicepig at 7:30 PM on February 11 [1 favorite]


Google's Perforce install is so idiosyncratic I think it's fair to call it a separate VCS

A good point, especially once you consider all the other home-grown tools as part of the ecosystem. When I say "Perforce" above, I really mean Google Version Control.

The github aspect of git is not useful to me, since all of my coding is at work aside from a few tiny one-offs at home.
posted by wildcrdj at 7:31 PM on February 11


Nelson is totally on to something with the github thing. We use git because its the way github lets us share work on open source programs.
posted by advicepig at 7:33 PM on February 11


Git Cheatsheet.

But mostly just use SourceTree.
posted by Combustible Edison Lighthouse at 7:34 PM on February 11 [2 favorites]


I guess I don't understand the "I'll break it" fears that people have about git. Sometimes it's needlessly complex, and the GUI tools (including TortoiseGit) are only passable at best, but I can't say I've ever had it lose my work entirely without any warning that what I was about to do might be a bad idea.

I have had trouble finding what I did with some work because I'm sloppy about branching or had a hairy merge because I was lazy and didn't keep a branch up to date, but never just poof and lost.

In both my programming and sysadmin roles I find it invaluable. It is easily adaptable to version control for conf files, ala etckeeper among many other tasks, and a lot of the tools out there adapt to that kind of use reasonably well. No master server or anything required, just optional, there if you want it.

Somehow I always felt like CVS and SVN were more difficult and scary, although those were quite the improvement to rcs and that may have been more due to my own lack of serious interest in learning how to use them well.

Those of you who are Mercurial lovers ought not forget about Bitbucket (which has also supported git for quite a while now) if you want Github-ish functionality for your Mercurial projects.
posted by wierdo at 7:38 PM on February 11


Google was paying people full time just to keep the Perforce servers running.

I guess maybe this is unusual for smaller companies but when you've got over 42,000 employees I think a software company can afford to put a couple of them on managing source control full-time. What's mind-bending is that it all used to be running on one physical machine. It was the biggest server in the company.
posted by GuyZero at 7:40 PM on February 11 [2 favorites]


Plus whatever else I assume they've done in the year or two since I've been there.

So not to spill the beans, but yeah, it got awesomer.
posted by GuyZero at 7:43 PM on February 11 [2 favorites]


One of the things I really like about git is that it's simple. :-) That is, it's a really simple data structure on disk with a primitive model for version control on top of that. In fact, that's what git originally was supposed to be. You weren't supposed to use "git", you were *supposed* to use something else that used the git tree/index utilities as a backend.

But, as it turned out, people(linus, other kernel devs) started using git directly[1], and gradually wrote their own wrappers to do common tasks (or augmented the primitive ones that existed). Most of the arcane commands were borne from scripting the common tasks people wanted to perform at the moment -- not from trying to make the system cohesive to an outsider.

Thus the downside of git. Given its origin, it makes sense -- but its user interface is complete amateur-hour: "git reset --soft/--hard/--merge/--keep/--overeasy/--mediumrare/....". If the original script writer had only just described what was happening instead of how they felt about it at the time. :-)

[1] In some ways this reminds me of lisp and s-exps, which were also originally meant to be substrate, not the actual thing you programmed in.
posted by smidgen at 8:19 PM on February 11 [5 favorites]


save alive nothing that breatheth: "ctrl-f DAG
ctrl-f directed acyclic graph
phrase not found
"

Then you want Git for ages 4 and up, which uses Tinkertoys as a visual to explain the whole DAG thing.
posted by pwnguin at 8:55 PM on February 11


The day I stopped fearing git was the day that someone showed me git reflog. It was the day I realized git wasn't just a tool for managing code but a no-shit time machine. Once I understood its power (among other things the ability to traverse potential timelines of code and rewrite history itself) and accepted the responsibilities that comes with that (to never interfere with another time traveller's subjective history), everything became clear.

Also, my partner is in graduate school for conflict resolution and that phrase is basically a trigger for all the bad merges I've resolved.
posted by OverlappingElvis at 9:06 PM on February 11 [5 favorites]


Git is really really good at being git.

Luckily "being git" happens to be useful for a lot of purposes, but it seems as if it wasn't designed for any of those purposes, it was just designed to be itself. And to really understand it you have to kind of throw away all the things you hope to use it for and learn what it *is.* Then you can sit back and think about ways that "being git" can be useful to you.

I don't know if I'd recommend it to someone if they didn't have other reasons for wanting to use it (the team uses it already, they want to use Github, etc). If I was just going to sit down and grab a version control system to do my version control I'd probably grab something that wasn't so painful to learn, something that catered to my needs. But if you have to learn it (like I did, for work) it's pretty cool and powerful once you know it.

I know git pretty well. People at work often go to me for help with weird git problems. But I am definitely not a fanboy. (And I don't know how to do a tenth of the things git can be made to do. Maybe not a hundredth.)
posted by edheil at 9:07 PM on February 11


I also like git because I'm a Javascript programmer and so am naturally drawn to problematic systems with a lot of power as long as you know how not to use them.
posted by OverlappingElvis at 9:09 PM on February 11 [8 favorites]


Why don't people like using GUIs with git? I feel like it's a billion times easier not to fuck up git with a GUI. Like, what's a situation where you're using a GUI for git and then cursing because you can only do that thing in terminal and you've gotta figure it out again?
posted by oceanjesse at 9:40 PM on February 11


smcameron: "Perhaps also of interest, especially if you ever find yourself needing to create patches, esp. if you need to make several related patches at once, is Stacked Git. ...Users proficient at git may wonder what use stacked git is"

It mostly sounds like git stash, which features commands like push and pop.
posted by pwnguin at 9:45 PM on February 11 [1 favorite]


I don't get the hate people have for git.

To quote Douglas Adams on another topic, git was not so much designed as congealed. Particularly the front end.

Linus threw it together and it shows.

Also it encourages people to make branches and is therefore evil, but that's something a lot of modern version control systems are guilty of.
posted by Tell Me No Lies at 10:38 PM on February 11


Git GUIs are a lot more fuckup-prone than the commandline. They hide the nice speed of Git behind slow crufty UI. They often encourage you to do things that are unsafe, like automagically rebasing after you pull, or retrying a failed push with --force. SmartGit is anything but.
posted by rustcrumb at 10:52 PM on February 11 [2 favorites]


Also it encourages people to make branches and is therefore evil

how else would you have a team of people working on different parts of a codebase coordinate their work?
posted by russm at 11:00 PM on February 11 [2 favorites]


how else would you have a team of people working on different parts of a codebase coordinate their work?

Feature flags are an approach formalized in the good old days of Flickr, when they wanted to deploy continuously, but had a product too large for each developer to run their own local version. If everyone’s working on the same system, you use feature flags. If everyone can poke at their own local mini-systems, you use branches.
posted by migurski at 11:16 PM on February 11


Feature flags as described in that blog post can be done far less error prone with branches. Divide your production system into three sets, with their own tracking branch: a test server, a few smoke test servers, and normal production servers. Each server is watching for changes to it's corresponding branch. Workflow is simple: Developer commits new code to test branch. If no errors are observed, merge test into smoke branch. If there's no scaling issues or uptick in error rates, merge smoke into prod. Zero extra lines of code written, and zero lines of code removed from working systems.

Feature flags can be useful during eventually consistent deployments to production, where your code needs to be prepared for the database possibly changing schema. I vaguely recall reading that Flickr also threw out schemas, essentially implementing them in software as well to fit their continuous deployment model (think key-value store).

Branches go all the way back to CVS, which was written in the heady days of everyone working on the same UNIX server in 1986. Branching has an aura of evil about it precisely because of CVS's less than stellar conflict resolution, but feature flags don't solve the problem of two developers making conflicting changes at the same time.
posted by pwnguin at 12:28 AM on February 12 [1 favorite]


Yeah, branches are a feature, not a bug. CVS gave them a bad reputation because it's merge support was so awful that it turned merging a branch into this huge palaver that people went out of their way to avoid.

Personally, I didn't really like this article. There's nothing in there that can't be done with almost any modern source control system: You could write exactly the same article using subversion commands instead, or even CVS (ugh). Which in turn means that someone using her approach will *still* come out the other end not knowing anything more than a bunch of cookie-cutter commands which might, maybe, map to the workflow they wanted. I'm not sure this is much of an improvement frankly - it's still effectively cargo-culting their use of git.
posted by pharm at 2:36 AM on February 12 [1 favorite]


Branches are a bad thing? That's the first I've ever heard that. My last job had something like 400 branches off of the main trunk in Perforce which is probably excessive but still, I can't figure out how you can do forward work without development branches separate from the release branch.
posted by octothorpe at 4:51 AM on February 12


Git is the mind-killer
Git is the little-death that brings total obliteration....
posted by mikeburg at 5:40 AM on February 12 [3 favorites]


Branches are essential in a distributed VCS, unless you want to purposely step on other contributor toes and break tests in mainline. Branch, (code, run tests, commit)^n, [squash]merge/rebase, run tests, push. Feature flags are an accident waiting to happen and pollute the code with distracting logic; forking the codebase will just lead to pain later down the line, although with git (specifically github) pull requests can ease the pain of this.

I use git all day, and for that reason i have the following in my .bashrc: export HISTIGNORE='? :?? :git @(pull|push|ci|co|st|diff|log|tree|dtree):ls:ls -l:&'

Whilst we're on the subject, can i encourage anyone using git to use verbose commit messages, thanks.

If you want to understand git i would recommend the O'Reilly "Version Control with Git" book, which goes into some depth with the underlying structure.

I realise this comment probably read like latin to some...
posted by lawrencium at 5:54 AM on February 12 [1 favorite]


Yeah, my git 'aha' moment was understanding that I could create local branches and switching between them would not be painful.
posted by RobotVoodooPower at 6:04 AM on February 12


Also, using git-bisect to binary-search for broken code is pretty boss.
posted by RobotVoodooPower at 6:10 AM on February 12 [3 favorites]


I have fumbled with Git, but only with small projects. Never anything multi-developer and I'm sort of afraid of it, to be honest.

I wish that there was something like Accurev in the FOSS market. Accurev is amazing and it's the best source control software I've ever used.
posted by DWRoelands at 8:36 AM on February 12


I'll also stand up for branching.

The key to success to branching is to name them descriptively and to delete them once you don't need them any more. If you merge a branch in without squashing the commits into a single commit, the history of the branch you merged into will have the history of the branch you merged in. You lose nothing.

If you want to keep it named so you can go back to it without knowing the long meaningless hash string, tag it.
posted by advicepig at 9:28 AM on February 12


I have been stuck with accurev for the last few years and I'm honestly surprised that I haven't thrown myself off a bridge yet.
...
I wish that there was something like Accurev in the FOSS market. Accurev is amazing and it's the best source control software I've ever used.

In conclusion, source control is a land of contrasts.
posted by murphy slaw at 9:52 AM on February 12 [3 favorites]


So, when I started my undergrad thesis I knew I wanted a backup somewhere, and since I was writing it in LaTeX, source control made a lot of sense. Then I'd have proof it was my work, backup and the ability to revert if I deleted something and changed my mind. Ask MeFi recommended Git and Mercurial. I tried setting up Git, but it was a pain, and Mercurial + Tortoisehg was both easy, and gave me access to Bitbucket's unlimited private repositories for students and academics (Bitbucket now offers this for git as well).

But man, Tortoisehg is easy to use. Typically I just make the repository on Bitbucket first, then clone it to my computer with a copy-pasted command. Then I can just right click it at any time and commit something, then sync it. The only time I have had a problem was when I accidentally committed a huge amount of raw data and had to get help reverting that so it didn't use up all the space in my repository, which I understand wouldn't have been possible at all in git.
posted by Canageek at 10:00 AM on February 12


Yeah, most of the objections I've run into over branches are about how they're misused. Any codeline needs an owner and a raison d'être. Most everywhere I've worked had some variant of the rules "don't be afraid to branch; branch as late as possible, but no later; branches need an owner and reason to exist." When you get away from those sorts of rules you end up with a lot of extra work and confusion. Branches come and go, but only a few have persistent lives (trunk, testing, dev).

As to the article: poorly-aimed, I think.
posted by introp at 11:00 AM on February 12


Dang, I am late to the party, but this was one of the things I spent a lot of time with at Software Carpentry. This is scientist-oriented, but one of the better Git introductions I know, from the Software Carpentry materials by Greg Wilson.

I'm working on my own, slightly faster-paced version of his materials, but it's not ready yet :(
posted by onalark at 11:04 AM on February 12 [1 favorite]


Actually, if somebody wants to give me feedback on what I've got so far (first two links are working), I'd be grateful.
posted by onalark at 11:06 AM on February 12


We're still stuck on CVS at work because of like 10 years of history in it

I don't know what the CVS->git path is like, but CVS->Subversion is pretty painless. The cvs2svn tool has been around for a long time and is well-tested, and will convert all your CVS history into a SVN repo. Here is a nice HOWTO that covers using it, while maintaining backwards compatibility with CVS if you really need to do that for some old crusty who won't upgrade.

Personally I haven't really found a compelling reason to switch from Subversion to git, at least for my personal projects, and at work we use Subversion because it has good integration with a wide variety of IDEs and everyone seems to understand it. Maybe there are some advantages to git that I'm just not aware of though.
posted by Kadin2048 at 6:57 PM on February 12


Kadin2048: "Personally I haven't really found a compelling reason to switch from Subversion to git, at least for my personal projects, and at work we use Subversion because it has good integration with a wide variety of IDEs and everyone seems to understand it. Maybe there are some advantages to git that I'm just not aware of though."

IMO most of the advantages to git are just having a nice set of bonus commands.

* git grep: greps your git repo for instances of a regex. This replaces the hacks like ack-grep that try to guess at what is and isn't relevant to your project based on file extensions. This is literally something I use daily in my role as a senior system administrator.
* git bisect: find the commit that caused a regression in log n tests
* git cherry-pick: apply one specific commit elsewhere to your current branch
* git shortlog: summarize the change history for a week / month whatever, and collect it by author

Nothing about SVN prohibits these, they just never thought to add them.
posted by pwnguin at 7:08 PM on February 12 [1 favorite]


I use Git every day. I have for a few years. I have thousands of (public) commits on GitHub. I rely on it, and I love it. I don't have the faintest idea of how to use it at the command line. And I don't have to. I save stuff, and every so often I go to my GUI-based Git client, peck out a few lines describing my changes, and submit them. That's it.

Just download GitHub's client. Try it out. It's really easy. You can learn all of the command-line stuff if and when you need to. But you probably won't need to.
posted by waldo at 7:28 PM on February 12


waldo: "Just download GitHub's client. Try it out. It's really easy. You can learn all of the command-line stuff if and when you need to. But you probably won't need to."

I just did try it. It's a really nice tool. I like the integrated diff that looks like the one on the github website. I also like clicking on my branches instead of typing it or pasting them. I think I'll use it it for the routine and mundane parts of working with git. However, it may be too limited for a lot of users.

One example is rebasing. I work with 20+ other Rails developers. Our project is in the "explosive growth" phase of development. We work in topic branches, create pull requests for code review and peer testing and then merge those pull requests into master. Our master branch is a busy place. Part of working with so many others is keeping our master branch log clean of BS commit messages. I push many commits to my topic branch while I'm developing. Some are checkpoints where I've coded up a section and have it working to that point. They let me go back to a place where I know the code was working when I've veered of into insanity. I also make bookmark commits for when it's time to go home and I don't want to risk losing an hour's worth of work. The point is that nobody wants to see all of those BS commits in the master branch. It's a good way to win our dreaded "fail trophy"*. That's why rebasing and squashing commits down to a single one with a meaningful commit message is important. Is there a way to rebase with the GUI? I didn't see it.

There are a lot of fancy console commands that I use to unleash the power of git but I understand that not everyone wants or needs to learn them. I'm all for a GUI tool that makes life easier. Just understand that you might not be making use all of the powerful tools that are available to you.

Speaking of GUI tools, command-line git comes with one. It's called gitk. It visualizes the branching history of your repository. I use it all the time as a sanity check, especially before merging into master.

* - There are some disadvantages to working with people half my age.
posted by double block and bleed at 5:02 AM on February 13


Hey everyone! And shout out to scruss for letting me know about the conversation.

I read all of your comments. GREAT! feedback on the article. Thanks for taking the time to read through it and voice your opinions. (I found the ones that said I didn't know how to structure an argument particularly delicious.)

For those of you who did find some value in the article, yay! (Andragogy is one of my favourite words.) There are so many approaches to learning Git, that I'm delighted I was able to expand your understanding of how to approach something that may have previously seemed inaccessible. Yes, all of the articles that were referenced are great ones! Schwern (git for ages 4 and up) is one of my heroes for conference presenting.

For those who got that "for grown-ups" was a reference to adult education, yay! (The original title of the piece was "Git Makes Me Angry Inside". It was delivered as a conference presentation at DrupalCon last year.)

And yes, the article works best for those who actually work on a team and are being "forced" to adopt version control. In the Drupal world: this is typically jr. devs with no open source experience, designers, (technical) project managers, QA, (etc).
posted by emmajane at 10:21 AM on February 13 [4 favorites]


double block and bleed: However, it may be too limited for a lot of users. [...] Is there a way to rebase with the GUI? I didn't see it.

There is no way to rebase with GitHub's GUI, no. GitHub's client is no doubt too limited for a lot of users, but relative to the initial post, it does everything that most Git newbies are going to need to do. Spending a few weeks or months interacting with Git in this manner will provide a much easier path to understanding it than looking at a series of charts and graphs and command-line references, all for a system with which one has no real experience. At the point that somebody thinks "gosh, I need to rebase," that's a pretty good time to learn about git rebase. There's a lot to be said for easing into it, especially for non-technical folks.

We saw this with Linux on the desktop, too. For a long time, especially in the nineties, there was a misplaced paternalism that said "people should learn how to use the command line, then how to administer their system with command-line tools, and only and then learn how to use X11 (KDE, Gnome, whatever). It turned out, unsurprisingly, that people didn't really want to do that. What worked much better was Mac OS X, where people could occasionally dip into Terminal.app, and then maybe use it regularly, and then eventually gain fluency at the command line. Now Mac OS X is the operating system of a supermajority of programmers and folks in the technical creative class, something that would have made for a shocking forecast in 1999. If Linux was the only options, I posit there would be far fewer people in the technical creative class today.
posted by waldo at 11:52 AM on February 13


Yes. GUI tools are great for what they are. Not everyone enjoys devouring man pages. Being able to use the command line is a skill that not everyone needs to have but it's good that it's there for those who do.

I used Linux for over a decade and only just recently switched to a Mac for work. I have a much younger coworker who is our resident git expert and a True Linux Zealot. He (somehow) reads our company outlook mail with pine. He seems to think everyone else should, too. He's a good guy and very talented but that alpha-geek more-slashdot-than-thou shit was tiresome even back in the 90s. I hope I didn't come across like that.
posted by double block and bleed at 2:38 PM on February 13


Any codeline needs an owner and a raison d'être. Most everywhere I've worked had some variant of the rules "don't be afraid to branch; branch as late as possible, but no later; branches need an owner and reason to exist."

This pretty much covers it for me. Branches are extremely easy to get in over your head with. In my ideal (corporate) world, there would be a review meeting to justify any new branch with "No" being the default answer.

The only reason ever to take a branch is so that you don't have to deal with instability on the mainline. People often claim they're doing it so that they themselves won't destabilize the mainline, but really, how hard is it to have a boolean shut your feature off? And either way all you've done is postpone the instability to the end-of-project merge, which is usually when you can least afford it.

My guidelines are:

< 10 developers:
No branches, keep ball peen hammer for people who break the build.

11-30 co-located developers:
No branches, switch to sledge.

31-100 developers:
Branches only for features that demonstrably will not cause conflicts when merged.

100+:
Welcome to hell.


At one point at Cisco we had 1000+ people working on the same release. We had branches of branches of branches so that individual teams wouldn't disturb their larger team who in turn wouldn't disturb their larger team who really didn't do anything with their time other than negotiate code swaps with other teams who were stomping on the same code so everyone could play nice together as much as possible before the truly epic month (the whole month) everyone spent trying to fold it all back together.

Not that I have a better solution for the whole mess, but branches should be the tool you reach for when nothing else will do.
posted by Tell Me No Lies at 2:48 PM on February 13 [1 favorite]


Tell Me No Lies: "People often claim they're doing it so that they themselves won't destabilize the mainline, but really, how hard is it to have a boolean shut your feature off?"

It's not hard to write, but you've just doubled the number of states you should be accounting for in integration tests.
posted by invitapriore at 2:54 PM on February 13 [2 favorites]


It's not hard to write, but you've just doubled the number of states you should be accounting for in integration tests.

I would say that is nicely offset by not having to test the integration of all those includes and changes to system-wide APIs that you made to support your "isolated" feature.
posted by Tell Me No Lies at 5:17 PM on February 13


At one point at Cisco we had 1000+ people working on the same release.

There's your problem... Now imagine those 1000+ people were all using feature flags and picture picking the bones out of the epic mess of "if ( SOME_FEATURE_ENABLED )" statements it would result in.

If you want to enforce a branch policy then try "you must keep your branch up to date with whatever line it was branched from"
posted by lawrencium at 4:34 AM on February 14


Tell Me No Lies: I would say that is nicely offset by not having to test the integration of all those includes and changes to system-wide APIs that you made to support your "isolated" feature.

If you have a test suite that tests all those system-wide APIs then what's the problem? If you *don't* have such a test-suite then surely the problem isn't the branches, it's the fact that you don't have a comprehensive test suite.
posted by pharm at 6:55 AM on February 14


« Older On Mammography   |   The True Story of America's... Newer »


This thread has been archived and is closed to new comments



Post