Git - Keeping protected feature branch in sync with master

user_11228445 0
Viewed 612

My team works with feature branches that get branched out of master at some point

# make sure the local version of master is up to date
git checkout master
git fetch origin 
git reset --hard origin/master

# create a new branch
git checkout -b feature/name

These feature branches can live for a few months while we develop the new feature, but master also changes in that timespan as we address bugs or other feature branches get merged.

We mostly follow the process described in feature-branch-workflow. Github also has good documentation about-protected-branches.

Now, the issue is that the team decided to protect the feature branch (including administrators), leaving us with a few options when syncing master and feature/name:

  1. temporarily remove the branch protection rules so we can update feature/name with master

    Pros: easier option (usually just use the Github UI to sync branch). Good to solve small conflicts -- git checkout feature/name; git merge master; solve conflicts, commit, and git push

    Cons: Risk of someone pushing to an unprotected branch (even if temporarily); merge conflict errors and code that is not peer-reviewed

  2. create a PR to the feature branch that includes the changes from master

    Pros: all code gets reviewed

    Cons: time-consuming; PRs usually get very big

  3. a mix of both depending on the conflicts to solve

    Pros: Use approach 1 for small conflicts (conflicts in changelog for instance) and use approach 2 for bigger conflicts

    Cons: Gray-zone of what is a small or big conflict. Same cons as option 1

I wonder how can this process be improved. Feature branches need at least two approvals to merge to master. Would it be safe to remove administrators from the branch rules? Are PRs, even if big, the way to go? What are the best practices?

version-control github git
1 Answers

The way I understand it, your best option is #2: Always require a PR into the protected feature branch. This means you may need to sometimes include the updated master in a PR into the protected feature branch.

There are 2 ways to do this:

  1. Periodically create a separate PR of master into feature/name (which may require a separate temp branch if there are conflicts).
  2. Have one of the feature branches getting PR'd into feature/name include the latest master in their branch.

Note the "con" you present for this option may not be a big deal:

time-consuming; PRs usually get very big

Regardless of whether you use a PR or just push out the merge, the conflicts still have to be resolved, and the merge still needs to be reviewed and tested. The overhead of the PR (compared to pushing without a PR) for a large change should generally be similar to that of a PR for a one-line change, except perhaps additional required sign-offs and/or builds; but those shouldn't increase "person-time" that much.

Note there's another advantage of always requiring a PR to get code into a protected feature branch, without exceptions. When it comes time to merge the protected feature branch back into master, the reviewers will know that every change on the feature branch has already been code reviewed. That way the reviewers can focus on the changes as a result of the merge, rather than also having to do an in-depth review of every individual change for functionality, style, etc.

Tip: I tell developers to generally avoid ever checking out master and to delete their local copy of it, because you almost never actually need it. Nearly every command you'd run with master can be substituted with origin/master instead. You can simplify the 4 commands you use to create a feature branch to these 2 commands instead:

git fetch
git checkout -b feature/name origin/master --no-track

The end result is identical but you never have to bother checking out master, and you also won't ever accidentally use an outdated copy of your local master.

user_1845460
Related