Git 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在某个时候决定更新到最新版本，如果您没有将补丁合并到master，那么补丁将不存在，这可能会导致一些罕见的bug再次出现

如果合并是处理这个问题的正确方法，是否有一些npm功能可以让我不忘记将我的补丁合并到master？或者甚至是比我正在修复的版本更高的所有主要版本（或者甚至是所有次要版本），因为如果团队A决定首先更新为2会更容易吗。*

---

如果没有像这样的功能，我会错过什么吗？向旧版本发布补丁是否太容易出错，并可能导致丢失一些错误修复？如果是这样，您是否应该阻止发布旧版本？

更多详细信息即将发布，但底线是：

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

---

让我们列出一些将代码从分支

A

移植到分支

B

的方法：

使用git merge实际合并分支：

使用

rebase

或

cherry pick

：

这有两个影响：

• branch

  v1.0版的所有功能和修复程序都将随附（这可能是件好事，也可能不是好事，你必须决定）

• git

  现在知道

  a

  、

  b

  、

  c

  已经集成到分支

  v2.0

  ，未来的合并将不会考虑它们（这通常是件好事）

重定基址、樱桃采摘：

• 这使您可以更容易地选择选择

  v1.0

  的一部分，而不带其他部分
• 结果将是新的提交，与先前存在的提交无关，因此记住“fix 123”已经应用，应该以其他方式进行跟踪（例如，在提交消息中提到一个问题）

手动重写修复程序

这可能不是遵循的方式；但是，如果

git merge

或

git rebase

触发了太多冲突，那么解决冲突最终听起来很像手动编写最终解决方案。
类似地，检查代码和测试可能会产生一些差异，这些差异需要修正，以匹配其他版本的细节

---

我这样说仅仅是为了强调一个事实，即最终，您需要知道什么是移植到

v2.0

的“正确修复”，更多详细信息即将发布，但底线是：

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

---

让我们列出一些将代码从分支

A

移植到分支

B

的方法：

使用git merge实际合并分支：

使用

rebase

或

cherry pick

：

这有两个影响：

• branch

  v1.0版的所有功能和修复程序都将随附（这可能是件好事，也可能不是好事，你必须决定）

• git

  现在知道

  a

  、

  b

  、

  c

  已经集成到分支

  v2.0

  ，未来的合并将不会考虑它们（这通常是件好事）

重定基址、樱桃采摘：

• 这使您可以更容易地选择选择

  v1.0

  的一部分，而不带其他部分
• 结果将是新的提交，与先前存在的提交无关，因此记住“fix 123”已经应用，应该以其他方式进行跟踪（例如，在提交消息中提到一个问题）

手动重写修复程序

这可能不是遵循的方式；但是，如果

git merge

或

git rebase

触发了太多冲突，那么解决冲突最终听起来很像手动编写最终解决方案。
类似地，检查代码和测试可能会产生一些差异，这些差异需要修正，以匹配其他版本的细节

---

我这样说仅仅是为了强调一个事实，即最终，您需要知道什么是移植到

v2.0

的“正确修复程序”，如果主要版本会有很大的不同，那么我同意是否应该合并修复程序需要一个决定，但是，在语义版本控制和增加主版本之后，每次都会有一个小的突破性变化（例如为其中一个类修复名称空间），并且基于我们的团队对旧版本所做的修复，它可以

git checkout v2.0
git merge v1.0

git checkout v3.0
git merge v2.0

# 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

# 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