通常我在master分支上工作,我做了一些提交,然后推送它.
然后我还需要将这些提交推送到其他分支.
通常,我会这样做:
$ git checkout another-branch
$ git cherry-pick commit1
$ git cherry-pick commit2
...
$ git cherry-pick commitn
$ git push
Run Code Online (Sandbox Code Playgroud)
某种愚蠢的,无论如何我可以从主分支的头部合并一些提交,所以我不必费心去挑选一个一个.
Cas*_*bel 10
听起来您可能希望在除master之外的分支上进行这些提交,然后将该分支合并到master和第二个分支:
git checkout working-branch
<do some work>
git commit
git checkout master
git merge working-branch
git checkout second-branch
git merge working-branch
Run Code Online (Sandbox Code Playgroud)
这比挑选樱桃更好,因为它不涉及复制历史中的提交,摆脱任何关于樱桃挑选提交两次的问题(你目前必须手动避免)...而且只是方式git旨在工作.我不知道你的第二个分支是什么,但我所描述的基本上是将维护和主题分支定期合并回主服务器以及任何其他适当的修改版本或维护分支的常见工作流程.
我强烈建议您采用如上所述通过合并完成此工作的工作流程,但要回答您提出的问题,如果您绝对必须使用master和cherry-pick,那么您可能想要自己写一个小脚本,某些东西喜欢:
#!/bin/bash
# take two arguments:
# 1. other branch to put commits on
# 2. number of commits to cherry-pick from master
if ! git checkout $1; then
exit
fi
git rev-list --reverse -n $2 master |
while read commit; do
if ! git cherry-pick $commit; then
exit
fi
done
Run Code Online (Sandbox Code Playgroud)
显然有一些方法可以使脚本更加健壮,例如,添加能够在其补丁不能正确应用的樱桃选择之后恢复的能力,但这是一个开始.
当然,您可以使用git-rev-list来选择提交.你甚至可以通过所有,但第一个参数一起的git-REV-列表,这样你就可以做cherries-pick <branch> -n 5 master或cherries-pick <branch> release_tag..master或任何你想要的.看看它的手册页!
您也可以git-rebase按照其他地方的建议使用,但因为您实际上并不想移动master,所以最终会执行以下操作:
git branch master-copy master
git rebase --onto <branch> master~5 master
git checkout <branch>
git merge master-copy
git branch -d master-copy
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
7767 次 |
| 最近记录: |