Code polish using Git Rebase

2908889599_f45224fb01

We are using git for more than half a year now and I just cannot believe that we could ever do anything using subversion. The difference between git and svn feels as big as a difference between svn and managing versions by zipping folders. In subversion it is really difficult to alter code once you committed it to the repository and consequently programmers are usually waiting with commits until the code is fully polished. In git, on the contrary, commits feel more like temporary snapshots with no pressure on programmer to polish them completely, since he has a full control over his local repository. A big part of final code polish in git that I've started to use more frequently recently is interactive rebasing. Rebasing comes especially handy in preparing code for a review. For example, if you've included code of external libraries into the project, you can use rebasing to move commits of library code before the commits with your code changes. Doing so makes it much easier to pack code for a review. Similarly, if you decide to do some code reorganization in the midst of a programming spree, you can use rebasing to move commits of reorganized code before commits of new functionality. Another useful practice that it's made really easy with git rebasing is squashing south migrations into a single migration before pushing code to the main repository.

I see preparing code before pushing it to the main repository and packing it for a code review, as the very first code review. The moment just before git push is a nice final check if your code makes sense and if it is polished enough to be presented to your coworkers in the form of a code review request.