我正在编写一门编程课程，希望逐步展示如何编写程序。我想使用git来实现这个目的。我的想法是将每一个教训作为一个单独的分支，并随着课程的进行创建新的分支。
一切都很好，直到我发现在lesson1中犯了一个错误。所以我去那里修复了它。
现在问题出现了：我必须重新调整每一个分支。所以：
git checkout lesson2
git rebase lesson1
然后对于lesson3和lesson4同样进行操作。
每个课程有大约20课，所以每次出错都非常痛苦。是否有一种方法可以自动化或者至少让它变得更容易？
顺便说一句，我用来创建这些图片的工具可以在这里找到。
所以我必须重新开始...
之前我提出了一个简单的filter-branch命令，但这有一个重大缺陷。（tl;dr - 我不再建议使用filter-branch --parent-filter；除非您关心为什么，否则可以跳到下一段。）当您使用git filter-branch进行重定向时，它不会重新应用更改以实现有效合并，而是将树保留在重新指定的提交中（创建新的差异）。仍然可以使用filter-branch，但需要使用tree-filter或index-filter，这会变得相当复杂。（如果您可以在脚本中自动修复问题，则使用该脚本作为tree-filter可能有效-可能需要在rev-list参数中进行微调，但让我们假设对于常规情况来说这不是那么容易。我考虑过编写脚本的方法，将"fix"提交中的更改合并到移植中的每个提交中，但这可能会在每次转折处导致冲突，并且也不太容易...)
那么应该怎么办呢？好吧，像Libin Varghese建议的脚本化方法还可以接受，如果没有冲突，并且假设您可以以明智的方式迭代引用名称。但是如果存在冲突，那么还有另一种方法...
所以如果您有
Bfix <--(lesson1)
/
A --- B --- C --- D --- E <--(lesson3)(HEAD)
|
(lesson2)
C、D 和 E 重新应用到 Bfix 上，作为 C'、D' 和 E'（一个单一的变基操作）X）移动到其替换（X'）上lesson3 进行变基，则会出现以下情况： (lesson1)
|
Bfix --- C' --- D' --- E' <--(lesson3)(HEAD)
/
A --- B --- C <--(lesson2)
X”到“替换提交X'”建立映射。git show-ref将ref（分支）名称映射到“旧”的SHA1值，然后使用stdin上的映射查找相应的“新”SHA1值，并调用git update-ref。start=2
end=10
for i in {$start..$end}
do
git checkout lesson$i
git rebase lesson$(($i-1)) || break
done
start=$i
rebase --continue。git rebase lesson1 lesson2
具有与
相同的效果。git checkout lesson2
git rebase lesson1
git rebase lesson1 lesson4
然后使用类似以下命令将分支转移到新提交（如果课程是连续的）。
git branch lesson2a lesson4^2
git branch lesson3a lesson4^1
git branch lesson2a lesson4^"{/Partial lesson2 commit message}"
git branch lesson3a lesson4^"{/Partial Lesson3 commit message}"
git branch -f lesson2 lesson2a
git branch -D lesson2a
这个开源CLI将执行递归分支变基（披露一下，我是贡献者）： https://github.com/screenplaydev/graphite-cli
主要的变基递归可以在这里看到：https://github.com/screenplaydev/graphite-cli/blob/dfe4390baf9ce6aeedad0631e41c9f1bdc57ef9a/src/actions/fix.ts#L60
git rebase --onto ${parentBranch.name} ${mergeBase} ${currentBranch.name}
关键见解是在git refs中存储分支的父级，以便在操作过程中递归DAG。如果没有父级元数据，就无法始终确定连续子分支的合并基础。
const metaSha = execSync(`git hash-object -w --stdin`, {input: JSON.stringify(desc)}).toString();
execSync(`git update-ref refs/branch-metadata/${this.name} ${metaSha}`);
#!/bin/bash
if [ "$1" != "rebase" ]; then
exit 0
fi
orig=`git rev-parse ORIG_HEAD`
while read line
do
IFS=' '
read -ra map <<< "$line"
old="${map[0]}"
new="${map[1]}"
heads=`git show-ref | grep -e " refs/heads" | grep "$old"`
IFS=$'\n'
for h in $heads; do
IFS=' '
read -ra ref_info <<< "$h"
ref="${ref_info[1]}"
# Don't update original branch as this causes rebase to fail
if [ "$old" != "$orig" ]; then
echo "Updating '$ref' to $new"
`git-update-ref $ref $new $old`
fi
done
done
filter-branch所做的，或者更多（因此我的回答采用了这种方法）。Git分支足够简单，以至于我不确定是否应该称其为“累赘”，特别是如果他不时需要返回并修复“错误”的课程。但通常情况下标签会起到同样的作用。（除非他使用变基移动它们时会遇到相同的问题...）你有更简单的想法吗？ - Mark AdelsbergerHEAD^{/lesson 3}来查找提交。 - torekfilter-branch，但事实证明，对于具有非平凡分支拓扑的历史记录，变基是笨拙的方法。（最终我使用了BFG，但这与此无关...）我只能想到很少几个filter-branch操作不能用变基来表示，所以我不确定我是否同意它更强大，而更容易处理复杂操作。 - Mark Adelsberger