35

这是让我非常恼火的场景。

Jack 在 foobar 一家软件公司工作，Jack 是一名正在工作的程序员，他喜欢编码并且经常提交。Jack 的经理 Paul 告诉他，我们将开始使用新的代码审查工具，phabricator。Jack 答应了，Jack 创建了一个本地分支并开始工作。他非常频繁地向他的本地分支添加功能和提交。现在，在一天结束时，他发送了一个 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.
4

7 回答 7

19

asherkin 的回答解释了这种行为的基本原理，以及为什么这是默认设置。

如果您没有发现该论点令人信服，您可以使用该--merge标志arc land来执行--no-ff合并而不是--squash合并。这些合并不会破坏本地提交。

如果您history.immutable在 , 中设置为 true .arcconfig，则默认情况下arc land会--no-ff合并。

git如果您不喜欢 ; 的行为，也可以使用原始命令arc land。它只是为了方便而提供的。

在您的示例中，我们建议创建五个单独的评论- 有多个不同的想法正在实施，它们不相关并且看起来很容易分离。请参阅编写可审查的代码。将错误修复、样式更改和新功能合并为一个更改是囤积。

于 2013-12-24T16:08:32.013 回答
10

您应该直接使用本地 git 流，例如git mergeand git push。来自 phabricator arc 文档：

在接受更改后，您通常会推送它们并关闭修订。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，然后从 Web 手动关闭修订。

arc是故意压制你的提交。

于 2013-12-24T07:49:09.340 回答
4

history.immutable：将 arc 配置为使用永远不会在工作副本中重写历史记录的工作流。默认情况下，arc 将对 Git 中的某些工作流执行一些未发布历史记录的重写（修改提交消息、压缩合并）。下面详细介绍了这些区别。

所以只需在你的 .arcconfig

"history.immutable": true
于 2016-02-18T10:18:47.537 回答
3

有一些文档解释了为什么这是arc land.

一个想法是一次提交的策略与任何其他策略相比都没有真正的优势，直到您的存储库达到它变得至关重要的速度。尤其是：

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

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

对于 git，推荐的解决方案是将功能分支推送到上游，然后合并而不是 rebase 到 master - 如果您同意上述几点但仍希望您的检查点提交在上游。

如果这仅用于审查期间（因为您的问题是措辞 - 但听起来您没有进行代码审查或仅使用 Audit 进行推送后代码审查），请注意差异将已经显示您的所有本地提交与原始提交消息供审阅者查看。

arc land旨在仅用于推送到存储库的“最终”分支（即生产或表示更改待发布的某个分支）。如果你在做post-push commit review（即从开发到master的合并），你可以直接绕过arc land（通常在很多情况下你需要这样做）和git push你的更改。

于 2013-12-24T11:33:34.797 回答
1

在对奥术师的最新更新中进行了一些更改之后，这个问题的现代答案

为了防止壁球，您必须使用新strategy语法

arc land Dxyz --strategy merge

--mergeor的旧语法--squash已被替换为--strategy

（见一些背景信息：https ://secure.phabricator.com/T13547 ）

于 2020-07-18T15:49:26.577 回答
0

--merge 不起作用，因为它会创建合并提交。我已经修补了我的 --rebase 来做正确的事情，但我不确定 arc 人是否愿意拥有这个。

于 2018-06-15T09:53:53.647 回答
0

这就是我所做的。它不会阻止提交历史记录被压缩，但它允许您将后续功能重新定位到丢失的分支上。

$ arc land --revision <feature1>

$ git branch -u master <feature2>

$ arc cascade

arc cascade 将重新设置从 feature1 分支出来的所有功能分支

于 2020-06-12T23:05:44.237 回答