Skip to main content
Solved

Updating a feature branch by merging from develop a bad idea?

  • December 19, 2024
  • 3 replies
  • 60 views
P
Captain
Forum|alt.badge.img+5

Consider the following scenario (from Manage branches with Thinkwise | Thinkwise Community)

In this scenario the Develop branch is merged to the Feature 2 branch. This works fine up to the point that Feature 2 is merged back to Develop. The SF (2024.3) will see all changes made to Develop between the creation of Feature 2 and the merge from Develop to Feature 2 as changes that are also made in Feature 2. This results in a lot of conflicts because everything that was added/changed in Develop will be seen as also added/changed in Feature 2 in the merge proces. 

Conflicts are at least a trigger for a developer to look at it and make a choice, but what makes it  worse is when you have created an object in Feature 1, and after the merge from Develop to Feature 2, the object is changed (renamed or deleted). The merge of feature 2 to Develop will not result in a conflict for this object, but it will add the object again with the old name.

 

Could we be doing something wrong when following this scenario? Or is this a bug?

I noticed that the ‘Origin model version’ of Feature 2 is the date when the branch was created, while I would have expected that this would get updated to a new model version when Develop was merged to Feature 2. 

 

 

 

Best answer by Mark Jongeling

Hi Peter,

This is indeed the result of merging all changes from the Origin into the Branch. We are aware of this, and I have experienced it first-hand a couple times now. Updating your Branch with changes from the Origin is not a bad thing to do but does brings in the possibility of many conflicts.

I noticed that the ‘Origin model version’ of Feature 2 is the date when the branch was created, while I would have expected that this would get updated to a new model version when Develop was merged to Feature 2. 

It did used to work like that actually. However, the origin model version is used as baseline for the difference analysis part of a merge session. Based on that point-in-time, all modifications of the involved branches are taken into account. 

If the origin model version would be moved, objects that were added in your branch prior to the merge session from the Origin into your Branch will not be seen as changes anymore, and then it also results in them not being merged into the Origin at a later stage.

By definition, the Origin model version indicates the point-in-time that the content of the Branch is exactly the same as the content of its Origin.

At this stage, the alternative is to create a fresh new branch from the Origin and then merging your existing feature branch into the new feature branch; an Arbitrary merge. This will apply all modifications of your earlier feature branch on a fresh copy. I haven't tried this myself yet though but this should be the solution.

View original
Did this topic help you find an answer to your question?
This topic has been closed for comments

3 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 3936 replies
  • Answer
  • December 19, 2024

Hi Peter,

This is indeed the result of merging all changes from the Origin into the Branch. We are aware of this, and I have experienced it first-hand a couple times now. Updating your Branch with changes from the Origin is not a bad thing to do but does brings in the possibility of many conflicts.

I noticed that the ‘Origin model version’ of Feature 2 is the date when the branch was created, while I would have expected that this would get updated to a new model version when Develop was merged to Feature 2. 

It did used to work like that actually. However, the origin model version is used as baseline for the difference analysis part of a merge session. Based on that point-in-time, all modifications of the involved branches are taken into account. 

If the origin model version would be moved, objects that were added in your branch prior to the merge session from the Origin into your Branch will not be seen as changes anymore, and then it also results in them not being merged into the Origin at a later stage.

By definition, the Origin model version indicates the point-in-time that the content of the Branch is exactly the same as the content of its Origin.

At this stage, the alternative is to create a fresh new branch from the Origin and then merging your existing feature branch into the new feature branch; an Arbitrary merge. This will apply all modifications of your earlier feature branch on a fresh copy. I haven't tried this myself yet though but this should be the solution.

"Wake me up before you low-code"
P
Captain
Forum|alt.badge.img+5
  • PeterKeerisCaptain
  • Author
  • Captain
  • 36 replies
  • December 19, 2024

Hi Mark,

Thanks for your response. 

Mark Jongeling wrote:

At this stage, the alternative is to create a fresh new branch from the Origin and then merging your existing feature branch into the new feature branch; an Arbitrary merge. This will apply all modifications of your earlier feature branch on a fresh copy. I haven't tried this myself yet though but this should be the solution.

I will try this next time when we want to update a feature branch. If this works as intended, wouldn't it be better to make this the actual behaviour of the SF when merging back from an origin branch to a feature branch?

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 3936 replies
  • December 19, 2024
PeterKeeris wrote:

If this works as intended, wouldn't it be better to make this the actual behaviour of the SF when merging back from an origin branch to a feature branch?

I would prefer that as well. 😄

Although it would cost more time in the beginning, it will indeed save time at the end when ready to merge from branch to origin. 

"Wake me up before you low-code"
Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings