admin管理员组

文章数量:1410725

Our team is struggling with frequent merge conflicts due to managing multiple versions simultaneously. We're looking for a workflow that reduces these conflicts.

Our Environments:

We maintain multiple environments, each running different versions of our application:

• PROD – Production environment
• SANDBOX – Customer testing/integration environment
• TEST – Internal testing (manual + automated) before promoting to SANDBOX
• DEV – Developer playground for feature testing and bug fixes

Current Workflow (GitFlow):

We currently use GitFlow, maintaining multiple long-lived branches:

• release/1.0 – Deployed on PROD/SANDBOX; only bug fixes and critical features are merged
• develop – Next release candidate (deployed on TEST/DEV)
• plan/1.1, plan/1.2, etc. – Future feature branches (used when releases are delayed, but rarely)

This leads to significant merge conflicts because:

• Changes in release branches need to be merged into develop and plan.
• Develop must be merged into plan after every feature or bugfix merge.
• Frequent refactoring exacerbates conflicts.
• Version updates (pom.xml changes) cause conflicts, as both source and target branches modify the version.

Trunk-Based Development (TBD) and Version Management:

I started experimenting with TBD, hoping it would simplify our workflow. If I understand correctly, in TBD:

• All development happens on trunk.
• Release branches are created only when needed and receive cherry-picked bug fixes.

The problem I don’t understand is how to handle version updates on trunk while supporting multiple versions.

Example Scenario:

• We support 1.0.x while developing 1.1.x.
• We create release/1.0 and start cherry-picking fixes.
• A release commit (e.g., "release 1.0.0") happens on trunk and is cherry-picked into release/1.0.
• Later, we release 1.1.0, which updates the version in pom.xml.
• Now, if we need to release 1.0.3 with a bugfix, it looks like the version is decreasing on trunk, which is misleading.

My Questions:

1. In TBD, where should version updates (pom.xml changes) happen?
   • If they happen on the release branch, the trunk never shows version changes.
   • If they happen on trunk, it can appear as if the version is rolling back when cherry-picking bug fixes.
2. What’s the recommended way to handle multiple active versions in TBD without causing confusion or conflicts?

Would appreciate insights from teams who have successfully implemented TBD with multiple active versions.

I've read the documentation on trunkbaseddevelopment but it doesn't seem to address this specific problem, or maybe i misunderstood something about the concept.

Our team is struggling with frequent merge conflicts due to managing multiple versions simultaneously. We're looking for a workflow that reduces these conflicts.

Our Environments:

We maintain multiple environments, each running different versions of our application:

• PROD – Production environment
• SANDBOX – Customer testing/integration environment
• TEST – Internal testing (manual + automated) before promoting to SANDBOX
• DEV – Developer playground for feature testing and bug fixes

Current Workflow (GitFlow):

We currently use GitFlow, maintaining multiple long-lived branches:

• release/1.0 – Deployed on PROD/SANDBOX; only bug fixes and critical features are merged
• develop – Next release candidate (deployed on TEST/DEV)
• plan/1.1, plan/1.2, etc. – Future feature branches (used when releases are delayed, but rarely)

This leads to significant merge conflicts because:

• Changes in release branches need to be merged into develop and plan.
• Develop must be merged into plan after every feature or bugfix merge.
• Frequent refactoring exacerbates conflicts.
• Version updates (pom.xml changes) cause conflicts, as both source and target branches modify the version.

Trunk-Based Development (TBD) and Version Management:

I started experimenting with TBD, hoping it would simplify our workflow. If I understand correctly, in TBD:

• All development happens on trunk.
• Release branches are created only when needed and receive cherry-picked bug fixes.

The problem I don’t understand is how to handle version updates on trunk while supporting multiple versions.

Example Scenario:

• We support 1.0.x while developing 1.1.x.
• We create release/1.0 and start cherry-picking fixes.
• A release commit (e.g., "release 1.0.0") happens on trunk and is cherry-picked into release/1.0.
• Later, we release 1.1.0, which updates the version in pom.xml.
• Now, if we need to release 1.0.3 with a bugfix, it looks like the version is decreasing on trunk, which is misleading.

My Questions:

1. In TBD, where should version updates (pom.xml changes) happen?
   • If they happen on the release branch, the trunk never shows version changes.
   • If they happen on trunk, it can appear as if the version is rolling back when cherry-picking bug fixes.
2. What’s the recommended way to handle multiple active versions in TBD without causing confusion or conflicts?

Would appreciate insights from teams who have successfully implemented TBD with multiple active versions.

I've read the documentation on trunkbaseddevelopment but it doesn't seem to address this specific problem, or maybe i misunderstood something about the concept.

• git
• cicd
• git-flow
• tbd

Share Follow asked Mar 11 at 7:41 Baksa ZoltánBaksa Zoltán 7955 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

The reference website says that release branches are optional.

1. A release can happen on trunk
2. Or on a release branch

