英文:
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。我们的分支设置有三个核心分支:main
、preRelease
和currentRelease
,所有特性和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大师。如果我们用于在main
和preRelease
之间迁移更新的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 <commit id>
to pull down the code for merging. Also tried git cherry-pick -m 1 <commit id>
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论