Question

我正在开发一个开发速度快，编译时间很长的大型开源项目。我的问题涉及如何在从master获得最新更改后最小化重新编译。

说我有

  /--MyDev1
 /
A (=master)
 \
  \--MyDev2

MyDev1和MyDev2只触及几个文件，所以如果我有A，MyDev1或MyDev2的编译版本，那么对其他任何一个进行结账并运行make非常快。

几周之后，大师在上游向前迈进了很多。几百文件已经改变：我结帐大师，拉最新的变化，运行make，并抓几十杯咖啡。

之后，我想做一个合并，这将导致世界看起来像

  /--MyDev1--------MyDev1'
 /                 /
A----....---------B
 \                 \
  \--MyDev2--------MyDev2'

然而，如果我只是这样做：

git checkout MyDev1 git merge master 使

然后make将重新编译所有内容，因为触摸了A和B之间的所有文件。喝那么多咖啡会让我生病。

我想要的是从 B合并，并且git只触摸A和MyDev1之间更改的文件（之后对MyDev2来说相同，可能会重新编译MyDev1和MyDev2之间的所有内容）。

Answer 1

我不知道使用纯git的解决方案。（可能甚至没有设计git。）

但是我有另一种解决方案，我经常使用它：我在每次构建之前将代码发送到其他地方（让我们称之为构建区域）。诀窍是，我让rsync根据校验和而不是时间戳（flags：-rlpgoDv --checksum --ignore-times）确定要同步哪些文件。然后我只在构建区域编译。

这不会加速一般情况，但至少对你来说是

git checkout MyDev1 && git merge master make

例子。在这种情况下，rsync只触及您的几个MyDev1文件。重新编译应该很快。

当MyDev2尚未合并时，事情变得缓慢，而MyDev1已经合并。在这种情况下，我建议每个分支一个构建区域（但这实际上需要每个分支的主编译）。根据您的实际情况，至少有一个提案应该有所帮助。

更新：我一直在想：实际更改时间戳的是git checkout MyDev1，而不是合并（假设没有冲突）。如果你可以在另一个方向合并，你可以做（假设你在master并且只是有很多咖啡也被编译）：

git checkout master
git checkout -b tmp_merging_branch master
git merge MyDev1
git branch -d MyDev1
git branch -m MyDev1

只要合并实际上没有更改文件，这就会保留时间戳。这没关系，因为这些文件无论如何都应该重建。好的方面是，你可以为MyDev2重复一遍：最初的git checkout master会保留master和MyDev1中文件相同的时间戳。但它只有在产生类似

之类的东西时才有效

  / --- MyDev1 --- MyDev1' ------ MyDev1''
 /                   \               \
A --- .... ---------- B --- ... ----- C
 \                   /               /
  \ --- MyDev2 --- MyDev2' ------ MyDev2''

Git：编译master，然后合并到dev而不重新编译所有内容

1 个答案: