While I've been writing my Git book, I keep trying to pick up new tricks and figure out places to use them. A came across a post on git rebase --interactive and knew I had to find an opportunity to play with this. This morning, that opportunity came.
I've been working on some performance enhancement at work this week. I use Git locally for all of my development, then push back to our central Subversion repo once my changes are done and approved for the main repository. Timing for the changes I made earlier in the week was bad, so I was going to hang on to them for a week and push them when our engineering/QA department can absorb them more easily.
... the observant reader should be picking up on the past-tense here ...
So as part of my changes I created a Registry to share a single instance of an object around instead of going the Singleton route or putting the data in the global scope. Pretty useful all round, but silly me didn't think to put that in a branch by itself so I could pull that change around as necessary. No worries.
Light Bulb! "Ah ha! I'll just switch into my branch and use git rebase --interactive to rewrite all of those commits and squash them together. A quick git cherry-pick later and I'll have my Registry object in this new branch on some other functionality I'm working on."
If you've ever used git rebase you can probably see where this is going. If you haven't, it's probably one of the more dangerous commands—if not the most—in Git. It will literally let you reshape the history of the repository. Running with scissors is child's play. No, rebase can really screw you over. Imagine riding a unicycle while juggling four meat cleavers and you'll have the idea. Really, and I mean really impressive to watch, but one false move and you're screwed.
So back to my experience. I proceeded to weed through the 80 or so commits from Monday afternoon and Tuesday morning and pull out everything that didn't relate to the code I wanted. "Git will just ignore those" I naively thought. I got it down to the 8 or so commits that had to do with my registry object and its tests and squashed them all into one commit. I knew I was rewriting the history, but it never occurred to me that I was rewriting history. I let rebase do its thing, then cherry-pick'd my newly created revision and was off.
Until this afternoon. Rumor of my changes had made it around the office and someone else wanted to see them. Since I only track our trunk and not all of our branches and I'm the only there using Git, the easiest solution was to just create a patch to send to him. Simple enough. Use git merge --squash and git diff --no-prefix --cached and I'd have a patch he could apply directly to his copy and we're set.
Needless to say, when I started reviewing the patch, I notice there was a lot missing. :-(
Lesson learned. Don't play with live data when trying new stuff out. When you miss a bean bag while you're juggling, you don't loose your toe...
Either I'm making up for time I spent slacking, or I just took 4 years off of my life today. Today I managed to:
- Have my git book from Pragmatic Bookshelf announced: Pragmatic Version Control Using Git - It'll be on a shelf near you this fall and in PDF form before then.
- I filed my taxes (not completely today - I'd already done then, just hadn't submitted them yet)
- Proved conclusively that an installation stack wasn't stable for production (which is always fun when it's a random failure and you're having to play by the Law of Large Numbers)
- Proved conclusively that another stack was stable
- Should be able to prove or disprove a third stack configuration by the end of the night
- Got PHPT setup for inclusion into PHP as a replacement for the run-tests.php code which means it'll be distributed as part of the core PHP product
- Got PHPT onto the Google Summer of Code project list for the upcoming summer (as part of it becoming part of php-src)
- Fleshed out a killer business idea with a buddy of mine
- Wrote what I think was a pretty good article on relational databases
- Spent an hour at the gym this morning doing a lower-body workout
And it's just now 5. ;-)
If you follow my tweets, you'll have seen that I'm writing Pragmatic Version Control Using Git. Needless to say, I'm pretty excited. Of all of the publishers to write for, the accidental ones have always been high on my list since the quality of their books is so universally high.
I've been wanting to write a book for awhile now, I just could never figure out what on. Some time last year I decided that I wouldn't push it until some topic felt right. This past winter as I learned Git it started to feel right. Before I committed to a book, I decided to write an article (which should appear in over the summer in php|architect). When I finished the article I realized I had barely scratched the surface and that it would take a full book to do the topic justice. And now a few weeks after my initial pitch to the Pragmatic Programmers, I'm set to start.
The market for this book is wide open right now. There is nothing available in print form on Git so the newbie is left to manpages and random blog posts that Google turns up. You can find out how to do just about anything, and in the time-honored Perl tradition, you can find out 10 different ways to do most things. For someone just interested in evaluating it, though, there isn't much out there. Find answers to the questions "what good is it?" (in a non fanboy way) and "how do I use it every day?" requires some digging. By the time I get through with this book, I plan on having both of those questions, and a few more answered.
Since this is my first book, I'm sure there'll be blog posts aplenty about the process and such. Right now I'm raring to go, using most of my free time to write. We'll see if I still feel that way after the third rewrite of an intro paragraph to some odd ball chapter. :-) If you're interested in following this, I'll be tagging posts with git book (atom feed of git book posts).
Finally, if you're feeling generous with your links, I'd love the help getting the phrase "git book" to the top of Google. Only one post tagged and I'm already on the front page, but it never hurts to have a few inbound links too ;-)
I've been kicking around the idea of a book on Git. I think it's a great tool, but there's a lack of an accessible guide to get started with. In any book on a new technology or tool, there's the initial sales pitch. Why should you use this? How is it better than what you're already doing? Than its alternative? I'm trying to answer those questions right now for myself. It's only a few paragraphs of the entire book, but I think having the answers will help keep me on track for the rest of the book. Here's what I have right now.
Distributed
One of the main reasons for using Git over the two traditional version control systems—CVS or Subversion—is its distributed architecture. Instead of having one central repository, or one central point of failure, each developer clones the entire repository. Changes can then be pushed back to a central source, or a completely different source.
In the workplace, this allows for multiple layers of code review before the code makes it into the main repository. Each developer would push their changes back to their team's repository, with the team captain pushing changes back to the main company repository after they've been reviewed and the unit tests are verified.
In the open-source community, distributed means that no one company or person controls the repository. Any developer could easily publish their changes with the exact same history up to their change. These changes could then be incorporated by developers that are still tracking the official repository, allowing them to try them out without leaving their version control software unused.
Easy Branching and Merging
Branching within Git is easy and without much overhead. Tracking multiple branches, merging changes from many branches in to one, tracking changes across multiple merges. All of these are considered esoteric in most version control systems, only for the most advanced user. While they still take some practice in Git, doing them is straight forward.
Tags are Just Tags
If you moved from CVS to Subversion, you were probably surprised the first time you realized you could change code that you "tagged". Git enforces the "gentleman's agreement" found in Subversion by not allowing anyone to write directly to a tag, treating it as just a named snapshot.
Network Not Required
It is easy to forget in the age of always-on broadband connections, but we don't always have a network connection. Since your working copy is your repository, you don't need access to a network connection to track changes. You can safely work on your code on your next plane trip, tracking your changes the entire time, then sync with your repository after you've landed.
Can Communicate with Subversion
In the centralized world of Version Control Systems (VCS), Subversion has become the defacto standard for new servers. Having the ability to communicate with SVN means that your entire company does not have to switch to Git just to suit one team or one developer. They can maintain their copy of the repository along side the existing infrastructure and push and pull changes to Subversion seemlessly.
Anyone out there using Git have anything more to add? What's the obvious thing I'm missing?
