如何自动跟踪 git 分支上的特定文件
How to track only specific files on a git branch automatically
我有一个 master 分支和几个工作分支，每个分支都应该实现一个特定的功能，然后合并到 master 并删除。
我遇到的问题是，工作分支跟踪所有也在 master 上的文件，每当 master 更新时，我必须手动将 master 合并到所有其他工作分支以保持它们是最新的，即使 none 与工作分支功能相关的文件受到影响。
有没有一种策略可以让我只跟踪一个分支上的特定文件，而让其他文件自由地被其他分支更新？有没有比使用 .gitignore 更好的方法，它总是必须手动更新到 ignore/include 特定文件？我只想自动跟踪那些在该分支上提交了更改的文件。
无论出于何种原因，我看到越来越多关于这个提议的工作流程的问题。它总是会导致问题。我将讨论如何接近您的要求，但我也会讨论为什么它总是会导致问题。
首先让我们解决这个问题：您提到 .gitignore。它不会帮助。如果您手动维护特定于分支的版本并不重要，它仍然无济于事。忽略规则只做一件事：它们使未跟踪的文件保持未跟踪状态（默认情况下）。它们不影响合并、获取、推送等。回购中的内容不受 .gitignore.
的影响
所以...在git中，假定分支（尤其是将要合并的分支）是相同内容的不同版本。这或多或少意味着同一组文件——而不是文件的子集。 （"More or less"因为一个分支可能已经添加或删除了另一个分支中尚未存在的文件；但在这种情况下，假设后续合并将从另一个分支中添加或删除文件。）
我见过很多人尝试过一种方法，他们在其中创建分支，然后删除除一部分文件之外的所有文件。然后，当他们合并时，这些文件将从 master 中删除 - 当然 会发生这种情况，他们告诉 git 分支工作包括删除这些文件。
一次提交是一个项目快照；这是 git 中的预期内容单元。 （您可以争辩说对象是最基本的内容单元，在 git 的物理模型中我同意。但是在作为源代码控制的 git 的概念模型中，它是提交。 ) 所以一次提交可以代表项目的一致版本。您可以构建和测试任何提交。
("But I can build the subset of code that's on each branch independently!" 那么您可能在同一个存储库中有多个项目，应该重新访问它。稍后会详细介绍。)
所以在我进入 "how" 讨论之前有几个问题：
您陈述的问题是您必须将 master 合并到所有分支以使它们保持最新，即使分支不关心修改后的文件。所以我的第一个问题是：为什么？如果分支机构不关心该文件，那么它包含该文件的过时版本有什么区别？当您合并或变基时，git 将知道分支版本已过时，因此似乎文件很重要（在这种情况下您不能 "not have it" 在分支上）或者它不重要't（在这种情况下更新它不是合并的理由 master）。
我的第二个问题是，"so what?"，因为即使你决定合并master，分支也不会有冲突文件（因为它不关心文件）。这是一个问题的唯一方法是，如果你在每次更新到 master 时先发制人地合并到每个分支......那会让我回到 "why?"
但是没关系，很好。让我们假设您不相信并且有一个用例，您只需要拥有包含部分源代码的分支。
怎么做到的
正如我上面所说，如果您从创建整个项目树开始，然后在您删除分支上的文件，那么您将会有一段糟糕的时光。来自 master 的合并将发生冲突，并合并到 master，当它们不冲突时，将清除您在 master.
上仍然需要的文件
您可以通过将分支创建为孤儿分支或 master 上的 "empty" 提交的子分支来做得更好。然后在相应的分支上创建每个子项目树。
现在，这更好，因为没有删除可以解决，但它仅在分支不相交时有效 - 即不共享代码。如果他们要共享代码...您在哪里创建代码？
在创建分支之前，您可以在 master 上仅创建 共享代码 。只是现在你有这样一种情况，共享代码的更新需要合并到分支，这将导致代码从其他分支合并到 master 到 "spill over"，因为 git 逐渐纠正你回来到所有与合并相关的分支都是相同内容的版本的情况。
这指向另一个问题：即使没有共享代码，您也不能将master合并到该模型中的分支（因为，同样，代码会 "spill over"。所以你还必须强加一些纪律，代码只在分支上修改。如果你直接更新 master，或者从外部源接收到 master 的更新，您将没有将该更新应用到分支的好方法。
那么你应该怎么做呢？
在非常有限的情况下，即每个分支都有一组其他分支中不存在的文件，我已经概述了一个可能大部分工作的模型......但为什么要使用它？这没有意义。您拥有的是独立的代码库，因此只需将它们放在单独的存储库中即可。如果你想要一个协调分支将它们拉到一起（就像 master 那样），你可以创建一个 "master repo" 并使用子模块将每个项目联系起来。
在共享某些代码的情况下，您仍然应该将每个 "branch-specific" 代码集视为自己的项目（应该有自己的 repo），另外您应该将共享代码视为它的自己的项目。然后使用构建工具声明对来自特定项目的共享代码的依赖关系。
这不仅让您摆脱了与源代码控制工具的工作背道而驰的工作（当您尝试解决不是源代码控制的问题时），它还给了您很多力量（在能力上构建一个复杂的构建基础设施），你甚至可能没有意识到你错过了。
我有一个 master 分支和几个工作分支，每个分支都应该实现一个特定的功能，然后合并到 master 并删除。
我遇到的问题是，工作分支跟踪所有也在 master 上的文件，每当 master 更新时，我必须手动将 master 合并到所有其他工作分支以保持它们是最新的，即使 none 与工作分支功能相关的文件受到影响。
有没有一种策略可以让我只跟踪一个分支上的特定文件，而让其他文件自由地被其他分支更新？有没有比使用 .gitignore 更好的方法，它总是必须手动更新到 ignore/include 特定文件？我只想自动跟踪那些在该分支上提交了更改的文件。
无论出于何种原因，我看到越来越多关于这个提议的工作流程的问题。它总是会导致问题。我将讨论如何接近您的要求，但我也会讨论为什么它总是会导致问题。
首先让我们解决这个问题：您提到 .gitignore。它不会帮助。如果您手动维护特定于分支的版本并不重要，它仍然无济于事。忽略规则只做一件事：它们使未跟踪的文件保持未跟踪状态（默认情况下）。它们不影响合并、获取、推送等。回购中的内容不受 .gitignore.
所以...在git中，假定分支（尤其是将要合并的分支）是相同内容的不同版本。这或多或少意味着同一组文件——而不是文件的子集。 （"More or less"因为一个分支可能已经添加或删除了另一个分支中尚未存在的文件；但在这种情况下，假设后续合并将从另一个分支中添加或删除文件。）
我见过很多人尝试过一种方法，他们在其中创建分支，然后删除除一部分文件之外的所有文件。然后，当他们合并时，这些文件将从 master 中删除 - 当然 会发生这种情况，他们告诉 git 分支工作包括删除这些文件。
一次提交是一个项目快照；这是 git 中的预期内容单元。 （您可以争辩说对象是最基本的内容单元，在 git 的物理模型中我同意。但是在作为源代码控制的 git 的概念模型中，它是提交。 ) 所以一次提交可以代表项目的一致版本。您可以构建和测试任何提交。
("But I can build the subset of code that's on each branch independently!" 那么您可能在同一个存储库中有多个项目，应该重新访问它。稍后会详细介绍。)
所以在我进入 "how" 讨论之前有几个问题：
您陈述的问题是您必须将 master 合并到所有分支以使它们保持最新，即使分支不关心修改后的文件。所以我的第一个问题是：为什么？如果分支机构不关心该文件，那么它包含该文件的过时版本有什么区别？当您合并或变基时，git 将知道分支版本已过时，因此似乎文件很重要（在这种情况下您不能 "not have it" 在分支上）或者它不重要't（在这种情况下更新它不是合并的理由 master）。
我的第二个问题是，"so what?"，因为即使你决定合并master，分支也不会有冲突文件（因为它不关心文件）。这是一个问题的唯一方法是，如果你在每次更新到 master 时先发制人地合并到每个分支......那会让我回到 "why?"
但是没关系，很好。让我们假设您不相信并且有一个用例，您只需要拥有包含部分源代码的分支。
怎么做到的
正如我上面所说，如果您从创建整个项目树开始，然后在您删除分支上的文件，那么您将会有一段糟糕的时光。来自 master 的合并将发生冲突，并合并到 master，当它们不冲突时，将清除您在 master.
您可以通过将分支创建为孤儿分支或 master 上的 "empty" 提交的子分支来做得更好。然后在相应的分支上创建每个子项目树。
现在，这更好，因为没有删除可以解决，但它仅在分支不相交时有效 - 即不共享代码。如果他们要共享代码...您在哪里创建代码？
在创建分支之前，您可以在 master 上仅创建 共享代码 。只是现在你有这样一种情况，共享代码的更新需要合并到分支，这将导致代码从其他分支合并到 master 到 "spill over"，因为 git 逐渐纠正你回来到所有与合并相关的分支都是相同内容的版本的情况。
这指向另一个问题：即使没有共享代码，您也不能将master合并到该模型中的分支（因为，同样，代码会 "spill over"。所以你还必须强加一些纪律，代码只在分支上修改。如果你直接更新 master，或者从外部源接收到 master 的更新，您将没有将该更新应用到分支的好方法。
那么你应该怎么做呢？
在非常有限的情况下，即每个分支都有一组其他分支中不存在的文件，我已经概述了一个可能大部分工作的模型......但为什么要使用它？这没有意义。您拥有的是独立的代码库，因此只需将它们放在单独的存储库中即可。如果你想要一个协调分支将它们拉到一起（就像 master 那样），你可以创建一个 "master repo" 并使用子模块将每个项目联系起来。
在共享某些代码的情况下，您仍然应该将每个 "branch-specific" 代码集视为自己的项目（应该有自己的 repo），另外您应该将共享代码视为它的自己的项目。然后使用构建工具声明对来自特定项目的共享代码的依赖关系。
这不仅让您摆脱了与源代码控制工具的工作背道而驰的工作（当您尝试解决不是源代码控制的问题时），它还给了您很多力量（在能力上构建一个复杂的构建基础设施），你甚至可能没有意识到你错过了。