标签: git-cherry-pick

昨天我挑选了两个提交到我的主分支,其中一个引起了合并冲突,我解决了它们,承诺并将它们推向原点.今天我收到以下错误时试图从服务器拉出来:

$ git pull
fatal: You have not concluded your cherry-pick (CHERRY_PICK_HEAD exists).
Please, commit your changes before you can merge.
$

Git状态如下:

$ git status
# On branch main
# Your branch is behind 'origin/main' by 2 commits, and can be fast-forwarded.
#
$

我试过以下无济于事:

$ git cherry-pick --continue
usage: git cherry-pick [options] <commit-ish>
$

关于如何解决这个问题的任何想法？提前致谢!

有两种不同的git分支.在一个开发进入(Branch1).

在其他分支中,一些PoC工作正在进行(Branch2).现在,我想挑选从Branch1到Branch2的更改,以便Branch2是最新的.

现在,在挑选了4或5个变化后,我发现了一些合并冲突,我无法继续进行更多挑选.

在进行下一次樱桃挑选之前,我需要解决所有冲突吗？或者我能否以某种方式推迟解决冲突,直到我挑选所有的变化(并一起解决所有冲突)？

此外,是否建议在这种情况下进行樱桃挑选或分支合并？

我从我的分支机构的gerrit评论中选择了樱桃.在gerrit代码审查中,我有两个补丁集和我之前挑选过的补丁,所以现在我想做第二个补丁集,但是有冲突,我怎么能强制git接受所有的更改？谢谢!

我确信这是一个很简单的问题并得到了回答,但我不知道要搜索的条款.我有这个:

    /--master--X--Y
A--B
    \--C--D--E

我在一个分支上提交C,D和E(仅限本地),但后来我意识到D和E实际上是独立于C.我想将C移动到它自己的分支,并保留D和E以供日后使用.也就是说,我想要这个:

                   /--C
    /--master--X--Y
A--B
    \--D--E

我怎样从D和E下面抽出C？

有什么区别git merge --no-commit和git cherry-pick --no-commit？

如果我遵循这两个命令后,历史上有什么不同吗？

我搜索了很多以下问题,但无法获得任何实质性信息...请帮助我,创建一个临时分支202116,我正在尝试做一个gerrit 202116的樱桃,我收到以下消息,为什么我不是能够挑选这种微粒,为什么我会收到这个错误？请提供您的意见

<>git fetch ssh://company@company.com:29418/platform/vendor/company-proprietary/radio refs/changes/25/202116/1 && git cherry-pick FETCH_HEAD
From ssh://company.com:29418/platform/vendor/company-proprietary/radio
 * branch            refs/changes/25/206025/1 -> FETCH_HEAD
# On branch 202116
# You are currently cherry-picking.
#   (all conflicts fixed: run "git commit")
#
nothing to commit, working directory clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

git有时会在冲突中给出这个消息(在恢复或樱桃选择期间)

hint: after resolving the conflicts, mark the corrected paths

这是什么意思？

我在主分支中有33个提交被网格化.现在我需要整齐地保持记录.所以现在我已经创建了功能分支,我试图在不同的功能分支中对这33个提交进行分类.那么可以一次选择多个提交来复制相关的功能分支吗？当我尝试使用cherry-pick命令进行多次提交时,我也面临着冲突.

git cherry-pick A B C

这里A,B,C是提交的哈希码.

在正常的Git合并冲突中,三向合并的三个版本的文件大致如下:

• LOCAL:我的分支机构的版本
• REMOTE:来自其他分支的版本
• BASE:来自两个分支的共同祖先的版本(特别是我的分支的HEAD的共同祖先和另一个分支的HEAD)

当一个Git樱桃挑选产生合并冲突时,没有共同的祖先,正确地说,那么这些东西是如何确定的？关于rebase也可以这样说.

背景资料:

由于现有系统的工作流程受到限制,我们需要建立一个有点非正统的git过程.

(patch)    A-B---F
             |   |
(hotfix)     C-D-E
                 |
(dev)      1-2-3-G

在补丁分支上,有一些提交.这里的文件与dev上的文件类似但不完全相同(同步脚本按照许多文件中的设置顺序切换,使它们在功能上相同时显示为已更改).

此分支需要修复,以便创建并处理修补程序分支.然后,这个分支合并回补丁,到目前为止,非常好.

需要将相同的修补程序部署到dev分支,以使其与修补程序保持相对同步,但尝试合并修补程序分支会导致git尝试合并来自A和B的所有不相关和"未更改"的文件,而不是只有C,D和E.

题:

看起来,cherry-pick做了我们想要的只是从选择的提交中获得更改,但我真的想要一种方法来同时挑选给定分支中的所有提交,而不必每次都查找提交ID .