背景：我在一家小型软件公司工作，该公司传统上从事研究型工作，在商业领域没有太多经验。我们现在正试图进军商业世界。由于我们起源于研究，我们习惯于非常快速的开发周期和非常少的结构，以维护适当的项目版本。
问题：缺乏结构现在被证明是一个障碍，因为每个开发人员对代码库的看法略有不同。一个开发人员发现的问题不能被另一个开发人员重现，并且在一个构建中发现的问题可能会在下一个构建中消失（或者更糟糕的是，可能会出现新问题）。对于负责集成所有项目并确保满足质量和性能标准的人（即我自己）来说，这会带来非常令人沮丧的经历。
潜在的解决方案：我个人相信我们需要通过固定版本号和定期发布来实施更好的结构。不言而喻，适当的版本控制将如何帮助解决我们的许多问题，但当然也不是没有问题 - 开发人员需要做额外的工作来执行和测试版本，并且将不再能够使用最新版本的一切。
问题：首先，您建议采用什么样的策略来确保发布所需的过程和工作尽可能顺利进行？我们使用 git 进行版本控制，使用 maven 进行构建系统，并且我们正在运行错误跟踪和持续集成系统，所以我相信这些工具就在那里。我只是不确定正确的发布过程应该是什么样子。
您拥有三大要素：版本控制、通过 Maven 的一键式构建和您的持续构建服务器以及错误跟踪。听起来你们正在倾向于敏捷方法论，因此您应该尝试始终将产品的主干版本保持在接近可交付的状态。
当您决定发布您的第一个版本时，请为该版本从您的主干版本创建一个分支。确定标签方案并确保标记分支版本。例如，您的第一个版本可能是 1.0.4530，其中 1 表示第一个版本，0 表示它是第一个候选版本，而 4530 是版本控制更改编号。您测试此发布分支并修复其上的重要错误。过了一会儿，你发布了另一个候选版本，比如 1.1.4807。这个过程重复了几次（比如说），你的版本变得足够好，你发布了 1.3.5167 版本。
同时，您的新开发仅发生在主干版本中，有时您需要将错误修复从 1.x 发布分支合并回主干。稍后，您将从主干中分离出一个 2.x 分支，为您的第二个版本重复该过程。您通常会有几个活动分支（加上主干），开发仅限于主干，每个分支都保持原始状态并独立于开发。
你们将掌握事情的窍门，并且您的开发人员协调问题将变得不那么频繁。但这些问题几乎都将仅限于主干，而不是发布分支。
一个开发人员发现的问题不能被另一个开发人员重现，并且在一个构建中发现的问题可能会在下一个构建中消失（或者更糟糕的是，可能会出现新问题）。对于负责集成所有项目并确保满足质量和性能标准的人（即我自己）来说，这会带来非常令人沮丧的经历。
潜在的解决方案：我个人相信我们需要通过固定版本号和定期发布来实施更好的结构。
我认为您不需要为了内部协调而非常频繁地发布。您可以通过版本控制来做到这一点。只是让人们在报告问题时谈论特定的 git 修订。另请注意，您还必须协调任何外部依赖项/库。某种供应商分支机构可以帮助解决这个问题。
听起来开发人员需要使用“测试分支”并更多地尊重“稳定/生产分支”。
以“在这个分支中做你的狂野西部的东西”的概念进行销售，当你对结果感到满意时，你将它合并到这个“无聊的稳定生产分支”中......（或类似的东西）
有关于一般主题的书籍；亚马逊搜索甚至返回三个专门的“使用 git 进行版本控制”的标题。
我认为您将从定义代码库的规范视图中受益。称之为测试。如果出现在测试中，问题就是问题。如果某个问题在某些开发人员看来没有出现，则由该开发人员确定重要的区别是什么；同样对于出现在开发人员视图中但不在测试中的问题。
一种约定是每晚从源代码重新构建测试。更严格的约定是在每次更新时重新构建测试。如果您的团队很小（五个或更少）并且没有分散在很远的距离或多个时区，一个合理的第一个近似值是在安装了您的工具链的服务器上测试一个 git 工作区以及一些 cron 作业，以便这个工作区每天晚上（通常）更新和重建。