存储库结构以修补上游下载的源

Question

我有一个Web应用程序。该应用程序有两个代码源：

• source1-是已发布的Java Web应用程序，必须通过受登录保护的Web ui手动下载
• source2-是对source1的修改和添加（xml和txt）

完成的应用程序是source1和source2的组合。 Source1被覆盖。

Source1是我不喜欢的代码。它作为我必须提取的zip文件发布。每隔几个月就会有一个修补程序（也包括zip）。半年后，有一个新的主要版本。主要版本不兼容，因此每半年我必须保存旧版本并重新开始。

Source2是我修改的代码，或者包括对source1的添加。 Source2是不断开发和更改的。

我想使用CI / CD来构建完成的应用程序并将其部署 在服务器上。我想要有关如何最好地构建我的一个或多个存储库的建议？

Answer 1

我想你想要类似的东西

• 为source1创建分支-在获取发布和补丁时在此处提交，以便分支的状态始终与您获取的最新版本匹配
• 从source1创建主分支，然后在此处提交source2提交（或提交功能分支，然后在此处合并它们）
• 从source2 / master分支设置CI和CD
  • （可能有必要在source1分支上设置一些CI，以确保在进行任何更改之前，它的测试可以在构建服务器上正常运行，但这并不常见，因此您可以手动将其启动。）< / li>

然后，source1提交始终是master / source2的父级，当您在source1分支上获得更新时，可以尝试将其git merge放入master / source2中。它可能会起作用：如果不行，则需要重新启动，然后重命名旧的master分支（或只是创建一个标签），然后从source1中选择一个新的master分支并进行选择，或重写所有对其进行提交，将其修复为新的source2版本。

可能有更聪明的解决方案，但这为您提供了source1的历史记录以及对您在它上面所做的source2工作的明智表示。我不能说git merge是否可以应付source1的重大变化；同事们对它的超级能力充满热情，但我本人取得的成功参差不齐，但是值得一试。在您必须从source1剪切新分支的那一刻起，这并不能为您提供所有source2版本的单个分支，但是您可以使用标签跟踪这些分支。

Answer 2

有很多方法可以构造这种结构，因此有一些建议：

假设您正在使用git：

• 仅对source1应用程序保留一个git分支。该分支中的每个提交都应仅是对source1文件的更新，并且任何提交都应仅包含sourc1文件。
• 为您的应用程序保留不同的分支，其中包含您所做的更改作为单独的提交。

.so

此结构可让您跟踪source1版本之间的更改，并且您可以随时从src1版本重新开始，然后在其顶部进行选择。

对于CI / CD，只需在推送到src2分支时重建/重新部署。