I Don’t Git GitHub Yet, But I Hope I Will

by Rick Ross on December 25, 2009

GitHub logoWe’ve been using subversion at DZone for several years, and looking backwards I can comfortably say it was a solid improvement over the CVS system we used before. Lately, the newer “git” and the popular GitHub project hosting site appear to be coming on strong, and I’ve started to use them in OSQA – an open source project I’m becoming involved in.

I’m willing to trust that there’s something really useful about git, something that qualifies it as a leap forward and not just a “newer must be better” alternative. If I’m completely honest, however, then I have to admit I don’t yet understand what it is? GitHub, in particular, confuses me.

The project I’m interested in has been forked dozens of times (since forking a project repository is apparently the first thing you do to get started.) As a result, there are now dozens of independent commit streams and lines of development branched off the primary original repository. It feels chaotic and disorganized.

github-networkTo be sure, the Network Graph Visualizer feature is one of the best tools I have yet seen for viewing such a set of mostly diverging (and occasionally re-converging) streams. You can see each commit in a timeline view that also shows how and when the streams are being merged back together.

What escapes me, however, is any understanding of how this supports and encourages teamwork? While it appears to make it easy to working independently and resynch from time to time, my guess is that you’ll need more than GitHub to work effectively as a team. A dashboard that shows the various commit messages is simply not enough for most teams to function together in a well-organized, coordinated effort. Merely having a wiki available to the project as part of the GitHub service is not really enough for most teams – it can too easily remain unused or under-used. I still want something like Trac or Jira to help discuss and prioritize development tasks.

I’m sure I don’t yet fully understand how git and GitHub make it easy to merge these independent streams. It is very cool that git and GitHub are aware of and respect the ancestry of the project, which may actually be what represents the major leap forward. I just need to get my hands dirty with this tool and find out how it works in practice.

I’d be delighted to hear the pros and cons of your experiences with git and GitHub (or Gitorious and other git-related tools and services.)

{ 17 comments… read them below or add one }

Tom Brander December 25, 2009 at 2:01 pm

Well as people make better commit messages and then merge into the upstream repo it becomes very easy for others to incorporate the work. The big deal is making lots of small commits locally on your own machine code, when you upstream commit the whole batch of commits goes up with the documented reasons as to why you did what.

Ultimately of course you are right, it is not a panacea but it can be a huge help. The ease of working on “live” code is pretty cool also. Mess up just revert. Makes it easy to do a trial merge of someone else’s stuff try it if it does not break get on otherwise revert.

Reply

xmutant December 25, 2009 at 7:56 pm

You might want to check out the following screencast.

http://www.gitcasts.com/posts/railsconf-git-talk

Reply

Rick Ross December 25, 2009 at 8:16 pm

xmutant :
You might want to check out the following screencast.
http://www.gitcasts.com/posts/railsconf-git-talk

Great reference, thanks a million!

Reply

Caleb Cushing ( xenoterracide ) December 27, 2009 at 5:41 pm

What’s wrong with the ‘issues’ feature? sure issues is a lot simpler than trac but that’s a good thing (because I’ve never seen a trac installation set up right the first time). personally I hate trac. but that’s beside the point… just curious what issues doesn’t do that you need.

Reply

Oliver Nassar December 27, 2009 at 6:38 pm

It took me a while to figure out the usefulness (and even generally understanding) of Git. I mean a while. It has it’s advantages, and in a work environment (eg. 9 to 5) it makes sense, but on solo work, I’ll maintain SVN for it’s sheer directness and analogous nature to standard file systems. It’s easy to understand and explain quickly.

Reply

masukomi December 27, 2009 at 7:19 pm

I haven’t watched the screencast so this may be redundant BUT…

The basic difference here is that a TEAM can work on the same repo. There’s no need for the separate ones if that confuses you. BUT in a real open source project random people are taking your code and forking it all the time, you just have zero insight. You don’t know that they’ve downloaded it and started hacking, you don’t know that there are some improvements you could be reincorporating into your main repo, and you don’t have any idea how many people are actually poking at it. All GitHub is doing (in this instance) is giving you information you didn’t have before. Now, if you choose to, you can benefit from all those forks. You can see what direction people are taking your code.

It’s not about encouraging teamwork. It’s about capturing info from people OUTSIDE of your team. Any team, theoretically, has its own methods for communicating amongst its members. If you’re collaboratively working on a project then all the team members can be contributing to the main repo, just use different branches. Maybe a dev, staging, and release branch but all within the main repo. This is where your team works. You COULD have them each use their own fork of their project that is tracked by a separate GitHub project page, but there’s no need for that really.

Reply

Alan Pinstein December 27, 2009 at 7:46 pm

