When you are working by yourself or with a small school project team the source control requirements are pretty low. You do not have to worry about keeping builds healthy all the time or the impact broken builds may have on others. But the story is very different when one is working in large engineering teams. Therefore, most engineering teams rely on Github protected branch rules to ensure stability of the application.
One of the most common restrictions that developers use in Github protected branches is to require status checks to pass before merging. This ensures that the CI is completed successfully before merging the changes into the protected branch (typically master or main).
There’s one additional restriction that requires branches to be up to date before merging. This ensures that the pull requests have been tested with the latest code before merging in the protected branch. This prompt typically shows up in the Pull Request asking developers to update their branch. This setting is less commonly used today, and we will look into why.
Example
So what’s the point of having branches up to date before merging? I recently ran into this scenario, so let me explain with an example:
Let’s say Joseph and Ashley are working on a web application for food ordering service. They are working on a feature to offer a discount for users who would order ahead.
PR #1: Joseph made the following change to calculate the discount offered to the users.
PR 2: Ashley adds a new API endpoint that will be used to charge users.
As you can imagine, the changes independently look pretty safe and pass the test, but when combined together will break the build as the signature of charge_order has changed.
These types of scenarios are very common in large teams where multiple engineers would be working on the same code base. In those cases, it is safer to enable the restriction that requires branches to be up to date before merging.
Side effect
Before you go and turn on that knob in Github, you should understand one side-effect from using this configuration. I remember after we turned it on, engineers started spending a bunch of time playing rebase-athon. So in the above example, let’s say both Ashley and Joseph are ready to merge the changes. Now if they do not communicate with each other, they may both rebase their branches with the latest master and wait for CI to finish. Whoever notices a finished CI would merge the changes, leaving the other developer to start the rebase process from scratch.
This can be optimized using a custom Github action to keep branches up to date. Every time a PR is merged, a Github action can be triggered to update the rest of the branches. Some companies have internally built a system to manage this whole process, for example SubmitQueue at Uber or Merge Queue at Shopify. There are also some plug and play versions of similar concepts, the one I’ve used in the past is called MergeQueue.
The bottom line is that as your team grows, optimizing the code merging process may become critical. This Github setting to restrict branches to be up to date before merging may seem a bit of an overhead, but would pay off to give you and your team peace of mind.
Top comments (0)