I Don’t Git GitHub Yet, But I Hope I Will
We’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.
To 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.)
Rick Ross
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.
You might want to check out the following screencast.
http://www.gitcasts.com/posts/railsconf-git-talk
Great reference, thanks a million!
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.
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.
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.
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
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.
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.
we’re using unfuddle with good results. git repository hosting + decent ticketing/tracking system. very lightweight and easy.
@Rick Ross
Yeah, and wait until you use git bisect to save yourself HOURS.
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.
@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.”
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.
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.
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.