Share Your Code For Review

When you work on your code for a while, you come to a point when you need someone else to review it. Perhaps you need help figuring out an issue, or maybe you just want to check with someone else that you’re on the right track. Ultimately, you need to push your branch to a repository so they can access it. What you may not know, is the act of publishing your git branch can cause issues. As soon as you publish your branch, any git command that rewrites your branch history will cause a problem. For example, if you choose to rebase your branch, it will rewrite the history of your branch – including changing SHA-1 hashes and timestamps. While you could force push your rebased changes, it’ll cause a problem for anyone who has pulled it. Since this article is about asking someone to review your code, at least one person will pull your branch. In an open source project, there could be several more.

Share your code safely

Lets say you have a branch called issue-128 where you’ve done some work. If you created your branch locally, origin doesn’t know about it. So git push won’t work without a change. Instead, the CLI git client will display a message to show you how to setup tracking.

$ git push --set-upstream origin issue-128

In many cases, this is what people want. Today we’re doing a little something different though. You can type git push origin issue-128 to push your branch without setting up a tracking branch. Notice how the branch name for origin, matches the local branch name. This is the command we’ll use when we’re ready to submit our code. So save this for later. It’s probably a good idea to read the docs for git push, but finish reading this article first.

For the purpose of our code review, we’re going to change the branch name that we push to origin. You can change it to anything. You could include your teammate’s name, to demonstrate your branch is for them. For now, let’s call it issue-128-review. You could try git push origin issue-128-review, as it’s the obvious guess – but that won’t work. Instead, here’s the command you should use

git push origin issue-128:issue-128-review

Structure of the git push command

Why does that work? I never had to do that before, you say. If you look at the help page for git push, it would show you a lot of detail about how the command works. Let’s pull out a couple of pieces. The first piece is there’s the general command structure.

$ git push <repository> <ref-spec>

The can be any remote you’ve set up. Usually, this is origin, but this could be upstream if you forked a project. The <ref-spec> in our case, is the branch name.

The second piece we’ll pull out, is that the can broken down into a source and destination. It is written in the format of <src>:<dst> where <src> is the source name which is our local branch name and <dst> is the destination. The <src> is your local branch name. The :<dst> part is optional, when the <src> and <dst> are the same. This is why the command git push origin issue-128 works. It’s as if you typed git push origin issue-128:issue-128 at the command line.

Note: One thing that might interest you is that the <src> can be an expression that refers to a git commit. It could be a specific commit SHA or even HEAD~3, if you didn’t want to push everything you’ve done.

Summary

I hope that helps. Pushing to a different branch name is a great strategy to allow you to share your code for review, while maintaining your ability to rebase your local branch. It’s easy to do, now that you know how. Hopefully this will encourage you to share your code for review with your colleagues more often.