【问题标题】:What is the best practice for using git on multiple projects with the same base?在具有相同基础的多个项目上使用 git 的最佳实践是什么?
【发布时间】:2016-02-15 06:29:47
【问题描述】:

我有一个项目在使用 git 作为其版本控制的客户端上运行。
过了一段时间,另一个客户想要具有一些不同功能的同一个项目。

然后,我想到了 2 个选项来管理 git 存储库中的新选项。

一个,fork 存储库,或者两个,为新的存储库创建另一个特定的分支。

因为我是 git 新手,所以我做了这两个测试来测试哪个更容易维护。后来,我选择了选项二,因为修复客户端中的错误要容易得多,然后将其挑选到另一个分支(如果错误出现在另一个客户端中使用的功能中)。而且在 IDE 中切换分支似乎比拥有多个项目更容易。

但是,我仍然不相信这是多个项目的最佳实践,因为现在我有更多的客户(因此,更多的分支机构)。

每个功能都使用分支确实令人困惑,我想利用 git 的拉取请求功能。我开始认为最好在他们的个人存储库中分离项目。
但是如果我这样做了,我还能在我的 IDE 中使用单个项目吗?

如何将错误修复“推送”到另一个存储库,而无需在另一个项目中重新编码(字面意思是再次编码、复制粘贴或使用差异)?

我做对了吗?
或者有更好的方法吗?

提前谢谢你。

【问题讨论】:

  • 它们是相同的选项。分支和克隆(fork)没有什么不同。您可以从一个合并到另一个,也可以从一个选择到另一个。
  • 另一种可能性是为共享代码创建一个库,然后在每个客户端的不同项目中重用该库。

标签: git


【解决方案1】:

版本控制不是这个问题的答案,这不是一个它从未打算解决的问题。您应该为所有客户提供一个代码库,并且您应该以可以在该代码库中打开和关闭的方式构建您的功能。

这是否意味着将功能提取到可加载模块中,或者构建它们以使您的代码中充斥着if/else 语句,这取决于您,但是任何一种解决方案都比分散分支的爆炸要好。每个客户端的分支解决方案几乎比将整个代码库复制并粘贴到每个客户端的新目录更好。如果您最终需要独立维护一百个客户端和一百个不同的分支,那么由于版本控制,您再好不过了。

【讨论】:

  • 我理解你对此的想法,是的,我同意你使用可加载模块(它仍在开发中)。但是,在新版本出来之前,应该管理正在运行的。我只是好奇,有没有更好的方法来做到这一点,只是通过版本控制。谢谢,顺便说一句。 PS:数百个客户?阿门:)
【解决方案2】:

为新存储库创建另一个特定的分支。
...
樱桃采摘到另一个分支

这是正确的工作方式。使用分支时,您可以选择在分支之间共享代码。添加功能或修复错误后,您可以非常轻松地将其添加到所需的任何分支。

所以分支是正确的做法。


但是,我仍然不相信这是多个项目的最佳实践,因为现在我有更多的客户(因此,更多的分支机构)。

  • 如果您希望对所有项目/产品使用相同的代码,您应该使用分支。
  • 如果您共享部分代码并且每个项目都有自己的一组功能,您应该使用submodules

请记住,即使您使用不同的存储库,您仍然可以在不同的项目之间使用cherry pick(在添加多个遥控器之后)。


每个功能都使用分支真的很混乱

这是使用 git 的推荐方式。
Git flow 这是 git 最常用的工作流程之一


如何将错误修复“推送”到另一个存储库,而无需在另一个项目中重新编码(字面意思是再次编码、复制粘贴或使用差异)?

Add several remotes 到您的存储库,您可以同时使用它们。

【讨论】:

  • 这可能不是我问题的解决方案(正如我在@meagar 的回答中的评论中所解释的那样),但这清楚地回答了我的问题,并给出了一个很好而简单的解释。我现在正在使用从主分支分叉的几个存储库,将它们添加为远程,并作为本地分支签出,并跟踪他们自己的远程。通过这样做,我可以更轻松地执行每个功能分支的工作流程,因为功能分支只会显示在相应的客户端存储库中。非常感谢:)
【解决方案3】:

看起来您需要为旧客户端分离分支,而不是故意提供不同的功能,但他们刚刚开始使用旧版本,您不想强迫他们使用新版本。然后你为他们拥有的分支就是所谓的维护分支。我可以想象两种最明显的方法来管理它们:

  • 将旧的维护分支批量合并到新的一次,如果有多个(v1 到 v2,然后 v2 到 v3,然后 v3 到主服务器)级联它们。这依赖于对维护分支的更改很小且经过充分测试的假设,因此它们不应该破坏新分支中的任何内容。例如,这就是 git 项目本身所做的(它只有一个维护分支)。
  • cherry-pick 对所需分支的所有更改。然后您可以使用问题跟踪器来跟踪哪些更改去了哪里,并且使用-x 标志来标记提交是经过精心挑选的总是一个好主意。通常你会先在master中开发和稳定它们,但在某些情况下使用维护分支更方便。

例如,您可以开始阅读here。一般来说,选择哪种模型并没有最终的答案。

【讨论】:

    猜你喜欢
    • 2018-12-11
    • 2019-10-23
    • 2017-12-07
    • 2021-01-29
    • 1970-01-01
    • 2022-08-19
    • 2018-03-20
    • 1970-01-01
    • 2014-05-31
    相关资源
    最近更新 更多