问题描述
正在将代码库从Subversion迁移到git（具体来说是使用Bitbucket），他对如何在多分支概念下管理发布构建感到困惑。
以下是他们在Subversion中的做法：
他们有一个基于声明性流水线（Jenkinsfile）的Jenkins作业。它有一个名为isRelease的参数，默认值为false。当他们决定构建一个发布版本时，开发人员手动启动作业，并将isRelease设置为true。在流水线中，当isRelease为true时，会执行一个名为“Release”的步骤，该步骤执行Maven发布操作。
他已经阅读了很多关于如何使用git分支的文章，但他无法决定使用哪个概念来构建发布版本。Jenkins似乎在多分支作业中没有提供手动构建的选项，所以看起来我们必须改变我们的方法。据我了解，有很多选择，例如：
(1) 使用第二个Jenkins作业
- 创建另一个Jenkins作业，专门用于手动启动发布构建。
- 这与我们目前的做法接近，但我觉得这实际上不是使用git的正确方式。
(2) 使用发布分支
- 创建一个名为“release”的分支。
- 当我们决定构建发布版本时，将其合并到“release”分支中。
- 让Jenkins流水线自动从“release”分支创建发布版本。
- 手动步骤将从启动Jenkins作业变为合并到“release”分支，这对我来说更符合git的风格。
(3) 使用develop分支
- 在开发过程中，创建一个名为“develop”的共同分支。
- 当我们决定构建发布版本时，将其合并到“master”分支中。
- 让Jenkins流水线自动从“master”分支创建发布版本。
- 类似于（2），只是以不同的方式使用“master”分支。
用户想知道哪个选项是最好的，为什么？还有其他更好的选项吗？
请注意，What’s the practice to perform a releasing with Git?听起来像是一个类似的问题，但它不是关于一般方法的，而是关于如何解决pom文件中的版本冲突的问题。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1：使用第二个Jenkins作业
使用第二个Jenkins作业来手动启动发布构建是一种常见的方法。这种方法与您目前在Subversion中的做法相似，但可能不是最佳实践，因为它没有充分利用git的特性。
方案2：使用发布分支
使用发布分支是一种常见的方法，它更符合git的工作流程。以下是使用发布分支的步骤：
1. 创建一个名为“release”的分支：git branch release
2. 切换到“release”分支：git checkout release
3. 合并开发分支到“release”分支：git merge develop
4. 在“release”分支上进行构建和测试。
5. 如果需要进行更改或修复，可以在“release”分支上进行。
6. 当发布版本准备好时，将“release”分支合并到“master”分支：git checkout master，git merge release
7. 在“master”分支上进行构建和测试。
8. 在“master”分支上打上标签以标记发布版本：git tag <version>
9. 推送“master”分支和标签到远程仓库：git push origin master --tags
使用发布分支的好处是，您可以在发布分支上进行构建和测试，而不会影响开发分支。这样，您可以在发布分支上进行必要的更改和修复，而不会干扰开发过程。
方案3：使用develop分支
使用develop分支作为开发过程中的共同分支，然后将其合并到master分支来构建发布版本，也是一种常见的方法。以下是使用develop分支的步骤：
1. 创建一个名为“develop”的分支：git branch develop
2. 切换到“develop”分支：git checkout develop
3. 合并特性分支到“develop”分支：git merge feature_branch
4. 在“develop”分支上进行构建和测试。
5. 当发布版本准备好时，将“develop”分支合并到“master”分支：git checkout master，git merge develop
6. 在“master”分支上进行构建和测试。
7. 在“master”分支上打上标签以标记发布版本：git tag <version>
8. 推送“master”分支和标签到远程仓库：git push origin master --tags
使用develop分支的好处是，您可以在开发分支上进行构建和测试，而不会影响主分支。这样，您可以在开发分支上进行必要的更改和修复，而不会干扰主分支的稳定性。
最佳实践
选择最佳的方法取决于您的团队和项目的需求。以下是一些考虑因素：
– 如果您的团队已经习惯了使用第二个Jenkins作业来手动启动发布构建，并且没有特别的需求，那么继续使用这种方法可能是最简单的选择。
– 如果您希望更好地利用git的特性，并且希望在发布分支上进行构建和测试，那么使用发布分支可能是更好的选择。
– 如果您希望在开发分支上进行构建和测试，并且希望将发布版本合并到主分支，那么使用develop分支可能是更好的选择。
无论您选择哪种方法，都应该确保团队成员都清楚并遵循相应的工作流程。此外，建议使用自动化工具（如Jenkins流水线）来自动执行构建和测试任务，以提高效率和一致性。
以上是一些常见的最佳实践，但根据您的具体需求，可能还有其他更好的选项。建议您根据团队和项目的需求进行评估，并选择最适合您的方法。