这些辅助文件应该在Git版本控制下吗？ 我决定开始使用Git版本控制系统来进行C++项目。我是版本控制新手。对于主干来说，事情很简单，我只需提交我所有的项目版本。我将每个版本作为一个单独的文件夹保存，因为我知道我很快就会使用Git。但是我的分支遇到了一个问题

在开发的某个阶段，我决定在一个分支中开发一个类。没有版本控制，我不得不使用make“manual”分支。我将该类的最新头文件和源文件复制到一个单独的文件夹中，并开始在那里工作。我在那里同时制作了几个版本。一个版本是根据计划的第一个类原型（为此我做了“分支”）。然后我添加了另一个文件，在其中我复制了第一个文件，但删除了似乎不必要的内容。这样我就有了两个版本，一个包含了我所有的想法和特性，另一个只包含了我在代码中真正使用的内容，而没有目前没有使用的内容

但后来我补充了更多。随着开发的进行，我决定将该类作为模板可能是一个好主意。所以我添加了第三个版本，与第二个版本类似，但是现在使用多态性实现的一些功能是使用模板实现的。我还不知道哪个版本是最好的，因为现在说还为时过早，所以我想把这三个版本都放在一起

然后我制作了另一个特殊的文件：第三个版本头文件的副本，其中每一行都可以被标记或不被标记。标记意味着我使用了那个特定的方法，或者我确信它很快就会被使用，否则这行就不会被标记

后来，过了一段时间，我开了一家新的分店。对于这个分支，我需要在第一个分支中开发的这个类的新版本。所以我只是将其中一个版本复制到新分支的文件夹中，并开始在那里工作。现在我又有了一些辅助文件：我有两个文件，一个是删除我使用的类方法，另一个是编写我需要的新方法

现在我想开始使用Git，我想知道：对于所有项目的文本文件、计划、图表等，很明显——我把它们放在Git回购之外。每当需要协作编辑时，我都可以建立一个wiki或类似的东西。但是对于同一头文件的所有副本，以及那些辅助的“标记”文件，我该如何处理它们呢？我的意思是，我可以把它们都放在一个分支中，但是当我把一个分支合并到主干中时会发生什么呢？我不想要所有这些副本、版本和列表，只是我制作的最后一个类文件

一方面，这些是编码时使用的C++源文件。另一方面，它们不是软件包的纯源代码的一部分，它们只是在我工作时帮助我，但永远不会被编译，因为最终只有我选择合并的类的最终版本，所有其他aux文件、列表等保留下来仅供参考

最好的做法是什么？ 感谢您阅读我的长篇故事：）

---

编辑：这是我个人电脑上的本地回购协议，这显然是文档，而不是源代码，所以你应该将其与源代码分开。由于您的文档似乎依赖于分支机构，因此您仍应将其签入回购协议，但应将其签入单独的

doc

目录

关于合并：合并的工作方式最终取决于您。Git只是有一个默认的合并策略，这是大多数人最想要的。但是如果你说合并到主分支应该只带来代码而不是docu，那就好了。这样合并即可：

git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit

---

始终将文档保存在与源代码相同的存储库中。如果您不这样做，您的文档将腐烂。这是因为文档是针对您的软件的某个版本编写的，因此它必须以与软件开发相同的方式进行开发

---

如果您的文档是自动生成或编译成其他格式的，请仅提交源数据、生成文件和生成器的配置，就像您对源代码所做的那样。

您描述的是分支的正常使用：您有主分支（“官方”，如果在哪里）和分支来开发新功能（如果我没有弄错的话，它实际上不必存在于单独的目录中）。定期将功能分支与主功能分支同步，方法是在主功能分支上重定其位置，或在中合并其更改。反过来，您也可以有下属分支，在这些分支中，您可以尝试开发功能的方法，就像在主功能分支上处理一样。但在这种情况下，您必须当你重新设定基准时要小心

您应该在存储库中保留任何不容易重新创建的数据，无论是源代码、文档，甚至是设计草图。可以重新创建的内容（目标代码、自动格式化的文档等）都应该保留在存储库之外（任何更改都会导致签入的差异）。您的存储库（特别是未发布的分支）是您自己的工作区，它可以是您喜欢的所有混乱

---

请看。

上提到的那本书。为什么不在回购协议中包含计划等？如果有，就更容易找到正确的版本。至于你的另一个问题，我不太确定你想要什么，但你可以通过使用不同的合并策略来改变合并的工作方式。我会选中“我们的”和“他们的”如果他们有什么帮助的话。你也可以在单独的回购协议中包含这些内容，并将其作为子项目或其他内容。实际上，我的意思是合并但排除一些文件。我找到了一个很好的解决方案：每次合并之前，最后一次“清理”提交时会显示一条消息，说明我已准备好合并分支，然后在所有辅助文件都不存在后合并分支。如果您只是想忽略这些文件，请尝试根文件夹中的.gitignore文件。谢谢，我已经找到了