Git Pull: A Follow-Up on my Previous Git Post
Published: February 3rd, 2008My last blog post, “All That Git Talk in The Rails World, What Gives?” received quite a bit of feedback. In this post I’m going to share the Git highlights that I’ve collected over the last two days.
So Much Buzz!
The amount of Git1 articles popping up over the last couple days is insane. I definitely know I’m not the one that sparked it, but it’s weird on how it’s popping up absolutely everywhere now. There’s at least two on Reddit2, I saw a couple on my Google Reader, and then some others on misc sources. I’ve compiled some notable articles in this post, and a couple highlights from comments on my previous Git post3.
A Good Comment
Here’s a comment on my previous Git post by Tom Preston-Werner4:
The distributed nature of git makes collaboration easier than with svn. Consider an open source project like Rails. Under svn, you checkout the Rails source, make the changes you like, produce one monolithic patch, and submit that back to the core team for evaluation. During this time you can never commit those changes anywhere or mark waypoints in development.
With GitHub and git, the workflow is much nicer. Let’s assume that Rails core maintains their version of Rails on GitHub. You would fork the Rails project into a repo under your name. You then clone that to your machine (which is a FULL repository with all history and can be pulled down surprisingly quickly). You make your changes, being able to commit as you please (commit messages and all). When you’re ready for Rails core to evaluate your modifications, you push those changes to your fork of Rails on GitHub and inform the core team that they should pull from your repository. It’s trivial for a core member to evaluate your code in a new branch of their local repository. They don’t have to worry about a patch not applying cleanly or being incompatible with their current revision. If they like the changes, they can merge them back into the mainline which would then show each of your commits as you had made them, complete with you as the author and placed correctly in the timeline. You complete the circle by updating your local repo from the new Rails master. You don’t even need to pull down the commits you authored, you already have them!
You can use the same workflow for closed source projects. You don’t need GitHub to make this possible, but it definitely makes the process more streamlined (and gives you a nice online interface to your code and changesets).
Another thing I love about git is the ability to create repositories without a central server. When I start a new project, a single ‘git init’ in that directory gives me a complete, self contained repo. You can even use git to revision your /etc directory so you never lose a config file again!. Oh, did you know that git repos only need a single .git dir in the top level of the repo? Sure beats dealing with a .svn in EVERY directory.
Even without all this good stuff, I’d still use git just for the local commits and cheap and easy branches. Any time I want to try out a new feature I just branch off and start coding like mad. No worrying about what revision I branched at, or special directory structures (i.e. trunk, tags, branches) to maintain. Just my code at whatever revision I want. Moving between branches is so fast you sometimes wonder if it actually changed.
Git has some very powerful tools for merging branches and messing around with prior commits. Need to combine several commits into one before you submit back to the mainline? No problem, git will help you do that. Need to merge just a single commit from one branch to the next? Look up git-cherry-pick. Updating branch B with changes from branch A by applying each branch B specific commit on top of branch A can be done with git-rebase. It even pauses after a conflicting merge and lets you fix it at the point it first occurred, then continue once you’ve fixed it!
I’m going to stop, but these are just a FEW of things that make git an improvement over centralized SCMs. As with any powerful tool, git has a bit of a learning curve. What really opened my eyes was sitting down for a few hours with the docs to REALLY understand the underlying organization of the object database, the difference between the working directory and index, and how to manipulate commits.
Hope this helps!
[Disclaimer: I am co-founder of GitHub]
My Insights
I believe that says a lot about Git. I really appreciate Tom for taking the time to write that up. Hopefully his comment will serve as a reference for clearing up some confusion about Git. I’m sure there are other impressive comments in my previous post. I don’t want to single out anyones contribution to the topic, so please check my previous Git post for some further insights.
Helpful Resources
There were a couple articles that I came across that really seemed to shine the point of Git, here’s a couple to take a gander at:
- Why Distributed Version Control Matters to You, Todayby James Golick
- Using Git within a project (forking around) by Dr. Nic
- Git is the next Unix
- One of the things Git gets right
Conclusion
Hopefully this serves as a good resource for brushing up on Git; it certainly brought my knowledge bar up. If you have any Git tips you’d like to share, or gotcha’s please spread the word!
- Git Homepage: http://git.or.cz/ [↩]
- http://www.reddit.com [↩]
- My original Git article: http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/ [↩]
- His blog, and is the co-founder of GitHub [↩]
Not to take anything from Github, but advertising a service that isn’t available to the public on a technology that is so new to our group of developers is well … uhm…
yeah..
Ready. Set. Go.
In terms of the formatting, you're allowed to use markdown, textile, or basic html; it's truly up to you -- what strikes your fancy?
You don't have to worry about your e-mail address being sold to a russian-spam-mafia. I'm only going to use it for my own weird needs; like asking you out for a date on a lonely night of coding.