Git 如何防止phabricator吃掉我的提交记录

这是一个让我非常恼火的场景

Jack在foobar软件公司工作，Jack是一名工程师，他喜欢编码并经常提交。杰克的经理保罗告诉他，我们将开始使用新的代码审查工具phabricator。杰克服从了，杰克创建了一个本地分支机构并开始工作。他经常添加特性并向其本地分支机构提交。现在，在一天结束时，他发送了一个phabricator请求

arc diff development

jacks团队成员John审查他的代码并接受他的更改。 现在，Jack打开终端并移动到他的存储库目录。 Jack键入以下命令以关闭修订并将其代码与开发分支合并

arc land --onto development

他看到了以下信息

Landing current branch 'feature-awesome-features'.
Switched to branch development. Updating branch...
The following commit(s) will be landed:

b2ff76e  Added the foo to bar
33f33ba  Added a really important check which can destroy the project or save it
31a4c9a Added that new awesome feature
8cae3bf rewrote that awful code john wrote
bc54afb  bug fixes

Switched to branch feature-awesome-features. Identifying and merging...
Landing revision 'D1067: Added the awesome feature'...
Rebasing feature-awesome-features onto development
Already up-to-date.
Pushing change...

现在，jack打开Github查看他的代码，他漂亮的提交。但他看到的是纯粹的恐惧，他所有的承诺都被一个简单的承诺所取代，基本上是这样说的

Summary: Added the awesome feature

Test Plan:  do foo bar testing

Reviewers: John

Reviewed By: John

CC: Paul

Differential Revision: http://phabricator.foobar.com/D1067

现在杰克很伤心，因为他想看到他所有的犯罪行为，杰克认为这一犯罪行为让他看起来不像他。他想解决这个问题，所以他去问了一个关于stackoverflow的问题

That how may he prevent phabricator from eating his commit history.

---

您应该直接使用本机git流，例如

git merge

和

git push

。来自phabricator：

接受更改后，通常会推送更改并关闭 修订。arc有多个工作流可帮助实现这一点，具体如下：

* squashing or merging changes from a feature branch into a master branch
* formatting a good commit message with all the information from Differential
* and automatically closing the revision.

您不需要使用任何这些工作流：只需运行git即可 push、hg push或svn commit，然后从手动关闭修订 网络

arc

故意压缩您的提交。

这就是为什么这是

arc-land

的默认设置

一个想法就是一次提交的策略与任何其他策略相比都没有真正的优势，除非您的存储库达到关键的速度。特别是：

• 基本上，针对主/远程存储库的所有操作都与想法有关，而不是提交。当一个想法是多个提交时，您所做的一切都会更加复杂，因为您需要弄清楚哪个提交代表一个想法（“foo小部件坏了，我需要恢复什么？”）或者提交最终代表什么想法（“提交af3291029毫无意义，此更改试图实现什么目标？”）
• 发布工程大大简化了。当每个想法对应一个提交时，发布工程师可以轻松地选择或放弃想法。当一个想法是多次提交时，很容易意外地选择或放弃其中的一半，并最终陷入一种几乎肯定是错误的状态
• 自动化测试大大简化了。如果每个想法都是一个提交，那么您可以针对每个提交运行自动测试，测试失败表明存在严重问题。如果每个idea都是多个提交，那么这些提交中的大多数表示代码库的已知断开状态（例如，在下一个检查点中修复了语法错误的检查点，或者使用半实现的idea）
• 理解变化大大简化了。您可以平分一段时间，然后简单地确定整个想法，而无需在日志中前后搜索以确定想法的范围。你可以对你需要恢复什么来消除整个想法充满信心
• 将检查点提交（其中一些被保证是存储库已知的已损坏版本）持久化到远程中没有明确的价值。考虑一个理论VCS，它自动为每个击键创建一个检查点提交。这种风投显然无法使用。但是，许多检查点提交并没有太大的不同，在概念上代表了编写更大想法的击键序列中的一些相对任意的点。摆脱它们或创建一个抽象层（合并提交），当您试图从思想的角度理解存储库时（几乎总是这样），它允许您忽略它们

所有这些都只是规模上的问题。Facebook每天推送数十个创意，每周推送数千个创意，如果不选择一个创意即一次提交的存储库策略，就无法做到这一点（至少，不能没有更多的人或更多的错误）

对于git，建议的解决方案是将功能分支推送到上游，然后合并，而不是重新基址到主节点上——如果您同意上面的观点，但仍然希望在上游提交检查点

如果这只是在审查期间进行的（正如您的问题的措辞一样，但听起来您没有进行代码审查，或者只进行了带审核的推送后代码审查），请注意，Differential已经显示了所有本地提交以及原始提交消息，供审查者查看

---

arc-land

仅用于推送到存储库的“最终”分支（即生产分支或代表待发布更改的分支）。如果您正在进行推后提交审查（即从开发到主控的合并），您可以绕过

arc land

（通常认为在许多情况下需要这样做），直接

git推送您的更改。
asherkin的回答解释了这种行为的原理，以及为什么这是默认行为

如果您不认为该参数具有说服力，则可以使用
--merge
标志执行
--no ff
合并，而不是
--squash
合并。这些合并不会破坏本地提交

如果在
.arcconfig
中将
history.immutable
设置为true，默认情况下，
arc land
将
--无ff
合并

如果您不喜欢
arcland
的行为，也可以使用raw
git
命令；它只是为了方便而提供的

在您的示例中，我们建议创建五个独立的评论——有多种不同的想法
"history.immutable": true