合并冲突的樱桃挑选在git樱桃输出中仍显示为未合并

huangapple go评论59阅读模式
英文:

Merged conflict cherry-picks still show as not merged in git cherry output

问题

在一个存在冲突的情况下,将提交(cherry-pick)到另一个分支,需要在新分支中手动解决冲突,会导致原始提交ID在git cherry -v输出中不显示。我们如何使提交ID显示,以便知道修复已应用到分支中?

我试图确定主分支上的拉取请求是否已合并到子分支。还有更多细节,但让我首先为您介绍我们系统的设置。

我们使用Azure DevOps Server 2020以及Git。我们的分支设置有三个核心分支:mainpreReleasecurrentRelease,所有特性和bug分支都是从main分支创建的。一旦工作项(例如bug或特性)通过了所有测试的验证,与工作项关联的每个拉取请求都会从main分支cherry-pick到preRelease

对于没有冲突需要手动解决的cherry-pick拉取请求,这种设置运作良好。我们可以使用git cherry -v origin/preRelease origin/main命令来查看两个分支之间存在的提交和拉取请求。然后,我们可以筛选出所有以-开头的cherry列表,然后检查与拉取请求ID相关的工作项的状态,以确定是否应将其合并到preRelease分支。已经合并的分支会被过滤掉,因为它们在git cherry输出中以+开头。当存在具有冲突的cherry-pick时,看到的情况是,无法连接回原始提交和拉取请求,也不能通过git cherry命令的日志输出来显示提交已合并。

我以为问题可能出在我们将拉取请求合并到preRelease分支时的方式。然而,在DevOps中尝试不同的选项,如非快速前进合并、快速前进重置和半线性合并,都导致提交未显示为preRelease分支的一部分。这让我们相信工作项并未包含在分支中,尽管实际上它已经并入了代码。

因此,我的问题是,是否可以利用Git和Azure DevOps Server 2020 API来确定是否通过cherry-pick将提交合并到分支,即使由于合并冲突而创建了新分支。如果有更好的处理整个过程的方法,我愿意尝试。我绝不是Git或DevOps大师。如果我们用于在mainpreRelease之间迁移更新的cherry-pick流程是正确的,那么是否有办法追溯回需要创建新分支处理合并冲突的cherry-pick的原始提交ID。另外,当我们创建一个分支来处理合并冲突时,我们从preRelease分支开始,拉取最新的代码,然后从preRelease分支创建一个新分支,并执行git cherry-pick <commit id>来拉取要合并的代码。还尝试过git cherry-pick -m 1 <commit id>,但在生成的提交日志中没有看到原始提交ID的区别。

英文:

tldr; Cherry-picking commit into another branch where a conflict exists, requiring manual resolution in a new branch, causes the original commit id to not show in the git -cherry -v output. How can we get the commit id to show so we know the fix was applied to a branch?

I'm trying to determine whether a pull request on main was merged into a child branch. There is more to it but let me first give you the setup of our system.

We are using Azure DevOps Server 2020 along with git. Our branching is set up with three core branches, main, preRelease, and currentRelease, with all feature and bug branches being created off of the main branch. Once a work item (i.e. bug or feature) is verified as passing all tests, each pull request associated with the work item gets cherry-picked from main into preRelease.

This setup works well for cherry-picked pull requests that don't have conflicts which require a manual reconciliation of the changes. We are able to use the git cherry -v origin/preRelease origin/main command to see which commits and pull requests exist between the two branches. We can then filter out all cherry listings that start with a - and then check the status of the work item associated with the pull request id to determine if it is in a state where it should be merged into the preRelease branch. The branches that were already merged are filtered out because they start with a + in the git cherry output. What is seen when there is a cherry-pick that has conflicts is that the connection back to the original commit and pull request is not available and not updating the log output from the git cherry command to show the commit was merged.

I thought that the problem might be how we are completing the pull request when we merge it into the preRelease branch. However, attempting the different options in DevOps, Merge no fast-forward, Rebase fast-forward, and Semi-linear merge, all resulted in the commit not showing up as a part of the preRelease branch. This leads us to believe that the work item isn't part of the branch when in fact it already is incorporated into the code.

So my question is whether it is possible to utilize git and the Azure DevOps Server 2020 API to determine whether a commit has been merged into a branch via cherry-pick, even if it was merged by a new branch because of merge conflicts. If there is a better way to handle this whole process I am open to it. I am by no means a git or DevOps guru. If the cherry-pick process we have for migrating updates between main and preRelease is the way to go then is there a way to trace back the original commit from a cherry-pick that required a new branch to be created for the handling of merge conflicts. Note, when we create a branch to handle the merge conflicts we start in the preRelease branch, pull down the latest code, then create a new branch off of preRelease and execute a git cherry-pick &lt;commit id&gt; to pull down the code for merging. Also tried git cherry-pick -m 1 &lt;commit id&gt; but didn't see a difference in the resulting commit logs to show the original commit id.

答案1

得分: 0

git cherry无法找到该提交,因为这些提交引入了不同的更改。

假设你挑选了一个提交,向文件追加了十行。但是然后你尝试将其挑选到一个已经应用了三行到相同位置的历史中。因此你解决了冲突。但是由于这三行不同,原始提交和新提交的更改现在也不同了。所以git cherry比较它们的更改(一种简化版本的差异),比较失败。

对于传播从开发到预发行以及发布等的更改,樱桃挑选太过脆弱。请改用合并。

英文:

git cherry won’t find the commit since the commits introduce different changes.

Suppose you cherry-picked a commit that appended ten lines to a file. But then you tried to cherry-pick it onto a history where three lines had been applied to the same place. So you resolve the conflict. But the changes from the original commit and the new commit are different now since those three lines are different. So git cherry compares their changes (a simplified version of the diffs) and the comparison fails.

Cherry-picks are way too brittle to rely on for propagating changes from development to prerelease and to release or whatever have you. Use merges instead.

huangapple
  • 本文由 发表于 2023年3月31日 03:53:27
  • 转载请务必保留本文链接:https://go.coder-hub.com/75892431.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定