Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
164 views
in Technique[技术] by (71.8m points)

Git merge creating conflicts when it shouldn't

We have two branches: master and dev. Our ci deploys to production upon a merge into master.

Now, we do our development in dev and intend to merge to master when we wish to deploy. We do not do development in master.

When we open pull requests to master from dev we are greetings with 'conflicts'. These conflicts are a list of the changes we made in dev. Resolving these conflicts means going through them manually and selecting the changes from dev in each case.

Why is the merge considering these conflicts? No changes were made to these files in master between merge events. Why isn't automerge just applying all the changes we made in dev to master instead of flagging them?

question from:https://stackoverflow.com/questions/65875789/git-merge-creating-conflicts-when-it-shouldnt

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

You shouldn't use squash merges to merge two long-lived branches. Always use a merge commit.

The Git FAQ explains why using squash merges in this case is a problem:

When Git does a normal merge between two branches, it considers exactly three points: the two branches and a third commit, called the merge base, which is usually the common ancestor of the commits. The result of the merge is the sum of the changes between the merge base and each head. When you merge two branches with a regular merge commit, this results in a new commit which will end up as a merge base when they’re merged again, because there is now a new common ancestor. Git doesn’t have to consider changes that occurred before the merge base, so you don’t have to re-resolve any conflicts you resolved before.

When you perform a squash merge, a merge commit isn’t created; instead, the changes from one side are applied as a regular commit to the other side. This means that the merge base for these branches won’t have changed, and so when Git goes to perform its next merge, it considers all of the changes that it considered the last time plus the new changes. That means any conflicts may need to be re-resolved.

There is no way to do this with squash merges that avoids this problem.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...