“git rebase”会更新被挑选并在重定位之前有引用的新提交的引用吗？
在重定位之前，不会。
但是在重定位过程中呢？可能会。
使用Git 2.38（2022年第三季度），“git rebase -i”（参见man手册）学会了通过“--update-refs”选项更新出现在重定位范围内的分支的末端。
查看
7fefa1b 提交（2022年7月12日）由
Junio C Hamano (gitster)。
查看
4611884 提交,
aa37f3e 提交,
3113fed 提交,
b3b1a21 提交,
89fc0b5 提交,
900b50c 提交,
a97d791 提交,
d7ce9a2 提交,
f57fd48 提交,
aa7f2fd 提交,
18ea595 提交,
1bec4d1 提交（2022年7月19日）由
Derrick Stolee (derrickstolee)。
（由Junio C Hamano -- gitster --于2022年8月1日合并至3d8e3dc 提交）
rebase: 添加--update-refs选项
签名作者：Derrick Stolee
在开发一个大型特性时，将其分成多个小部分并按顺序进行审查可能会很有帮助。在开发或审查过程中，对特性的某一部分进行更改可能会影响多个这些部分。交互式变基可以帮助调整分支的多部分“故事”。
然而，如果有跟踪特性不同部分的分支，则重新设置整个提交列表可能会创建无法从这些“子分支”到达的提交。需要手动更新这些分支。
在 "
git rebase -i"
(man) 中添加一个新的
--update-refs选项，每当正在重新设置的提交被装饰时，在todo文件中添加'update-ref '步骤。最后，重新设置过程会更新所有列出的引用以存储在重新设置操作期间存储的值。
确保在放置任何压缩或修复之后进行迭代。只有在完成这些压缩和修复之后才更新分支。这样，即使修复了该部分中最近的提交，位于特性末端的
--fixup提交也可以正确应用于子分支。
此更改更新文档和内置程序，接受
--update-refs选项，并使用'update-ref'命令更新todo文件。添加测试以确保在正确的位置添加这些todo命令。
该更改不包括跟踪更新的引用并在重新设置过程结束时编写新的引用值的实际行为。这将推迟到以后的更改中。
git rebase现在在其手册页面中包括以下内容：
--update-refs
--no-update-refs
自动强制更新任何指向正在进行变基的提交的分支。
在工作树中检出的任何分支不会以这种方式更新。
还有：
rebase：从“update-ref”命令更新引用
Signed-off-by: Derrick Stolee
先前的更改引入了 '
git rebase --update-refs'
(man) 选项，该选项将 '
update-ref <ref>' 命令添加到交互式 rebase 的
todo 列表中。
教 Git 在到达这些 'update-ref' 命令时记录 HEAD 的位置。
ref/before/after 三元组存储在
$GIT_DIR/rebase-merge/update-refs 文件中。
先前的更改解析了此文件，以避免在 rebase 进行期间其他进程更新该文件中的引用。
当序列化器到达这些 'update-ref' 命令时，我们不仅会更新文件，还会在 rebase 序列的末尾更新引用本身。
如果在此最后一步之前中止 rebase，则不会更新引用。
before 值用于确保我们不会意外地覆盖同时更新的引用（例如，由较旧版本的 Git 或第三方工具）。
结果：
序列控制器：通知用户 --update-refs 活动
报告者：Elijah Newren
签名者：Derrick Stolee
When the user runs 'git rebase -i --update-refs'(man), the end message still says only
Successfully rebased and updated <HEAD-ref>.
Update the sequencer to collect the successful (and unsuccessful) ref updates due to the --update-refs option, so the end message now says
Successfully rebased and updated <HEAD-ref>.
Updated the following refs with --update-refs:
efs/heads/first
efs/heads/third
Failed to update the following refs with --update-refs:
efs/heads/second
`git rebase --update-refs`（见{{link1：
git rebase --update-refs}}
（man））在Git 2.39（2022年第4季度）已得到修正，不再会在序列器中移除所有 `update-ref` 命令时删除引用。
查看
提交 44da9e0（2022年11月7日），提交人为
Victoria Dye (vdye)。
（由Taylor Blau -- ttaylorr --合并于提交 35dc2cf，2022年11月18日）
报告人：herr.kaste
协助者：Phillip Wood
协助者：Derrick Stolee
签署者：Victoria Dye
签署者：Taylor Blau
在
b3b1a21（“
sequencer: rewrite update-refs as user edits todo list”，2022年7月19日，Git v2.38.0-rc0--列出在
批处理＃8中的
合并），添加了“
todo_list_filter_update_refs()”步骤来处理从“
rebase-todo”中删除“
update-ref”行。具体来说，如果没有相应的“
update-ref”行，则从“
update refs state”中删除潜在的引用更新。然而，由于当'
refs_to_oids'列表为空时，'
write_update_refs_state()'不会更新状态，所以删除所有'
update-ref'行将导致状态保持与初始化时一样（所有引用的“after”OID都为null）。然后，在应用引用更新时，所有引用都将被更新为null，并因此被删除。要解决这个问题，在'
refs_to_oids'为空时，删除'update-refs'状态文件。此外，添加一个测试来涵盖“所有update-ref行已删除”的情况。
git-rebase-todo中插入一个update-refs行时会出现错误。如果你有一个已经检出了old-pr的工作树，在另一个工作树中你有“new-work-on-old-pr”，并且你正在重新定位“new-work-on-old-pr”内部的工作树，那么在你的git-rebase-todo文件中放置一个update-refs refs/heads/old-pr行会导致old-pr工作树进入一种奇怪的状态，许多“incoming”更改留在工作目录中（相当奇怪的脏git状态）。 - Devin Rhode