npm-合并补丁到更高的主要版本

问题描述

当前，我们有一个用于共享内部软件包的git存储库，每个软件包都是其自己的文件夹。 多个独立项目通过共享代码将依赖关系添加到这些程序包中。

由于发布周期不同，所以不同的项目可能依赖于不同的主要软件包版本，并且可能需要发布其当前版本的补丁程序。 例如，团队A在1.0.0版上，而团队B在3.0.0版上。 要修复1.0.0中的错误，您只需从包含1.0.0的提交中创建一个新分支（例如，没有足够的时间更新到最新版本，其中包括一些重大更改），进行更改并发布一个新的1.0.1。

您是否还要将更改合并到master并发布3.0.1？ 如果您不这样做，那么B团队将无法获得解决方案。尽管3. *是两个主要版本，但这并不意味着它的代码库是完全不同的，除了两个导致主要版本两次被颠簸的小改动之外，它的相似度可以达到99％。

此外，如果A团队决定在某个时候更新到最新版本，如果您没有将修补程序合并到主版本中，则该修补程序将不存在，这可能会导致一些罕见的错误再次出现。

>

如果合并是处理此问题的正确方法，是否有一些npm功能可以使我不忘记将补丁合并到母版中？甚至是高于我要修复的所有主要版本（甚至是所有次要版本），因为如果团队A决定先将其更新为2. *会容易些吗？

如果没有类似的功能，我会缺少什么吗？发行旧版本补丁是否容易出错并且会导致丢失某些错误修正？如果是这样，您是否应该阻止发布旧版本？

解决方法

更多细节即将到来，但最重要的是：

在某个时候，开发人员将决定是否包含此修复程序，或者是否需要更多修复程序。
显然，此决定需要进行审查和测试，并可能编写一些额外的代码。

---

让我们列出一些将代码从分支A移植到分支B的方法：

1. 实际上使用git merge合并分支：

git checkout v2.0
git merge v1.0

git checkout v3.0
git merge v2.0

1. 使用rebase或cherry-pick：

# if the fix consists in one or two commits,it is easy to cherry-pick these commits :
git checkout v2.0
git cherry-pick <fix-commit1> <fix-commit2>

# 'rebase' is a convenient way to apply a sequence of cherry-picks :
git checkout v1.0
git checkout -b v2-port
git rebase --onto v2.0 <from>..v2-port
git checkout v2.0 && git merge --ff-only v2-port

1. 有一个开发人员在分支v2.0上手动编写修复程序并提交

---

以下是一些要了解的内容：

1. 合并：

# if your history looks like that :
 *--x--a--b--c  <- v1.0
     \
      *--*--*--*--y <- v2.0

# merging will turn it into something like that :

 *--x--a--b--c------
     \              \
      *--*--*--*--y--m <- v2.0

这有两个效果：

• 分支v1.0的所有功能和修补程序都将被带到（您必须决定这是好事还是不好）
• git现在知道a，b，c已集成到分支v2.0中，以后的合并将不会尝试将它们考虑在内（这通常是一件好事）

1. 调车，采摘樱桃：

• 这使您可以更轻松地选择摘录v1.0的一部分，而不带走其他部分
• 结果将是新的提交，这些提交与先前的提交无关，因此请记住应该以其他方式跟踪“ fix 123”已被应用（例如，提及提交消息中的问题）

1. 手动重写此修补程序

这可能不是遵循的方法；但是，如果git merge或git rebase触发了太多的冲突，则解决冲突最终可能听起来很像手动编写最终的修复程序。
同样，检查代码和测试可能会引起一些差异，这些差异需要加以修复以匹配其他版本的细节。

我只是想通过这种方式强调一个事实，那就是最终您是知道什么是移植到v2.0的“正确解决方案”的人。