Java Gitflow工作流与Maven-何时构建什么？

Gitflow引入了几个分支，如

develope

、

release

、

hotfix

，还鼓励使用功能分支

在Maven项目中，您通常构建快照和发布版本，并且通常使用三位数的语义版本对它们进行编号

尽可能地自动化构建过程是明智的，但问题是：我们应该在什么时候构建快照版本，什么时候构建发布版本，什么时候根本不构建这些版本

我认为以下可能是合理的：

• 每当一个功能分支被合并回

  develope

  ，就会触发一个快照构建并部署到Maven存储库中
• 当创建

  发布

  分支时，发布构建开始

但还有更多的情况：

• 当我修复

  发行版

  （或

  热修复版

  ）分支上的错误时，我是否总是想要一个新的发行版版本
• 在开发特性的过程中，我应该建立在特性分支上吗？如果是这样，该版本应称为什么（

  1.2.3-FEATURE1-SNAPSHOT

  ？）

---

让我们从发布开始。当已经构建的二进制文件部署到TST envs并进行检查时，是否发布版本将在将来决定。提交或构建时，您无法预测该版本是否为“发布版”
一旦你放弃这些想法，事情就会变得简单得多。既然不能在发行版中使用基于分支的版本，那么让功能分支有所不同又有什么意义呢？您最好忘记将分支和版本控制的概念混合在一起
通过持续交付（即使你没有充分利用它，你也可以借用它的想法），任何构建都有可能进入PRD，因此：
• 使用您喜欢的任何类型的版本控制构建二进制文件。对于Maven，最简单的方法是坚持使用SNAPSHOT*并且永远不要使用“发布”快照。它是独一无二的，它是标准的，它与Nexus（保留策略）有一些优势
• 当你准备好去珠江三角洲并且选择了发布版本时，用某种方式标记它。它可以是跟踪所有PRD部署的CI作业；或者您可能有一个包含所有发布版本的页面；或者您可以将二进制文件传输到另一个Maven repo（仍然可以是快照类型）。如果使用快照的保留策略，则后者非常方便
此外，我们通常还想提到二进制文件是从哪个commit构建的。您可以在构建期间将其放入二进制文件（某种类型的

version.properties

）。为了方便起见，你甚至可以在你的应用程序中创建一个服务端点
PS：如果你只是想遵循GitFlow的建议，这里有一个例子可以说明你是如何做到的。但是你会遇到你在问题中已经提到的所有问题（以及更多问题）

---

*Maven自动将快照版本解析为时间戳版本。但是您实际上不能使用这个功能，因为在构建过程中，不同工件的时间戳是不同的。如果要在构建中的所有二进制文件中保持版本相同，则需要使用

versions:set

手动生成并分配时间戳版本。这并不复杂，但值得一提。
谢谢您的想法。坦率地说，我不喜欢将快照投入生产的想法。我们现在不这么做，似乎是在反对马文。此外，如果不跟踪时间戳，您就无法轻松确定部署了哪个版本。只有在按原样使用时，即在依赖项中写入快照时，快照才会与Maven相冲突，因为这会导致不可重复的生成。与范围相同。另一方面，解析的快照（看起来像

0.0.1-20101204.150527-6

）是一个非常好的版本，它确实包含时间戳。顺便说一句，Maven是在CD被描述之前创建的，所以并不是所有的想法都是最新的（Maven发布插件就是一个很好的例子）@StanislavBashkyrtsev您可能需要查看最新的Maven发布插件时间戳快照的问题是，从Maven的角度来看，这些插件被标识为发布版本，而不是从存储库管理器的角度来看，这可能会导致其他问题。我在两个组织中使用快照版本控制已经6年了-它非常有效嗯，而且没有造成任何问题。如果你要求Nexus提供一个带有时间戳的版本，它会给你这个版本（不是最新的可用快照）。但是，你也可以使用发布版本，我以前试过，它也很有效（不过你不会从Repo Manager那里得到一些很好的仅快照的功能）。例如，您可以使用Build No和Commit hash，也可以使用时间戳并上传到“releases”。但您仍然需要为每个构建生成一个相同格式的版本。从我的观点来看，它深入到一个问题：您是否将这些构建的构件作为其他项目中的依赖项使用？此外，您使用哪种版本控制策略？（语义版本？）。。。