Minimize context loss when opening a Pull Request
You’re working in a codebase. You stumble upon something you’d like to change. The code change will only take 2 minutes.
Do you make the change and open a Pull Request?
The answer likely depends on how costly it is to open that Pull Request (PR). Ignoring the specifics of the code change, the cost of opening a PR is commensurate with the loss of context of our current work.
Losing that context is costly. So, I don’t blame developers for not wanting to make those small, separate changes. But making those changes is also the best way to improve our codebase continuously and prevent technical drift.
The moment we spot an issue is often the best time – it might be the only time – to fix it. Frequently, that is when we have the most information related to the topic (after all, we just identified the issue). And typically, we know that if we move on, we’ll never have time to come back and fix it.
So, what can we do? We can minimize the context loss by making it fast and simple to open a PR. All we have to do is improve our workflow.
Process of opening a Pull Request
We see something we want to change. We create a new branch, make the change, commit the code, and push the branch to GitHub.
How do we open a Pull Request?
This is my workflow:
- Open a PR with
hub pull-request(commit message is PR description)
- Go back to my previous branch:
git checkout -
- I’m back in the flow of things
Compare that to the alternative workflow:
- Go to GitHub
- Find the branch
- Compare code to open a Pull Request
- Type in a Pull Request message (or worse, don’t type a message at all)
- Open the Pull Request
- Go back to the command line
- Go back to our previous branch:
git checkout -
- Go back to whatever we were doing, having lost all context
The second workflow is a lot longer, and the critical point is the last one. It takes so long to open a Pull Request that we lose all the context of our work. That is costly indeed!