We have a repo that (for us) is fairly busy; we can get several dozen PRs a week. We require successful completion of some status checks and, along with those, require that the source branch be up to date with the base branch. The issue we run into is that every time we approve and merge a PR, all of the other outstanding PRs become out of date with the base branch. The person doing the merge then has to choose to update the source branch in order to complete the PR merge.
Question is: what's the best practice here for busy repos? GitHub is doing what we're telling it to do, and it's good to keep the source branches up to date with the base branch. But is there a better way we should be doing this? What do other large repos do that need to handle dozens of PRs? I want to simplify the process for merging PRs but also want to maintain the integrity of the base branch...those seem to be at odds.
thanks for any help!
I've worked on projects that receive that amount of PRs per week and most, if not all, of them allow the merge so long as there are no conflicts detected. If there are no conflicts, the common case should be that the merge happens and everything just works. Git maintains the integrity of things through its merge processes.
What is the intended goal of expecting the source branch to be up-to-date with the base branch if there are no conflicts? Do you experience a lot of test failures after the merge of branches that weren't up-to-date? If so, you should also see those same test failures when the person updates their source branch to include the latest from the base branch, which would also tend to slow down the pace of development. If you don't see test failures when updating the branch, then you should very, very rarely experience them post-merge.
If you can give more insight into the reasoning behind the requirement, perhaps we can look deeper at the cost/benefit of it?
hi @lee-dohm, thanks for the reply!
I guess that's part of the question - is it really necessary? Our usage is definitely not typical - we use GitHub as a content repository for our help content (my team owns several sites under docs.microsoft.com). So we don't encounter test failures, but rather want to ensure that people are working on the latest content. The ideal situation being that the likelihood of hitting a conflict is reduced and the source branch is kept up to date. Branch freshness is a bit of a challenge because 1) our users are still getting used to the platform and sometimes forget to refresh their branches and 2) these users frequently work in a number of different repositories due to the large footprint of our product ownership. So they may spend the majority of their time in repoA but need to dip into repos B and C periodically. They may forget to refresh their branches and work off old content.
Forcing the branches to be up to date won't prevent conflicts from happening for the files being updating but hopefully will ensure the that the branch as a whole will be brought up to date for future work.
Talking about it, I'm starting to doubt whether it's necessary and that it's just adding complexity. But would still love to get your thoughts as well. thanks!
It sounds to me like it isn't strictly necessary but is a symptom of the people using it not having much experience with Git and maybe needing a little assistance with the workflow. One thing I can recommend is the GitHub Desktop tool. It has a convenient indicator that is a good reminder of where your local copy is relative to the remote repository and it auto-fetches (not the same thing as pull, mind you) new changes every so often:
My personal workflow is from the command line and I have a couple aliases that help streamline things:
My `git done` command ensures that I've deleted the branch that was just merged, updated to the latest, and cleaned up other merged branches.
Let me know if you'd like me to go into more detail about how I've constructed that workflow for myself.