Working with a chain of reviews

This blog post comprises of a very simple but an extremely important concept which is very widely used while working with version control and in big teams, the `git rebase` command. I knew of this command before but never got the chance to play with it, until this Outreachy Round, where I need it now almost on every single review. This post is mainly for beginners since I guess most of the experienced developers will be very much familiar with this.

My internship is with OpenStack, which use gerrit as their code reviewing tool. In gerrit, we can submit only one commit per review, that means that if you have multiple commits on your local branch and you would like to push those commits to gerrit, they will form separate reviews. Now generally, it is advised to keep each patch/review as small as possible, but complete in itself. This makes it easier for the reviewers to go through the code and suggest changes. So my mentor, Samuel, suggested me to divide my work in small patches, such that each patch makes a prominent change, but is dependent on the previous ones and works on top of those. So far so good, I planned my work and patches accordingly, I make the first change, push it to gerrit, then fork a new branch from there, work on the second one, push a new review, then again fork and so on.

But what happens when you have to make changes on your base reviews. How to propagate those changes to the subsequent branches/patches?

Now let us just consider an example of a chain of reviews: 1 →2 →3 →4, where these numbers are, say, the review numbers published on gerrit and this is the sequence you followed while creating them. Change in 2 builds upon the change in 1, change in 3 builds upon change in 1, 2 and so on. Now for some reason you made a change at the review 1 and since the subsequent patches depend upon the first one, you want all those changes to be propagated. To do this we use the git rebase command. We simply to go the review 2 branch and do git rebase -i 1.Using -i you get an interactive interface which allows you to select which changes you need to apply. After that, the changes/commits selected would be applied in the same order and you will be notified of conflicts, if any, which you will need to resolve manually. After propagating the change on 2, you can do git rebase -i 2 for review 3 and git rebase -i 3 for review 4, and you will see the changes applied till the end.

Another application of this rebase command is when there is some path conflict in a patch because of some other changes merged in the master after you started working on yours. In that case you need to do git pull on master and then git rebase -i master on that branch, and toresolve all the conflicts.

So thats all for now, It was a little tough for me to get familiar with this, so I hope all this makes some sense and is helpful for some other people too. Thanks for reading and stay tuned for more .

Show your support

Clapping shows how much you appreciated Samriddhi Jain’s story.