Question

我正在尝试为与编程相关的教程设置版本控制。这证明是有问题的，因为有两种不同的历史：

本教程正在构建项目的历史，每个章节都可以使用，这是读者将看到的内容。如果我从未计划再次更改本教程中已编写的章节，我可以将每章作为标记存储在项目的历史中。

然后还有教程本身的历史（不仅是文本，而且是我对项目假装历史的研究）。如果我发现了一个错误，我需要在第1章中回过头来修复，在最后添加新的提交不起作用，因为我想改变项目在该阶段“出现”的方式，即在项目历史中插入提交然后向前移动章节的标签。

到目前为止，我已经考虑了一些可能性 - 使用git分支，每个章节都是一个分支，每当我进行更改时，它都会被重新定位到前一章的前面，一个我插入补丁的mercurial补丁队列，或者围绕我可以放在子存储库中的一组模块来构建教程。

我以为我会问是否有人有过这类事情的经验以及哪些解决方案有效但没有。

Answer 1

不是因为对早期章节的后期修复而重写了所有项目的历史，我宁愿将每个章节隔离在它自己的分支中，让每个HEAD代表每个章节的当前状态。 /> 然后组装所有教程更多是发布管理问题（通过从Git Repo中提取相关信息来部署教程）。

然后，您可以开发教程以实现与git immersion类似的功能。

（注意：如果这更像是您所追求的电子书，那么 git-scribe 将是一种更有趣的版本方式。）

OP rusky在评论中添加：

我正在尝试为章节编写示例代码版本，其中每章的代码都基于前一章的代码

这意味着您添加的任何错误修复都需要报告给代表其他章节的其他分支，在这种情况下请参阅：

In Git, how do you apply a commit of bug fix to the other newer branches?（避免采摘樱桃，这通常是一个坏主意）
using a topic branch
rebase --onto solution

Answer 2

基于CLI的版本控制的好处是你可以使用shell脚本来构建教程示例，例如：

#!/bin/bash
mkdir example_repo
cd example_repo
git init .
touch file1
git add file1
git commit -m "Added file 1"
git checkout -b branch2
echo "New line" > file1
git commit -am "Added new line to file 1"

你明白了。它允许你从头开始构建一个新的仓库到你喜欢的任何地方，并且中间的错误很容易修复，因为你每次都从一个空白的石板开始。您可以将shell脚本本身置于版本控制之下，或者只注释掉不同示例所需的部分。

Answer 3

git rebase --interactive可能是最直接的解决方案。这将允许您选择要编辑的特定提交，然后在其上重新应用所有后续提交。当然，取决于你的变化有多广泛，不应该比常规合并困难得多。查看有关拆分提交的git rebase手册页的部分内容。这样您就可以保留原始版本的历史原因，然后在历史记录中添加一个新的提交，您可以移动标记。

Answer 4

这是标签的用途。标记您的“快照”点，然后从那里开始。如果您需要返回并更改某些内容，请执行此操作并更新标记。如果您不希望人们看到中间阶段，只需创建第二个存储库并逐步检查您的提交中的一个标记。

教程的版本控制设置

4 个答案: