所以我试图确定这个工作流程是否理想，以及如何解决它的常见问题。目前我在git repo的主分支中有一个已完成的项目。我现在需要做的是将这个项目分成20个＆＃34;章节＆＃34;。每一章都代表了一些进展，它将我从第1章的一个完全空的项目带到了我现在在第20章的完整项目。理想情况下，回购分支将是：
主 第1章 ... 第20章（与项目完成时的Master类似）
这似乎是一种合理的结构方式吗？此外，在我进行更改时，我想知道在忘记某些事情时如何对所有分支进行共同提交。一个例子是，如果在第10章，我意识到我错过了第2章中应该存在的内容。我可以回过头来添加到第2章，但是我希望将它添加到第3章到第10章代表那种变化一直存在。这可能吗？
谢谢
答案 0 :(得分：2)
如果你想坚持每一章的分支，那么你的方法是可能的。这取决于您的实际需求和文档/项目结构。但是，如果你改变某事。在（分支）“chapter2”中，您必须将其合并到以下所有章节（子分支）中，即
git checkout chapter2;
# edit chapter2.txt, git add, git commit
git checkout chapter3; git merge chapter2;
git checkout chapter4; git merge chapter3;
...
git checkout chapter20; git merge chapter19;
更新：如果您希望章节完全相互独立，您还可以使用git的 章鱼 合并。这是多个分支合并到当前分支。从你所描述的我不推荐它，但只是告诉你：
然后你将有20个分支第1章......第20章不彼此依赖，即第2章不“chapter1 + edits”，它只是第2章。每个分支只处理（并看到）它自己的章节，没有别的。然后，当你想要发行一本新书时，你会做
git checkout master
git merge chapter1 chapter2 chapter3 ... chapter20
分支 master 然后是所有章节的合并。这会产生gitk中有趣的图片，因此名称章鱼; - ）
缺点是， branchX 不能依赖于其他分支的任何变化。如上所述，这取决于你是否对你有意义的情况。
答案 1 :(得分：0)
您描述的场景类似于＆＃34;标准＆＃34;使用所谓的功能分支时的软件开发。您需要将章节分支合并到master，然后每个人都需要从master合并到他们工作的章节分支。当某人需要更改旧章节时，您可能会遇到一些冲突，但看起来仍然可能。
答案 2 :(得分：0)
听起来tags比branches更合适。 https://softwareengineering.stackexchange.com/questions/165725/git-branching-and-tagging-best-practices可能会为您提供一些见解。我最初就专业项目问过这个问题，但我认为同样的想法同样适用于教程。