给出以下git历史记录:
将分支机构feature/1
和feature/2
重建到master
上以实现以下历史记录的最简单方法是:
到目前为止,我已经提出了以下建议:
feature/2
(我想作为基准的提交链的头)git rebase master
feature/1
分支的标题:git branch -f feature/1 <hash>
<hash>
是Feature 1
命令创建的重复rebase
提交的哈希。
它工作正常,但对我来说似乎太复杂了。
答案 0 :(得分:2)
最简单,最快的解决方案是您已经制定的解决方案。您可以合并步骤1和2
git rebase master feature/2
,在某些情况下(例如您的示例),可以轻松地计算出目标提交的表达式,您可能会发现避免处理提交ID更容易
git branch -f feature/1 feature/2^
正如其他人所述,您可以使用两个变基。但是,这并不简单。就是说,命令的复杂性是否更简单是一个意见问题。但是,实际上,您要告诉git进行的操作比较复杂。因此,出现错误的机会更大。例如,首先对feature/1
进行重新基准化,然后在feature/2
上对feature/1
进行重新基准化的特定技术依赖于在第二次重新基准化期间检测到重复的补丁程序ID,如果有的话,它将以不幸的方式失败解决第一个基准期间发生冲突。如果您真的想使用2-rebase方法,我建议您执行第二次rebase操作
git rebase --onto feature/1 feature/1@{1} feature/2
,因为这样甚至可以避免考虑重新重写feature/1
提交。 (feature/1@{1}
是一个reflog条目,指向feature/1
进行重新基准化之前。)但是,然后您使用的是不太常见的rebase语法,据我所知,它至少是“不简单”,就像您最初所做的一样。
或者,您可以使用--fork-point
来告诉git自动解释引用日志,并尝试找出哪些提交是伪造的。
git rebase --fork-point feature/1 feature/2
只要您在同一克隆上几乎同时执行两个基准操作,这在大多数情况下都会起作用。但是它增加了更多的复杂性(git在幕后做了“魔术”的形式),因此您需要了解它可能会出错,并且如果这样做(a)对它试图做的事情足够了解来诊断问题,或(b)退出并使用其他方法之一。
答案 1 :(得分:-2)
告诉git您在做什么,顺序是:
git rebase master feature/1
git rebase feature/1 feature/2
像这样,您可以进行以下操作:
git init test; cd $_
doit() { eval echo \>$*; git add $1; git commit -m "$2"; }
doit master "Initial commit"
git checkout -tb feature/1
doit file1 "Feature 1"
git checkout -tb feature/2
doit file2 "Feature 2"
git checkout master
doit master "New commit on master"
精确生成图形:
$ git log --graph --decorate --oneline --all
* 35cfad5 (feature/2) Feature 2
* 46b79ae (feature/1) Feature 1
| * ae89e31 (HEAD -> master) New commit on master
|/
* f1138eb Initial commit
$
现在,既然您告诉git您的分支结构,
$ git rebase master feature/1
First, rewinding head to replay your work on top of it...
Applying: Feature 1
$ git rebase feature/1 feature/2
First, rewinding head to replay your work on top of it...
Applying: Feature 2
$