I’d like to point out that if it weren’t for git/github, it is unlikely that you’d have *any* patches whatsoever. The overhead/complexity of contributing code (and consequently accepting it) to an svn-based project is so high that it was rarely done.

The other thing that has completely changed my life about git is how cheap branching is. I routinely have multiple branches going, something I never did in subversion. I can also share these branches with other developers without polluting the main repo.

The more you use git, the more you realize how great it is. I would really suggest diving in hard and forcing yourself to learn it inside & out.

Alan

Reply

Rick Ross December 27, 2009 at 9:27 pm

masukomi :
BUT in a real open source project random people are taking your code and forking it all the time, you just have zero insight. You don’t know that they’ve downloaded it and started hacking, you don’t know that there are some improvements you could be reincorporating into your main repo, and you don’t have any idea how many people are actually poking at it.

I feel you make a strong point. The insight you get into the activity of the forks that branch from a given original is useful information which would never be visible in a lot of the other systems. This is a big plus.

Reply

Rick Ross December 27, 2009 at 9:31 pm

Alan Pinstein :
The other thing that has completely changed my life about git is how cheap branching is. I routinely have multiple branches going, something I never did in subversion. I can also share these branches with other developers without polluting the main repo.

Alan, I think there’s no doubt about this. From what I can see, git makes branching and merging so much easier that it makes a qualitative difference in the process. I am definitely going to give it an honest try to see how it feels once I am familiar.

Reply

Justin Shaffer December 27, 2009 at 10:07 pm

we’re using unfuddle with good results. git repository hosting + decent ticketing/tracking system. very lightweight and easy.

Reply

Alan Pinstein December 27, 2009 at 11:00 pm

@Rick Ross

Yeah, and wait until you use git bisect to save yourself HOURS.

Reply

Jack9 December 27, 2009 at 11:49 pm

masukomi :
The basic difference here is that a TEAM can work on the same repo. There’s no need for the separate ones if that confuses you. BUT in a real open source project random people are taking your code and forking it all the time, you just have zero insight. You don’t know that they’ve downloaded it and started hacking, you don’t know that there are some improvements you could be reincorporating into your main repo, and you don’t have any idea how many people are actually poking at it.

I still don’t get Git. In a production environment, why would you want to examine random branches for improvements? Why wouldn’t you know “which were working on which parts” or care since they haven’t committed to the main branch? Am I supposed to use Git but not replace project management, priorities and responsibilities, leaving me with a complicated version RCS that’s only providing me with “cheap branching”…except it doesnt seem to be any different than SVN (ok, we could create tag namespaces…howabout no), someone help me here…For specific kinds of organizations I’m glad it’s working. Same for lots of other RCSs. I don’t see the benefit of Git, myself.

Reply

Fred Grott December 28, 2009 at 8:40 am

@Rick Ross

Something like Github negates that complaint point as you can see all forks of your project..

Reply

Rick Ross December 28, 2009 at 8:49 am

Fred Grott :
@Rick Ross
Something like Github negates that complaint point as you can see all forks of your project..

Just curious, Fred. How do you interpret “complaint point” from “This is a big plus.”

Reply

Dan DeLeo December 28, 2009 at 10:56 am

Rick,
As many of the other commenters touched on, appreciation of git seems to come about slowly, as you encounter problems that would have been a nightmare with anything else. I suggest you try never developing on master, always in branches, and just merge the branch when whatever feature or bug fix you’re working on is done. Do that for a while, and eventually you’ll be in the middle of some big new feature and you’ll find out about some bug you need to fix *right now.* You’ll commit or stash your work in progress, switch to a new branch for the bugfix, push the fix, then get back to what you were working on before. Then you’ll wonder how you ever lived without it.

Reply

Levi Rosol December 28, 2009 at 11:47 am

I am also new to git, coming from an SVN background, and had / have many of the same thoughts as the author. However, I’m in a single developer environment (me) with git, so I understand why I don’t see the other benefits of git.

I do agree with Dan Deleo that if you work in a branch for your enhancements, there will come a time when you need to bug fix in master. This happened to me recently and it was very easy to switch between my branch and master to fix and deploy the change.

I will also add that not having a GUI tool like tortoise forced a pretty steep learning curve as I was also new to Ubuntu when I made the jump to git. The command line is not hard to use, however, I have found that using SmartGit made managing my repository MUCH easier. Especially when jumping between branches or adding new files.

Reply

Bill Robertson December 30, 2009 at 10:40 am

Contributing to projects on github is dead easy. Make a fork, and clone your repository. Then make a branch, and do your fix. Push the branch to github, and then send a pull request to the maintainers via. the web interface. Whether or not they accept it is a different matter, but it becomes really easy to contribute if you want.

Its also really easy to watch other projects or your own forks on github. Just follow the project and subscribe to your rss feed.

Reply

Leave a Comment

Previous post:

Next post: