Github teaches us that "great" is better than "good" | Hacker News Reader

Github teaches us that "great" is better than "good"

joncanady.com

33 pointsgeneralk18 comments

Ok, that's a nice story, but a bit short on meat. On the whole, it reads almost like an advert for Tender Support. Is the author affiliated?

Nope, Jon Candy is not part of ENTP. We do really appreciate the kind words he said about Tender though :)

Man, I almost wish I was.

Yeah, I know it kinda reads like an advert, sorry about that. But I'm still a little shocked when I come across support systems that work as opposed to the common OSS-project style of "File bug in Bugzilla. Wait. Wait. WONTFIX."

This might not be the place to ask, but I'm curious and I've never quite understood: why/how do you use version control systems like GitHub? I've never worked with it in a project, and I've never quite seen the point: I keep all of my files backed up, my partner does the same, and so if we need to go back and look at something it's not hard. We edit directly from the server, so there's no need to sync information. So: why would I use something like Git or Mercury?

I'm not attempting to troll: I'm just curious. Since Github is YCombinator (I think, right?), I'm sure a lot of people use it. So: as somebody who works as part of a two-man group, who keeps his files all stored and backed-up offline, what does Git get me?

Some reasons you might want to use it:

1) can you roll back a certain feature easily if there is a bug with them? 2) can you and your partner edit the same files at the same time without clobbering your changes? 3) do you have a record of all of the features added and bugs you have fixed by datetime 4) are you and your partner always in sync? 5) if you really just edit files while on server do you ever want to develop software while disconnected from the web? 6) copying to backup folders is really cumbersome 7) can you easily create branches of your software if you want to try out something new and experimental?

The usefulness of version control increases exponentially with the number of developers you have but I even use it as a solo developer due to many of the reasons above.

Expanding on the issue of finding bugs, everyone should check out git's "bisect" feature for when regressions crop up: http://lwn.net/Articles/317154/

It really helps that git has all the history locally stored, too - doing an intensive bisect search with something like perforce would take quite a bit longer.

Also, it's "Mercurial." "Mercury" is the former name of a pretty awful commercial bug tracker now known as HP Quality Center.

Not to mention a planet, an element on the periodic table, and a badass Roman god (perhaps in exactly the reverse order, in terms of which came first).

I'm pretty sure the order was: Roman god; name of planet; alchemists' name for the element, which has persisted to the present day. See http://www.encyclopedia.com/doc/1O27-mercury.html for some evidence.

Github is YCombinator (I think, right?)

Not AFAIK: "We had a talk and agreed right away: no outside funding. We wanted to keep the whole company."

http://37signals.blogs.com/products/2008/07/how-github-used....

GitHub is not a YC company.

Version control is not the same thing as a backup. They're completely different, and you need both.

Git is hard to explain to someone who hasn't lived it. It's as if you've got a button that saves the state of your entire project, instead of just saving one file at a time. Each time you press the button (which is called committing or making a commit) you save all the changes that you've made to any file in your project directory or its subdirectories, along with your name and the time and the date and a note describing what you did. The resulting series of commits is better than just a bunch of backups: it's a very long series of annotated undos which (ideally) stretches back to the beginning of your project. Making a commit is much, much easier than copying your entire project directory over and over, so you end up with a lot more date-stamped backups than you ever would otherwise.

Only it's better, because this history is editable: you can rearrange the order of your commits, break one commit apart into two or more, smash several of them together, edit their descriptive messages, undo some of them while leaving others, group a bunch of them together and mail them to someone else as patch files, and so on. You can edit the history of your software's development after the fact to turn it into a clear story that other people can understand.

But wait, there's more! You can create multiple different versions of your project ("branches") and work on them in parallel. With one command you can switch from working on the production version of your code to a development version, or to a crazy experimental version. And you can move commits from one version to another. Of course, every developer has their own private copy of each of these branches, and commits can be moved from one developer to another. If two developers change the same file in incompatible ways, the system warns you so that you don't inadvertently destroy each other's work.

You need to find some screencasts of someone using git for something real. I'm not sure what to recommend. Maybe someone else can link to one. If I can't find any, I've been thinking of trying to make some myself.

I love stories like this. We're thinking for our startup that everybody can have the same job title: Customer Support.

Github stands as one of the more inspirational companies. Their model - business/customer services/innovation - can be applied to a few other markets as well.

I definitely wish them luck, as an avid user (though only at the $7/month level).

Is it just me, or did the author basically use

  %w(GitHub Github).rand

to pick his spelling throughout this article?

For the record:

  No, ma'am.  Yes, sir!
  
  Github      GitHub
  FaceBook    Facebook
  Javascript  JavaScript
  Blackberry  BlackBerry

Author here: Random number generators have logic behind them. My capitalization prefs there did not.

No worries. I was just amused at how rapidly the case of the 'H' oscillated. (Judging from my comment's current score, apparently I was the only one; I think that including some actual working code should make comments downmod-proof.)

My list of examples was meant to show that you are in very good company; major publications get this sort of thing wrong all the time. Keep up the good blogging!

Reply on news.ycombinator.com