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

无论出于何种原因,我看到越来越多的关于这一拟议工作流程的问题。它总是导致问题。我将讨论如何接近您的要求,但我也将讨论为什么它总是导致问题。

首先让我们把这件事弄清楚:你提到 .gitignore .这没用。不管您是否手动维护特定于分支的版本,它仍然没有帮助。忽略规则do 只有一件事 :它们保持未跟踪的文件未跟踪(默认情况下)。它们不影响合并、提取、推送等。回购中的内容不受 .gitignore 。

所以在git中,假设分支(尤其是将要合并的分支)是相同内容的不同版本。这意味着,或多或少是同一组文件,而不是文件的子集。(“或多或少”,因为一个分支可能添加或删除了另一个分支中尚不存在的文件;但在这种情况下,假设后续合并将添加或删除另一个分支中的文件。)

我见过很多人尝试一种方法,在那里他们进行分支,然后删除除一个子集以外的所有文件。然后,当它们合并时,这些文件将从 master -其中 当然 他们告诉git,分支工作包括删除这些文件。

提交是项目快照;这是git中预期的内容单元。(你可以说对象是最基本的内容单元,在git的物理模型中我也同意。但在git作为源代码管理的概念模型中,它是提交。)因此,提交可以表示项目的一致版本。您可以构建和测试任何提交。

(“但我可以独立构建每个分支上的代码子集!”那么,您可能在同一回购协议中有多个项目,应该重新考虑。稍后将详细介绍。)

在我开始“如何”讨论之前,有几个问题:

您声明的问题是您必须合并 主人 发送到所有分支,使其保持最新,即使分支不关心修改后的文件。所以我的第一个问题是:为什么?如果分支不关心该文件,那么它包含的文件的过期版本有什么区别?当您合并或重新设置基址时,git会知道分支版本已过期,因此似乎要么文件很重要(在这种情况下,您不能在分支上“没有它”),要么文件不重要(在这种情况下,更新它不是合并的理由 主人 )。

我的第二个问题是,“那又怎样?”,因为即使你 做 决定合并 主人 ,分支不会与文件发生冲突(因为它不关心文件)。这是一个问题的唯一方法是,如果您在每次更新时都抢先合并到每个分支,以掌握。。。这会让我回到“为什么?”

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

如何做到这一点?

正如我上面所说的,如果您从创建整个项目树开始,然后在分支上删除文件,那么您将度过一段糟糕的时光。合并自 主人 将发生冲突,并合并到 主人 ,当它们不冲突时,将删除您仍然需要的文件 主人 。

通过将分支创建为孤立分支或“空”提交的子分支,您可以做得更好 主人 。然后在相应的分支上创建每个子项目树。

现在,这是 较好的 因为没有要解决的删除问题,但它只在分支不相交的情况下工作,即不共享代码。如果他们要共享代码。。。您在哪里创建它?

您可以创建 只有共享代码 在…上 主人 ,然后创建分支。只有现在,您才会遇到这样的情况:对共享代码的更新将需要合并到分支,这将导致代码合并到 主人 从其他分支到“溢出”,git逐渐将您纠正回所有与合并相关的分支都是相同内容的版本的情况。

这就指向了另一个问题:即使没有共享代码,您也可以 不能 合并 主人 对于这个模型中的分支(因为,同样,代码会“溢出”。因此,您还必须施加一些规则,该代码只会在分支上修改。如果您更新 主人 直接,或接收更新 主人 从外部源,您将没有一个好的方法将该更新应用于分支。

那么你应该怎么做呢?

在非常有限的情况下,每个分支都有一组不存在于其他分支中的文件,我已经概述了一个模型,该模型可能基本上可以工作。。。但为什么要使用它呢?这没有道理。您拥有的是独立的代码库,所以只需将它们放在单独的回购协议中即可。如果您想让一个协调分支将它们联系在一起(例如 主人 您可以创建一个“主回购”,并使用子模型将每个项目联系起来。

在共享某些代码的情况下,仍应将每个“特定于分支”的代码集视为其自己的项目(应获得自己的回购),此外,还应将共享代码视为其自己的项目。然后使用构建工具声明对特定项目中共享代码的依赖关系。

这不仅使您摆脱了与源代码管理工具的粒度对抗的工作(当您试图解决非源代码管理问题时),它还为您提供了一系列的能力(在构建复杂的构建基础设施的能力方面),您甚至可能没有意识到您丢失了这些能力。