The latter can happen because you might want to “harden” a release. Which I interpret as cutting a release point, testing it, and incorporating urgent fixes. Meanwhile trunk can continue its life with whatever other changes which will not impact the release branch.

Keep in mind that there’s another dimension here:

1. A preemptive release branch (what we just discussed)

2. An after-release release branch

   - - - ★ - ★ - ★ - ★ trunk
          \v1.0
   

The latter here is relevant if you released 1.0, a bug was found and you need some version like 1.0.1 with just that bug fix. But trunk has many more commits at this point. But that’s not a problem. Just check out the tag and make a release branch. Then you can incorporate the change there.

How to incorporate changes between trunk and the release branches

How do you incorporate changes between the eternal trunk branch and the releases?

The reference has its guideline for this:

The best practice for Trunk-Based Development teams is to reproduce the bug on the trunk, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.

Apparently this is the Trunk Based Development approach. But I disagree. This is not the correct approach if you want to handle changes in the best way with Git.

Take the bug on v1.0 example. Is the bug urgent enough to fix on top of v1.0 and make a bug fix version? Then fix it there.

- - - ★ - ★ - ★ - ★ trunk
      v1.0 - ★ (bugfix)

Then merge it into trunk:

- - - ★ - ★ - ★ - ★ - - - ★ (merge) trunk
      v1.0 - ★ (bugfix) /

Now the upcoming v1.0.1 (or whatever it will be) will have the commit. Just query it:

git tag --contains=<bugfix commit>

As does trunk. Just query it:

git branch --contains=<bugfix commit>

You cannot directly query it if you use cherry-picks.

You should also get less merge conflicts since there is less merge-base drift when you avoid cherry-picks. You can imagine multiple releases and multiple cherry-picks on top of release branches or trunk. That means that Git has to go further back to calculate differences when doing future merges.

And if you have multiple releases? Merge upwards from the oldest release to trunk. For the release branches corresponding to these tags:

1. v1.0.1 into 1.5.5
2. 1.5.5 into 1.7.0
3. 1.7.0 into trunk

Imagine having to use cherry-picks for all of that instead. The work compounds.

When cherry-picks might be relevant

The merge approach works well when you apply the change to the correct place from the start. But sometimes you might apply a fix to trunk and then later figure out that you want it in some release branch as well. Use cherry-pick in that case since that’s the only option anyway.

TBD website says not to do this

This should not be done according to the reference website:

You should not fix bugs on the release branch in the expectation of cherry-picking them back to the trunk. Why? Well in case you fet to do that in the heat of the moment. Fetting means a regression in production some weeks later (and someone getting fired).

(Why not merge instead of cherry-pick?)

The emphasis on “fetting” seems arbritrary here since their recommended approach is to fix on trunk, then wait until CI passes, then finally cherry-pick to the release branch. Well. What if you fet to cherry-pick that way?

We might risk getting fired here according to their corporate crystal ball. But fixing on the release branch and then merging to trunk is both neater and prioritizes the most immediate need:

1. The upcoming release has the fix
2. You might break trunk with a fix that works well for the release branch but not on trunk for some reason, which is a small inconvenience compared to a broken release
3. You have all the time until the next release to remember to merge to trunk before the harm is done
   • Granted this is not a strong point if you release every day
   • But just merge immediately to trunk and don’t worry about fetting it in the first place

Questions

In TBD, where should version updates (pom.xml changes) happen?

This does not have anything to do with any version strategy. The Maven Masters demand a build to have the correct version. So you need to have that on whatever commit you choose to release on.

What’s the recommended way to handle multiple active versions in TBD without causing confusion or conflicts?

It is poorly thought out. See the reference website again:

Merge Meister role

The process of merging commits from trunk to the release branch using ‘cherry pick’ is a role for a single developer in a team. Or dev pair, if you are doing Extreme Programming. Even then, it is a part time activity. The dev or pair probably needs to police a list of rules before doing the cherry pick. Rules like which business representative signed off on the merge. Perhaps the role should also rotate each day.

Some teams update a wiki to audit what made it to the release branch after branch cut, and some use ticket system as this by its nature interrupting and requiring of an audit trail of approvals.

The “merging” here means cherry-picking all changes that are going into a release.

• A part time activity?
• Police a set of rules?
• Business representative signoff?
• Wiki to audit release branch?

No thanks. All you need:

• trunk is the default target for all development
• But first target the release branch for something that is going into a fix for a release and you cannot do it on trunk (because trunk has moved on and has things that should not go into the fix release)
• Then merge the changes into other release branches (if applicable) and finally trunk

Now, as mentioned, it is simple to query exactly what commits are in what tags and branches. It’s simple to see the discrepancy between any two points in the history. No “wiki to audit” needed beyond the standard fare (maybe issue tracker keys from the commit messages).

本文标签： gitHow to manage multiple version at the same time in TBDStack Overflow