我们有两个主要分支：
master由开发人员更新release由CI更新。开发人员不会推动这个分支。我们的自动化持续集成工作原理如下：
这有一个问题：
主版本中的版本号不会增加。
如果我们这样做，那将会有一个无限循环，因为CI认为：
啊，master上的新变化（它没有看到它只是版本号更新）。让我们测试一下代码......
如何将CI的更改恢复为主文件？
我们希望避免所有CI提交进入主服务器的合并。在经常更新的repos上，每天都会有一个CI提交。结果是git历史中有太多CI提交。随着＆＃34;太多＆＃34;我的意思是＆＃34;太多＆＃34;对于人类的眼睛。
更新
我们做＆＃34;持续整合＆＃34;。软件每天两次测试。如果稳定，则版本号会增加。没有＆＃34;发布日＆＃34;在我们的背景下。
我们有开发/功能分支。但我认为这不是问题的一部分。合并到主服务器由开发人员完成。这不是自动化的。
答案 0 :(得分：1)
听起来您希望不断整合来自开发人员的更改，在这种情况下您应该使用相同分支（master），CI系统应该只是在主服务器上放置一个标签分支并使用它（或选择由其他方法放置的最新CI标签）来完成它的工作 - 它所做的就是验证该标签上的集成分支，它通常不应该对代码库本身进行任何提交。
使用另一个分支只是为了实现CI是恕我直言，这是一个复杂的方式，只会带给你复杂和麻烦（例如这个问题）。
如果您确实想要使用release分支进行发布，那么永远不会从master盲目地向其添加更改。您应该从不将其合并回master，因为master现在演变为下一个版本。 - 两个分支的上下文分歧，只是因为一个分支中的变化并不意味着它在另一个分支中起作用。
release分支在接近发布日期时应该具有逐渐减小的提交率（远小于master中的提交率）。如果需要修复主数据库和发行版中遇到的问题，则应该挑选它们并将其双重提交到2个分支，并使用适合每个分支的验证。
答案 1 :(得分：-2)
嗯......转换策略怎么样？
在开发/功能分支中工作，合并到master，ci发布master（或标签，如果你喜欢）。
对于git，master是项目的官方历史，分支只存在于master中。
我目前知道有两个（ok的三个用linux）不同的主流程序使用git。 一个是github model，另一个是Gitflow模型。 Gitflow有点复杂，而且通常也没有必要。
为什么在已有两个现有工作解决方案的情况下发明自定义策略？