git - 如何自动跟踪git分支上的特定文件

无论出于何种原因，我都会看到有关此建议工作流程的越来越多的问题。它总会导致问题。我将讨论如何接近你所要求的内容，但我也会讨论为什么它总会导致问题。

首先让我们解决这个问题：你提到.gitignore。它没有帮助。如果你手工维护特定于分支的版本并不重要，它仍然不会。救命。忽略规则完全是一件事：它们将未跟踪的文件保留为未跟踪（默认情况下）。它们不会影响合并，提取，推送等。回购中的内容不受.gitignore的影响。

所以...在git中，假设分支（尤其是将要合并的分支）是相同内容的不同版本。这或多或少意味着同一组文件 - 而不是文件的子集。（＆＃34;或多或少＆＃34;因为一个分支可能添加或删除了另一个分支中尚未出现的文件;但在这种情况下，它假设后续合并将添加或删除该文件另一个分支。）

我已经看到很多人尝试一种分支方法，然后删除除文件子集之外的所有文件。然后，当它们合并时，这些文件将从master中删除 - 当然 就会发生这种情况，他们告诉git分支工作包括删除这些文件。

提交是项目快照;这是git中内容的预期单位。（你可以说对象是最基本的内容单元，并且在git的物理模型中我同意。但是在git的概念模型中作为源代码控制，它是提交。）所以提交可以表示项目的一致版本。您可以构建和测试任何提交。

（＆＃34;但我可以独立构建每个分支上的代码子集！＆＃34;然后你可能在同一个仓库中有多个项目，并且应该重新审视它。稍后会详细介绍。）

在我进入＆＃34;＆＃34;之前，有几个问题。讨论：

您声明的问题是，您必须将master合并到所有分支机构以使其保持最新状态，即使分支机构并不关心修改后的文件。所以我的第一个问题是：为什么？如果分支机构不关心文件，那么它包含文件的过时版本的区别是什么？当你合并或变基时，git会知道分支版本已经过时了，所以看起来任何一个文件都很重要（在这种情况下你可以＆＃39; t＆＃34;没有它＆＃34;在分支上）或者它没有（在这种情况下更新它并不是合并master的原因）。

我的第二个问题是，＆＃34;那么什么？＆＃34;，因为即使你做决定合并master，分支也不会有文件的冲突（因为它不关心文件）。这是一个问题的唯一方法是，如果您在每次更新时都先抢先合并到每个分支......这会让我回到＆＃34;为什么？＆＃34;

但是好的，很好。让我们假设您不相信并且有一个用例，您只需拥有部分源代码的分支。

怎么做？

如上所述，如果您首先创建整个项目树，然后在分支上删除文件，那么您将度过一段美好时光。来自master的合并将发生冲突，并合并到master，当他们发生冲突时，将会删除master上仍然需要的文件。

你可以通过创建分支作为孤儿，或作为＆＃34;空的＆＃34;的孩子来做得更好。在master上提交。然后在相应的分支上创建每个子项目树。

现在，这是更好，因为没有可以解决的删除，但它只有在分支不相交时才有效 - 即不共享代码。如果他们要共享代码......你在哪里创建它？

在创建分支之前，您可以在master上创建仅共享代码。只有现在你的情况是共享代码的更新需要合并到分支，这将导致代码从其他分支合并到master到＆＃34;溢出＆＃34;随着git逐渐将您恢复到所有与合并相关的分支是相同内容的版本的情况。

这又指出了另一个问题：即使没有共享代码，也无法将master合并到此模型中的分支中（因为，代码将会＆＃34;溢出＆＃34;。所以你还必须施加一些纪律，代码只在分支上修改。如果你直接更新master，或从外部来源收到master的更新，你没有把这种更新应用到分支机构的好方法。

那你该怎么做呢？

在非常有限的情况下，每个分支都有一组没有其他分支的文件，我已经概述了一个可能大部分都可以使用的模型......但为什么要使用它呢？它没有意义。你拥有的是独立的代码库，所以只需将它们放在单独的回购中。如果您希望一个协调分支将它们组合在一起（如master那样），您可以创建一个＆＃34;主仓库＆＃34;并使用子模块将每个项目绑定在。

在共享某些代码的情况下，您仍然应该处理每个＆＃34;分支特定的＆＃34;代码集作为自己的项目（应该有自己的repo），另外你应该将共享代码视为自己的项目。然后使用构建工具声明对特定项目的共享代码的依赖性。

这不仅让你摆脱了与源代码控制工具相悖的工作（当你试图解决什么不是源代码控制问题时），它会给你一堆力量（能力）建立一个复杂的构建基础架构，你可能甚至都没有意识到你会失踪。

如何自动跟踪git分支上的特定文件

1 个答案: