关于为迭代教程将Git回购构造为分支的建议

Question

我是一名教师，我即将发表一篇教程，介绍如何在几个迭代步骤中构建PHP应用程序。在每次迭代中，我都希望提供对相关源代码的访问，以及与上一次迭代的代码的不同。

当然，我计划为项目源代码使用一个Git存储库，每次迭代都有一个分支。但是，我想知道将来对我的不同分支的修复和更新。如果我在一个分支上做了一个修正(比如说，迭代-03)，我希望它“传播”到所有即将出现的分支(迭代-04，迭代-05，等等)。我的分支也必须保持一致。

所以我的问题是：

• 为了达到我的目标，将Git回购组织成分支的最好方法是什么？
• 如何将修补程序传播到以下分支？

提前谢谢你的回答。

你好，巴蒂斯特

Answer 1

Git并不是一个非常合适的工具。特别是，创建git是为了跟踪数据的确切变化历史。虽然分支系统提供了一些支持，以保持不同的叉的最新，这是不太方便。让我们假设您有以下历史图表：

a1--a2  branch a
      \
       b1  branch b
         \
          c1--c2  branch c

现在要修复分支a上的错误。我们这样做并以a3的形式提交更改：

a1--a2--a3  branch a
      \
       b1  branch b
         \
          c1--c2  branch c

为了获得对其他分支的更改，我们可以将每个分支重新定位到它的前身上，这将重播每个分支的提交：

a1--a2--a3  branch a
          \
           b1'  branch b
              \
               c1'--c2'  branch c

或者，我们可以将每个分支合并为其后续分支(不可能进行快速转发，因此我们将获得显式合并提交b2和c3)：

a1--a2------a3  branch a
      \       \
       b1------b2  branch b
         \       \
          c1--c2--c3  branch c

虽然重基使历史看起来“更好”，合并提交告诉我们项目的真实历史。在这两种情况下，任何更改都将修改所有依赖的分支，历史记录将清楚地显示修复提交a3。Git不自动保持相关分支的最新信息，但是您可以编写一个脚本来帮助您。请注意，如果更改不能自动解决，任何合并或重基都可能被中断，在这种情况下，您必须手动解决。

使用此方案，对于基分支中的更改，分支之间的差异将保持相当恒定，因为更改将传播到所有依赖的分支。

替代策略:标记✘

如果您希望能够修复以前的“版本”，那么简单地记录历史和标记有趣的状态是不可行的选择。我们可以从这样的历史开始：

a1--a2--b1--c1--c2  branch master
    ↑   ↑       ↑
tag a  tag b    tag c

我们可以通过分支创建一个fix分支，在其中提交修复提交a3：

       a3  branch fix
      /
a1--a2--b1--c1--c2  branch master
    ↑   ↑       ↑
tag a  tag b    tag c

然后我们可以将master分支重新定位到fix上：

       a3--b1'--c1'--c2' branch master
      /
a1--a2--b1--c1--c2
    ↑   ↑       ↑
tag a  tag b    tag c

不幸的是，这些标记引用了它们最初的提交，并且没有被更新。

替代策略:带有git remote✔

的多个文件夹

然后，可以简单地将每个迭代存储在一个单独的目录中。这实际上是最方便用户的选项，因为它不需要git知识来访问特定的状态，但这使得正确跟踪更改变得更加困难。使用git的一种可能性是在每个迭代文件夹中有一个单独的git存储库。然后，每个迭代都将前一个迭代的存储库标记为上游存储库。每次更改之后，您将对每个依赖的回购进行git pull更改。

虽然这是最难设置的，但对于所有参与者来说，这可能是最好和最直观的解决方案。

下面是使用此策略设置示例项目的一些代码：

#!/bin/sh

# create the three iterations a, b, c:
mkdir a b c

# fill each repository and set up upstream repos
cd a
git init
git commit --allow-empty -m 'a1'
git commit --allow-empty -m 'a2'

cd ../b
git clone --branch master ../a .
git commit --allow-empty -m 'b1'

cd ../c
git clone --branch master ../b .
git commit --allow-empty -m 'c1'
git commit --allow-empty -m 'c2'

cd ..

现在我们创建一个提交a3：

cd a
git commit --allow-empty -m 'a3'
cd ..

要更新其他repos，只需发出一个git pull：

cd b
git pull  # enter message for merge commit
cd ../c
git pull  # enter message for merge commit
cd ..

运行这些命令之后，在c中生成的日志如下所示

*   d8943fb c3
|\
| *   c670d4f b2
| |\
| | * f2ae31e a3
* | | e362453 c2
* | | 6e2a2d7 c1
|/ /
* | c78583c b1
|/
* 3c377e4 a2
* 098f321 a1

这种策略最终在功能上相当于通过合并传播更改，但使用起来可能要容易一些--特别是对于那些以zip归档方式下载代码的新手来说。另一方面，这使得作为git分发完整教程变得更加困难，因为所有内容都是跨多个链接repos分发的。如果这一点很重要，那么顶部描述的等效普通合并更有可能更好。