我的主人有两个分支:
v2.1 :(第2版)我已经工作了几个月
wss :我昨天创建的是为我的主人添加一个特定功能(在制作中)
有没有办法将昨天的提交从wss复制到v2.1?
你应该有一个工作流程,让你通过合并完成所有这些:
- x - x - x (v2) - x - x - x (v2.1) \ x - x - x (wss)
所以你所要做的就是 git checkout v2.1 和 git merge wss . 如果由于某种原因你真的可以使用git rebase将你的wss分支移动到正确的位置,那么从某个地方获取单个提交并将其应用到其他地方的命令是git cherry-pick . 只需检查要应用它的分支,然后运行 git cherry-pick <SHA of commit to cherry-pick> .
git checkout v2.1
git merge wss
git cherry-pick <SHA of commit to cherry-pick>
rebase的一些方法可能会拯救你:
如果您的历史记录如下:
- x - x - x (v2) - x - x - x (v2.1) \ x - x - x (v2-only) - x - x - x (wss)
您可以使用 git rebase --onto v2 v2-only wss 将wss直接移动到v2:
git rebase --onto v2 v2-only wss
- x - x - x (v2) - x - x - x (v2.1) |\ | x - x - x (v2-only) \ x - x - x (wss)
然后你可以合并!如果你真的,真的,真的无法达到你可以合并的程度,你仍然可以使用rebase一次有效地做几个樱桃选择:
# wss-starting-point is the SHA1/branch immediately before the first commit to rebase git branch wss-to-rebase wss git rebase --onto v2.1 wss-starting-point wss-to-rebase git checkout v2.1 git merge wss-to-rebase
注意:为了做到这一点需要额外工作的原因是它在您的存储库中创建了重复的提交 . 这不是一件好事 - 简单分支和合并的关键在于能够通过将提交放在一个地方并将它们合并到需要的任何地方来完成所有事情 . 重复提交意味着永远不会合并这两个分支的意图(如果您决定以后再进行,则会产生冲突) .
使用
git cherry-pick <commit>
将 <commit> 应用于 current branch .
<commit>
我自己可能会交叉检查我在 gitk 中选择的提交,然后通过右键单击提交条目来挑选它们 .
gitk
如果你想更自动(带有所有危险)并假设自昨天以来所有提交都发生在wss上你可以使用 git log 生成提交列表( --pretty 由Jefromi建议)
git log
--pretty
git log --reverse --since=yesterday --pretty=%H
所以一切都假设你使用 bash
bash
for commit in $(git log --reverse --since=yesterday --pretty=%H); do git cherry-pick $commit done
如果这里出现问题(有很多潜力),你就会遇到麻烦,因为这会影响实时结账,所以要么手动挑选,要么像Jefromi建议的那样使用rebase .
git cherry-pick :应用某些现有提交引入的更改
git cherry-pick
假设我们有分支 A 与(X,Y,Z)提交 . 我们需要将这些提交添加到分支 B . 我们将使用 cherry-pick 操作 .
cherry-pick
当我们使用 cherry-pick 时,我们应该按照提交出现在Branch A 中的相同时间顺序在分支 B 上添加提交 .
cherry-pick确实支持一系列提交,但如果你在该范围内有合并提交,它会变得非常复杂
git checkout B git cherry-pick SHA-COMMIT-X git cherry-pick SHA-COMMIT-Y git cherry-pick SHA-COMMIT-Z
工作流程示例:
我们可以使用 cherry-pick 和options
-e或--edit:使用此选项,git cherry-pick将允许您在提交之前编辑提交消息 .
-n或--no-commit:通常命令会自动创建一系列提交 . 此标志应用必要的更改来挑选您的工作树和索引的每个命名提交,而不进行任何提交 . 此外,使用此选项时,索引不必与HEAD提交匹配 . 樱桃选择是针对索引的开始状态完成的 .
这里有一个有趣的article关于 cherry-pick .
您可以从要复制的提交create a patch和apply the patch到目标分支 .
或者,如果你在福音传道者身上少一点,你可以做一些我正在使用的丑陋方式 . 在deploy_template中,我想要在我的主服务器上作为分支部署进行复制
git branch deploy deploy_template git checkout deploy git rebase master
这将在deploy_template上创建新的分支部署(我使用-f来覆盖现有的部署分支),然后将这个新分支重新绑定到master上,而不改变deploy_template .
对于仅将最后一次提交从分支wss复制到v2.1的简单情况,您只需获取提交ID( git log --oneline | head -n 1 )并执行:
git log --oneline | head -n 1
git checkout v2.1 git merge <commit>
6 回答
你应该有一个工作流程,让你通过合并完成所有这些:
所以你所要做的就是
git checkout v2.1
和git merge wss
. 如果由于某种原因你真的可以使用git rebase将你的wss分支移动到正确的位置,那么从某个地方获取单个提交并将其应用到其他地方的命令是git cherry-pick . 只需检查要应用它的分支,然后运行git cherry-pick <SHA of commit to cherry-pick>
.rebase的一些方法可能会拯救你:
如果您的历史记录如下:
您可以使用
git rebase --onto v2 v2-only wss
将wss直接移动到v2:然后你可以合并!如果你真的,真的,真的无法达到你可以合并的程度,你仍然可以使用rebase一次有效地做几个樱桃选择:
注意:为了做到这一点需要额外工作的原因是它在您的存储库中创建了重复的提交 . 这不是一件好事 - 简单分支和合并的关键在于能够通过将提交放在一个地方并将它们合并到需要的任何地方来完成所有事情 . 重复提交意味着永远不会合并这两个分支的意图(如果您决定以后再进行,则会产生冲突) .
使用
将
<commit>
应用于 current branch .我自己可能会交叉检查我在
gitk
中选择的提交,然后通过右键单击提交条目来挑选它们 .如果你想更自动(带有所有危险)并假设自昨天以来所有提交都发生在wss上你可以使用
git log
生成提交列表(--pretty
由Jefromi建议)所以一切都假设你使用
bash
如果这里出现问题(有很多潜力),你就会遇到麻烦,因为这会影响实时结账,所以要么手动挑选,要么像Jefromi建议的那样使用rebase .
git cherry-pick
:应用某些现有提交引入的更改假设我们有分支 A 与(X,Y,Z)提交 . 我们需要将这些提交添加到分支 B . 我们将使用
cherry-pick
操作 .当我们使用
cherry-pick
时,我们应该按照提交出现在Branch A 中的相同时间顺序在分支 B 上添加提交 .cherry-pick确实支持一系列提交,但如果你在该范围内有合并提交,它会变得非常复杂
工作流程示例:
我们可以使用
cherry-pick
和options-e或--edit:使用此选项,git cherry-pick将允许您在提交之前编辑提交消息 .
-n或--no-commit:通常命令会自动创建一系列提交 . 此标志应用必要的更改来挑选您的工作树和索引的每个命名提交,而不进行任何提交 . 此外,使用此选项时,索引不必与HEAD提交匹配 . 樱桃选择是针对索引的开始状态完成的 .
这里有一个有趣的article关于
cherry-pick
.您可以从要复制的提交create a patch和apply the patch到目标分支 .
或者,如果你在福音传道者身上少一点,你可以做一些我正在使用的丑陋方式 . 在deploy_template中,我想要在我的主服务器上作为分支部署进行复制
这将在deploy_template上创建新的分支部署(我使用-f来覆盖现有的部署分支),然后将这个新分支重新绑定到master上,而不改变deploy_template .
对于仅将最后一次提交从分支wss复制到v2.1的简单情况,您只需获取提交ID(
git log --oneline | head -n 1
)并执行: