寻找处理庞大的PHP升级项目的git-workflow建议

Question

在过去的几个月里，我一直致力于一项11年历史的应用程序的大规模升级项目，该应用程序包含超过3,500个单独的文件。在某个时间点，文件被复制（它们由SVN管理，然后......），和转换工作开始，与继续工作同时支持客户。

在转换存储库（与取代SVN的“其他”git存储库完全无关）中，已完成大约314次提交，其中一些是巨大的。 （将<?转换为<?php，通过调用接口库替换mysql_调用，等等。）

现在，手头的任务是将“其他”repo 中的大约120个文件（最终将被放弃......）带入此文件中。到目前为止，我的方法是创建一个分支，将文件复制到新的分支中，并使用我为此目的开发的自动代码分析工具重新应用上述“基本”更改。

这是我不确定下一步该怎么做的地方。我想重新对这些文件进行更改，这反映在我的转换库的主分支上的300多次提交中，并尽可能自动地进行。我有一个文件，其中包含所有相关文件的列表。我的想法是cherry-pick主分支中的一些旧提交，并将这些提交应用于新分支中的文件（可能永远不会合并到主分区中）。根据我的思维方式，只需要重新应用那些触及任何文件的提交。 （但是，其中一些提交涉及成千上万的文件，包括但不限于此处的文件。）

此时，我站在一个决定的尖端，尚未做任何事情，并且不太确定如何最好地继续下去。

请记住：有两个单独的git回购，但它们与另一个完全无关。 （用于生产维护的那个当时甚至都不存在。）所以，我可以使用它...并且，确实使用它......只是为了获得已被触摸的文件列表，并获得他们最新的版本。转换项目完成后，转换回购将被丢弃，并且将冻结当前的生产回购。将创建一个全新的回购，以便继续前进。

忠实地寻求建议。 。 。

编辑： 我已经考虑过一种完全不同的方法，它会放弃我开始的课程，完全抛弃那个分支，并采取不同的策略来完成旧的repo，将选定的提交作为补丁抓取，并尝试将这些补丁应用于现有（尽管可能是非常多变的）模块。或者，如果需要，手工做同样的事情。只有大约100，承诺或承诺，承诺做...评论是诚恳地（并且，认真）要求任何一种策略。

Answer 1

我不确定这是否正是您所寻找的，但我的建议是使用Gitflow Workflow。

这种方式有效，你有一个名为master的主分支，其中存在主要代码。此代码始终是项目的最新稳定代码。

此分支旁边是develop分支。这个分支掌握着所有的发展进步。其他功能可以从develop分支出来，并在完成后再返回。修补程序也可以从develop分支。对于您的情况，您可以为每个迁移分支develop分支，即一次引入一个功能。

当develop分支稳定且需要发布时，您可以将develop分支与master合并。我已经将这种类型的工作流程用于我的一些大型项目，并且它对我来说非常好。

下面的图表显示了此类工作流的外观。圆圈是由图例进行颜色编码的提交。如果您有任何问题或需要我澄清，请随时告诉我。