这些辅助文件是否应在 Git 版本控制下

Should these auxiliary files be under Git version control?

本文关键字：Git 版本版本控制控制下是否文件更新时间：2023-10-16

我决定在我的C++项目中开始使用 Git 版本控制系统。我是版本控制的新手。对于主干来说，事情很简单，我只是提交我拥有的所有项目版本。我将每个版本保留为一个单独的文件夹，因为我知道我很快就会使用 Git。但是我的分支遇到了问题。

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

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

然后我做了另一个特殊的文件：第三个版本头文件的副本，其中每一行都可以标记或不标记。标记表示我使用该特定方法，或者我确定它将很快使用，否则不会标记该行。

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

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

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

最好的办法是什么？感谢您阅读我的长篇小说:)

编辑：这是我个人计算机上的本地存储库

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

如果您的文档是自动生成或编译成另一种格式的，请仅提交源数据、生成文件和生成器配置，就像处理源代码一样。

你描述的是分支的正常使用：你有你的主分支（"官方"，如果在哪里）和一个分支来开发新功能（如果我理解正确的话，它实际上不必存在于单独的目录中）。定期将功能分支与主分支同步，方法是将其重新定位于主节点或合并其更改。反过来，您完全可以拥有从属分支，您可以在其中尝试开发功能的方法，就像处理主分支一样。但在这种情况下，每当你变基时，你必须小心。

您应该在存储库中保留任何不容易重新创建的数据，无论是源代码、文档还是设计草图。可以重新创建的东西（目标代码，自动格式化的文档等）应该被排除在外（任何更改都会产生要签入的差异）。您的存储库（尤其是未发布的分支）是您自己的工作区，它可以是您想要的所有混乱。

看看 git 主页上提到的书。

嗯，这显然是文档而不是源代码，所以你应该把它和源代码分开。由于您的文档似乎依赖于分支，因此您仍应将其签入存储库，但在单独的doc目录中。

关于合并：合并如何工作最终取决于您。Git 只有一个默认的合并策略，这是大多数人大多数时候想要的。但是，如果您说合并到主分支中应该只带来代码而不是文档，那很好。只需以这种方式合并：

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