Git like a Pro

It's easy to just use git like someone would use other systems like Subversion, but with Subversion's rigidly immutable history, how many times have you made an elegant commit only to follow it with a commit saying "forgot to add this file; this fixes the build?" With Git's distributed nature with a local repository and its ability to rewrite local history, it's possible to create commit histories which are completely clean and properly ordered, where the tree builds and passes unit test at every single commit. Since this clean history is possible, it should be considered required for disciplined software development, whether developing solo or on a team. Use of these principles is required for submission to the Linux kernel and to many other F/OSS projects.

Developing code is often a process of:

1. Try to add new feature

2. Realize you need to add code to supporting libraries

3. Find bugs that need to be fixed

4. Iterate 1, 2, and 3 until it works.

In a commit log however, the order of commits should be:

1. Fix bugs

2. Add supporting library code

3. Add new feature

This is made difficult because you don't want to commit anything before it's all proven to be working, and once it's all been proven working, there are often changes all over the source tree. Sometimes items 1, 2, and 3 will involve changes in the same files as one another which are not appropriate to be committed together.

This presentation will describe the tools and process of creating clean commits and a clean history. This presentation isn't about a

git workflow that only works; it's about the proper way to use git to create what git was intended to create.

Also discussed will be tools for doing the hard things in git like bisecting, rebasing, reviewing code, using the reflog, and working in teams using git.