A question has surfaced on the team: would it be a good or a bad idea to have a script auto merge from master to all this release’s branches on a daily basis?
I’m not entirely convinced by it — it seems that merging may yield conflicts (and in that case the script would back-off), but even if it doesn’t, I can imagine cases where I’m working on some huge refactor on my branch, by some reason I want to commit and push it and then it may so happen that I can’t because the master has been changed in-between! In those (rare) cases I would be left with no option than to git push --force or simply not push my changes.
What’s your take on this? Are teams using these kinds of scripts elsewhere?
Thanks
4
My gut tells me I wouldn’t do it. The issues probably outweight the benefits:
- conflicts
- not wanting to merge yet
- rollbacks accidentally overriden by the script
- wanting to merge two branches in a particular order
- …
In the trivial cases of simple merges without conflicts, doing it manually takes a couple of seconds anyway. And in the other cases, a script probably can’t help.
would it be a good or a bad idea to have a script auto merge from master to all this release’s branches on a daily basis?
On a daily basis? No. Does “master” change every day?
Having a bunch of changes periodically steam-roller’ing all over your precariously-balanced code that only just compiles and is nowhere near ready for release is just asking for trouble.
After such a merge, your Team is likely to spend a lot of its time unpicking the damage done to their code or even just re-running regression tests and sorting out “what’s changed”, none of which is anything to do with the feature/ bug fix/ etc. that they’re supposed to be working on.
2
Isn’t automerging conflicting with the main idea of release-branches? A release branch (as I understand it) is to have the possibility to look back to the history of an already released version, or add a patch (e.g. customer 1 get’s v1.0, oops there is an error, we deliver v1.0.1). Merging master into a release branch would also add new features, which makes the branch unpredictable and instable.
I’ve seen it the other way around – a bugfix is done in the affected release-branch and then merged back to master. This was always a manual task.
On the other hand, merging release + master without pushing (!) may be useful in a CI environment to check for potential compatibility.
Daily integration from master to all feature branches gives lots of benefits for many teams. However, it should not happen unsupervised. It seems what you really want is a daily reminder for you and your team members to try a merge from master to the current feature branches. So if you want to automate this, you could instead make a kind of dry-run, like it is described here, without affecting the current feature branch or local copy. If that dry-run shows any merge conflicts, send the developer in charge a message about the conflicts he has to expect, if it does not, don’t bother him or the team.
1