2

We currently have a workflow where master is the more long-term feature release branch and numbered branches like 3.0 are for releases coming up in the next week or so.

With the above example, we are pushing several last minute changes to 3.0 that need to be merged into master. If we don't merge often, we'll wind up having master out of date without recent changes. If we merge as we go, we have logs full of merges from 3.0 to master.

The seemingly magical command git-rerere seems to solve this problem, but only for local topic branches that you need to update. In other words, it would work if 3.0 was only on one person's machine and not public.

Is there a way to keep master up-to-date without all the ugly merge noise? Do I understand the use of rerere?

hlovdal
  • 26,565
  • 10
  • 94
  • 165
Kyle Heironimus
  • 7,741
  • 7
  • 39
  • 51

1 Answers1

2

rerere stands for "Reuse Recorded Resolutions". All it does is make your merges/rebases easier by remembering decisions you made in the past. It doesn't make them less noisy when they actually happen; what it does allow is going longer without doing a merge (because you can "pre-flight" the merge and not push the results).

Why is "having logs full of merges" an issue? You can use git log --no-merges to show the log without the merge commits.

Your options are basically this:

  • Merge less often, which will make the merges, when you do need them, more difficult
  • Merge more often and live with having merge commits in your logs
  • Use rebasing, and deal with the issues that entails on a public repository
  • Use cherry-picking, which means the branches won't share history
Borealid
  • 95,191
  • 9
  • 106
  • 122
  • git log --no-merges can be very confusing because it hides the changes happening in the merge commits, especially when used with the -p flag. So in some situations it is a lot harder to work with a repo full of merge commits. – Étienne Feb 14 '20 at 12:42