gpt4 book ai didi

git - 管理将多个版本的 repo 统一到一个通用的基本分支中 - 最佳实践工作流程?

转载 作者:行者123 更新时间:2023-12-02 02:40:07 24 4
gpt4 key购买 nike

我的任务是“取得我们的一个插件的所有权”,在几年的时间里,它针对不同的客户分成了不同的版本,因此我们有大约 5 个不同的“产品”版本,一些添加了相同的功能,一些功能缺失。

基本上我需要做的是创建一个通用的基础分支, merge 其中的所有各种更改并确保没有遗漏任何内容。然后我们要开始为所有客户端使用通用分支。

解决这个问题的最佳方法是什么?

  • 我可以从一个“最新”分支(即对其进行最多更改的分支)开始,然后从该分支创建一个新分支,然后(例如 base-branch)尝试 rebase 在其他“产品”分支中。
  • 或者我可以从 master 分支(现在落后了一些)开始,然后尝试将所有内容 rebase 到那个分支。
  • 或者有更好的方法吗?

我没有对一个大项目和许多不同版本做过这样的事情,所以我不确定要确保的最佳实践,首先我不会错过任何提交并最终缺少功能,并且其次只是一般的工作流程,这将使这尽可能轻松。

谢谢。

最佳答案

git 有点像时间机器。

您现在陷入了困境,因为您有五个 个独特的软件版本需要协调成一个统一的产品。事后看来,如果在添加功能时将分支 merge 并重构为一个通用产品,这个问题甚至不会存在。你可能有这样的东西作为你的树;

           C--D
/
R--*--*--*--*--*--E
\ \
A B

Even if you don't have a tree at the moment as long as you know the history you can infer one and use the same process by copying versions over your working copy instead of merging.

如果我们能回到我们第一次 fork (AB)并将它们 merge 到一个 base 中,那将是多么令人惊奇-分支。您可以使用 git checkout 命令执行此操作;

$ git checkout -b base-branch R

给予;

R--*--*
\ \
A B

这感觉更易于管理; git merge A 是一个快进,然后 git merge B 将需要一些重构,但我们会有;

     *--B   
/ \
R--*---a--b <- (base-branch)
\ /
A

这正是您希望发生的事情。第一个功能集 A 被 merge 到 base-branch 中,然后是功能集 B 将进行所有必要的重构。

想象一下你又回到了过去,但在这个时间线中我们有 base-branch 并且我们刚刚发布了 CDE。我们想要 base-branch 中的那些功能集。您可以继续 git merge C,重构,git merge D,重构,因为它可能不再是快进了。最后 git merge E,重构,大功告成。

         *--*--E
/ \
*--C--D \
/ \ \ \
*--B \ \ \
/ \ \ \ \
R--*---a--b---c--d---e <- (base-branch)
\ /
A

您最终得到的是与您想要的完全一样的项目历史记录。每个功能集都按时间顺序开发,就好像它一直都是正确完成的一样。

这并不容易,与 gitting 相比,您需要进行更多的重构。把你自己放在当时作者的心态中,并像他们那样融合,并加入一点你的后见之明。

关于git - 管理将多个版本的 repo 统一到一个通用的基本分支中 - 最佳实践工作流程?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60100144/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com