使用标准 gitflow 对 npm 依赖项进行版本控制
Versioning of npm dependencies with standard gitflow
我遵循标准的 gitflow，并且我有不同的环境来测试开发构建和发布构建。大师去生产。
我也将我的 JS 应用分成多个私有 npm 模块，这些模块进入私有 npm 存储库。
Q1
有什么方法可以让我的 npm 包根据标准方式构建的分支进行版本控制吗？
我试过的是，我在版本中添加了 prerelease pre-ids。喜欢
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev
但是如果我从 master 创建一个功能分支，它包含 master 的版本。当我尝试从它向 dev 提出 PR 时，它会显示冲突，因为 dev 的版本中有 -alpha.x。要解决冲突，我将不得不使用目标分支的版本控制。在发布分支上合并时也会出现同样的问题。
并且在合并到 master 时，发布版本（-beta.0）完全取代了 master。
于是就变成了这样：on 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
是否可以让包 JSONs 脱离版本控制。
Q2
如何控制使用这些 NPM 模块的应用程序包 JSON 中的版本控制？它也在 gitflow 和功能分支模型上，我希望应用程序在 dev 分支上构建时，它使用工件构建从各自的 dev 分支发布。
老实说，我可能也在滥用 gitflow，但截至目前，我太困惑了，无法弄清楚我哪里出错了。
任何帮助将不胜感激。
提前致谢
您可以将所有分支中的 package.json 文件的合并策略设为 ours。详细步骤如下：
配置merge.ours.driver为true
git config --global merge.ours.driver true
在每个分支上添加 .gitattributes 文件
在每个分支上添加 .gitattributes 文件，内容如下：
echo 'package.json merge=ours' >> .gitattributes
更多细节，您可以参考Git Attributes中的最后一部分（合并策略）。
到目前为止，在大多数情况下，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'
我解决的方法是，
//${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
我遵循标准的 gitflow，并且我有不同的环境来测试开发构建和发布构建。大师去生产。
我也将我的 JS 应用分成多个私有 npm 模块，这些模块进入私有 npm 存储库。
Q1
有什么方法可以让我的 npm 包根据标准方式构建的分支进行版本控制吗？
我试过的是，我在版本中添加了 prerelease pre-ids。喜欢
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev
但是如果我从 master 创建一个功能分支，它包含 master 的版本。当我尝试从它向 dev 提出 PR 时，它会显示冲突，因为 dev 的版本中有 -alpha.x。要解决冲突，我将不得不使用目标分支的版本控制。在发布分支上合并时也会出现同样的问题。
并且在合并到 master 时，发布版本（-beta.0）完全取代了 master。
于是就变成了这样：on 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
是否可以让包 JSONs 脱离版本控制。
Q2
如何控制使用这些 NPM 模块的应用程序包 JSON 中的版本控制？它也在 gitflow 和功能分支模型上，我希望应用程序在 dev 分支上构建时，它使用工件构建从各自的 dev 分支发布。
老实说，我可能也在滥用 gitflow，但截至目前，我太困惑了，无法弄清楚我哪里出错了。
任何帮助将不胜感激。
提前致谢
您可以将所有分支中的 package.json 文件的合并策略设为 ours。详细步骤如下：
配置merge.ours.driver为true
git config --global merge.ours.driver true在每个分支上添加 .gitattributes 文件
在每个分支上添加
.gitattributes文件，内容如下：echo 'package.json merge=ours' >> .gitattributes更多细节，您可以参考Git Attributes中的最后一部分（合并策略）。
到目前为止，在大多数情况下，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'
我解决的方法是，
//${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