目前我们正在使用 cvs 进行版本控制。我们想使用 Vincent Driessen 的分支模型迁移到 git (http://nvie.com/posts/a-successful-git-branching-model/)
对于构建，我们使用 maven。
我们希望通过 pom.xml 将不同的 maven 版本（基于 git 版本）分配给功能分支，以保持我们的 maven 存储库干净。
如果您将功能分支合并到开发分支中，maven 版本将覆盖目标分支的 maven 版本。
有没有可能防止这种情况发生？我们的用例是愚蠢的吗？
用于标准合并情况的自定义合并驱动程序会非常好，但是它们只适用于特殊情况？
【问题讨论】：
标签： git maven version-control versioning branching-and-merging
听起来是个明智的想法。但是为什么整个建筑必须在同一台机器上进行呢？您可以设置单独的机器（甚至虚拟机）来构建您关心的分支，以便将不同的环境严格分开（这就是我理解您的目标）。 DVCS 的美妙之处在于它们是分布式的，您可以将部分项目发送到其他地方。
来自 CVS，习惯 git 不会一帆风顺。建立一个你关心的小项目（一个玩具项目不会做）但它并不重要（你会搞砸，并且可能需要重新开始清理）以加快速度。将 git 用于您的“个人”工作（也许您有一组小脚本可以自动执行重复性任务、配置文件等）。
【讨论】：
不要这样做。
Git 没有像 CVS 这样的版本号。 Git 使用哈希码。您可以指定模仿旧 CVS 版本但需要手动工作的标签。
不要将功能分支部署到主 Maven 存储库。主仓库应该只包含发布。
当您使用功能分支时，您无法再部署 SNAPSHOT 版本，因为来自不同功能分支的 SNAPSHOT 会相互覆盖。
这是我们的解决方案：
功能分支很少离开开发者机器。仅当多个成员在同一功能上工作时才会推送它们。
开发人员应在其本地计算机上运行构建（包括测试）。构建服务器只构建主分支和少数几个功能分支。
当构建服务器构建一个特性时，它使用一个独特的 maven 存储库来完成这项工作。这意味着构建服务器有 N 个本地 maven 存储库。您必须这样做以防止 SNAPSHOT 版本覆盖自身。
功能完成后，将合并到主分支。此时，它对所有人可见。
我们从不将 SNAPSHOT 版本部署到共享的 Maven 存储库。原因很简单：我为功能 X 部署了我的 SNAPSHOT 版本。另一个开发人员进来，启动他的 PC 并构建一个模块。 Maven 现在会很高兴地下载我的 SNAPSHOT 并破坏他的构建。或不。开发人员会遇到非常奇怪的错误。执行的代码与他硬盘上的源不匹配。会浪费很多时间。
【讨论】：