使用标准gitflow对npm依赖项进行版本控制

Question

我遵循标准gitflow，并且我有不同的环境来测试开发构建和发布构建。大师开始生产。

我还将我的JS应用程序划分为多个私有npm模块，这些模块进入私有npm存储库。

Q1

有没有什么方法可以针对以标准方式构建的分支来对我的npm包进行版本化？

我所尝试的是，我在版本中添加了prereleasepre-ids。类似于
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev

但是，如果我从master创建一个功能分支，它包含master的版本。当我试图将PR从它提升到dev时，它会显示冲突，因为dev的版本中有-alpha.x。为了解决冲突，我必须使用目标分支的版本控制。在发布分支上进行合并时也会出现同样的问题。

当涉及到合并到master时，发布版本(带有-beta.0的版本(完全取代了master。所以它变成这样：在master上，

| It was        | After Merge   | After version bump  |
| ------------- |:-------------:| -------------------:|
| 1.0.0-rc.0    | 1.0.0-beta.0  | 1.0.0-rc.0          |

理想情况下，在版本升级后，我希望它是1.0.0-rc.1

是否可以将包JSON排除在版本控制之外。

Q2

如何控制使用这些NPM模块的应用程序的包JSON中的版本控制？它也在gitflow和功能分支模型上，我希望当应用程序在dev分支上构建时，它使用从各自的dev分支发布的工件构建。

老实说，我可能也滥用了gitflow，但到目前为止，我太困惑了，不知道哪里出了问题。

如有任何帮助，我们将不胜感激。

提前感谢

Answer 1

我解决它的方法是， //${buildNumber} and ${branch} are available as env variables in the build agent(at least available in jenkins/bamboo) tagversion="1.0.0-${branch}.${buildNumber}" echo $tagversion npm version $tagversion

所以我的构建被创建并发布为 1.0.0-master.1 //for master 1.0.0-release.1 //for release 1.0.0-dev.1 //for dev

Answer 2

您可以将所有分支中的package.json文件合并为ours。详细步骤如下：

1. 将merge.ours.driver配置为true

   git config --global merge.ours.driver true
   

2. 在每个分支上添加.gitattributes文件

   在每个分支上添加具有以下内容的.gitattributes文件，如下所示：

   echo 'package.json merge=ours' >> .gitattributes
   

   更多详细信息，您可以参考Git属性中的最后一部分(合并策略(。

到目前为止，在大多数情况下，package.json文件在合并过程中不会被覆盖。

注意：pakage.json文件将被覆盖以进行递归合并。当合并从branch1更改为branch2时，如果文件package.json仅在branch1上更改，则合并提交将通过递归合并策略保持package.json文件的版本为branch1。

例如在master分支上，版本1.0.0-rc.0没有改变；而在release分支上，版本已更改为1.0.0-beta.0。将release分支的更改合并到master分支时，版本将为1.0.0-beta.0(如您所述(。

因此对于递归合并情况，您需要在合并后手动更改package.json文件版本：

# On the merged branch, as master in above example
git checkout head~ -- package.json
git commit -m 'use the original package.json after recursive merge'