Good idea to have Git auto pull master into other remotes?

Question

My team has been looking at possible ways of reducing integration issues.

Currently we have a very simple workflow, with a stable and running master branch, and individual branches where new features are built and tested. We try to keep these as small as possible, and move them through into master as quickly as possible. Nothing goes into master until it's tested and verified to be working. I believe this is reasonably standard practice.

We do have issues occasionally where 2 closely linked features might break each other, and we don't know this until they've been signed off and merged together. While we do try to keep our remotes up-to-date with master, being a human process it's prone to someone forgetting it (and issues don't just arise from pull requests with merge conflicts). It also means anything awaiting testing won't get much (if any) attention from the developers, so if 2 conflicting features are awaiting testing at the same point, odds are once one gets merged into master, it still won't be available in the other.

I was thinking of setting up some git hooks to automatically pull main into any open remote branches every time a new features get's merged in. While not fail proof (eg. a tester moving onto a new feature will not give enough time for our automated builds to complete), it could help minimise the issues by keeping all remotes as close in sync as possible, and it would put us in a state of a constantly moving master head (a branch being merged into master is effectively master + new feature at this point).

Before I went through implementing this I was wondering had any experience running a similar setup, or could think of any critical flaws with it?

Answer 1

Assuming you mean "pull master into other remotes" to mean a merging operation, I don't suggest it. I think it would be really surprising for any sort of "automatic merge" to happen with enough reliability that developers would pay attention to it, particularly merging between closely-intertwined features that may have incompatible changes on either the file level or the API level.

This is especially true if you're merging main into the feature branches on your team's repo server while developers continue developing on their workstations; they might find, then, that they can't push their work to the main server without first merging their local work with your main-branch-to-feature-branch merge (assuming the latter succeeded consistently). That could get very frustrating very quickly.

If instead you say "pull master into other remotes" to mean that across your team local clients perform an automatic automatic fetch of origin/master, combined with some post-commit message that notifies you that the master is further ahead than the most recent merge, then you can give a timely reminder that a merge is required (as in this SO script) while also giving them the flexibility to defer the headache of merging. After all, they may be too focused on active development to want to merge until (say) the end of the day, and with a reminder they can reserve some time to merge without being forced to do so immediately.