2

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

Improve this question
4
  • btw.. don't you usually do the opposite: merge branches into master?
    – dagnelies
    Sep 5, 2016 at 10:17
  • 7
    It is a good thing to keep branches up-to-date. It prevents lots of big merge conflicts. We do it by regularly updating by hand and I would not want a tool to do it for me. When we merge to master we first update the branch to be in line with master, so all conflicts can be solved on the feature branch, and then we merge. So maybe you could add some check in a git hook, before merging into master, which ensures that you are up-to-date. Same as GitHub does below pull requests: It shows whether merging is possible.
    – Luc Franken
    Sep 5, 2016 at 10:27
  • How many branches would this affect? Isn't there a team member responsible for each of the branches?
    – Doc Brown
    Sep 5, 2016 at 11:00
  • 1
    In general each feature is implemented by a single developer, and each feature is on its own branch. They live for a couple of days, sometimes one week or two. I generally merge from master to my feature branch once per day, but sometimes it may so happen that I let it lag behind master a bit more than I should. Anyway, and as stated initially, I'm not particularly pumped about the idea, but I was unsure what the general trend on other teams/companies might be.
    – devoured elysium
    Sep 5, 2016 at 11:04

4 Answers 4

Reset to default
3

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.

Improve this answer
2

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.

Improve this answer
2
  • 1
    "Does master change every day?" - in many teams, it does. Either the team size is so big that almost every day one dev completes his work on a certain feature. Or the one who is in charge to define the features / user stories / development tasks manages it to break down bigger features into many small feature slices, which can be developed, tested and integrated in less than two days (and if your team works that way, that is a very good thing.)
    – Doc Brown
    Sep 5, 2016 at 13:17
  • 1
    Our master changes every day. Mostly for bug fixes here and there, or really minor stuff like adding JavaDoc / small aesthetic changes in the code that obviously don't require a full-blown branch on their own.
    – devoured elysium
    Sep 5, 2016 at 13:55
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.

Improve this answer
1

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.

Improve this answer
1
  • Seems a very good approach, indeed!
    – devoured elysium
    Sep 5, 2016 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.