Can I prevent pull requests being merged at certain times of the week?

user_5898423 0
Viewed 1247

On my GitHub repo, I have two primary branches, develop and main, which represent a testing and production-ready website, respectively. I work on a feature on some branch, say newFeature, and then I merge that into develop, for testing. Other people are also doing this with their branches, so then develop has a number of changes on it. Assuming everything is tested, we want to now add these changes to the production-ready site by merging develop into main.

I want to do this merge from develop to main regularly, say every Friday at 10am. I'll need to check in with anyone who has added changes this week, to ensure that everything is tested and working correctly. To ensure the chance of success here, I'd like to prevent people from merging any more pull requests into develop after Thursday at 2pm.

The devs (who are made aware of this restriction) should then spend the rest of the day testing any changes on develop that are due to be added to main the following morning. If they find any issue with what's already on develop, they can fix the issue on their branch, raise a PR into develop, and ask the repository owner (who is not subject to this restriction) to approve their PR.

Is this scenario, where users (except the repo owner) can't merge PRs into a branch at certain times of the week, possible?

github git
1 Answers

There are multiple ways to accomplish this, and none of them are even GitHub specific:

  1. Lock down the develop branch starting a time X and ending at time Y. AFAIK most popular centralized Git repo tools have the ability for the admins to manually lock and unlock branches (either with an explicit lock or by adjusting permissions). Whether you can automate the timing would be tool dependent, but I assume you could write custom integrations, and if not, manually locking once per week isn't a big deal, especially since you would have to intervene manually to allow bug fixes to get in.
  2. Add a custom integration "gated check-in" such that additional requirements exist during the desired time frame.
  3. Don't lock down develop at all! This is actually what most people do. For example, in Git Flow you simply create a release branch for this exact reason. If you don't want to actually create the dedicated release branch, you don't have to; just remember the commit ID from develop that you cutoff and tested from, and if you don't have new PRs for bug fixes, simply release that commit ID and merge that commit ID into main. If you end up having bug fixes, you might as well create a release branch so there is a branch to PR the fixes into.

Whether you use Git Flow or not, I highly recommend option 3, for sanity purposes, and so you don't have to stop development during the release cycle.

user_1845460
Related