0

我继承了一个大型代码库,其中开发分支在 git 下已经有一段时间了,但生产并没有受到任何版本控制。

..我知道。

将代码提升到生产环境的方法是从 dev 和 prod 手动来回复制所有更改的文件,直到它们同步,并在周末尽快处理随后的灾难。

从那以后,我将生产置于一个全新的 git 实例下git init/add/commit,现在可以跟踪所有这些在生产中实时生成的修补程序(当我回到每个人后面并每天进行检查点提交时)。我已将生产上的“起源”设置为与开发相同,因此生产现在是同一存储库的单独分支,没有共同的祖先。

我想在这里进行真正的开发过程,这意味着我想将分支合并在一起。

在这一点上值得一提的是,开发和生产分支都在进行,因为首席开发人员喜欢在生产中进行热修复。我相信我可以改变他的这种习惯,如果我可以提供将修复应用到另一个分支并将其合并生产中的替代方案。

但要做到这一点,我需要一个与生产共享共同祖先的分支。

..我该怎么办?我可以将生产合并到开发中,这会产生大量冲突,我可以尝试手动解决(即合并工具),但这听起来像是大量的工作。

有没有更好的办法?

我仍在学习成为一名 git 大师,我想完成这件事,但是.. 最好的方法是什么?

4

1 回答 1

1

第一:对不起乔恩,这听起来像一团糟。:-(

这是一种方法:

git master branch:这应该是当前的生产。(简单的)

来自 master的修补程序分支:这些应该是您描述的在生产中完成的修补程序(很容易,假设进行修复的人实际上是这样做的)

开发分支:从 master 的一个分支开始。然后将文件/更改复制到这个分支,就像团队已经在做的那样,将文件从开发转移到生产。每当修补程序应用于主控时,就合并到主控中。这将导致一个分支可以无冲突地合并到 master 中,但有一个很大的差异,可以由整个团队审查。(很难,但值得)

一旦你完成了这个,你就可以开始遵循更标准的方法,比如git-flow

于 2015-06-16T22:57:02.843 回答