Some topics I play with for years. Turning them over, coming at them from different angles, in different formats, and presenting the information to different people. I enjoy finding better ways to help people through topics I've tackled myself. Last week I gave two presentations based on the book I'm writing: Peer Code Reviews: Are they worth it? and A Rebasing Workflow. These topics are ones I've been working on for years through college curriculum development, conference presentations, workshops, articles, and through on-the-job observation.

I've written a few articles on code review, and I've also given a few presentations on effective critiques. It's something I've been exposed to and thought about my reaction to for literally decades.

Rebasing, however, isn't something I've written about nearly as much. I touched on it a little bit in The Evolution of Social Coding, but I think it deserves more attention. Sure, the merge conflicts which pop up during rebasing can be frustrating to deal with, but that's not really what makes rebasing hard. Rebasing is complicated, not because of the technical part, but because of the social implications of how much it can break teams apart and how much the information can be used to make people feel like an outsider.

Hopefully Git for Teams will help to reduce the mysteries around rebasing and make it easier for teams to choose the best workflow for their circumstances. Maybe it will include rebasing, maybe it won't. But hopefully I can help people make an informed decision that makes their day-to-day interactions with Git a little easier.