我工作的公司希望每月发布一次，我试图说服他们切换到git。我相信处理这个问题的正确方法是为每个版本（即每月）创建一个集成分支，并在集成分支上设置功能分支以进行新的开发和更改。环境中存在相互依赖关系，有时由于其他外部系统所需功能的延迟，功能必须推迟到不同的月份。这些项目通常会同时对2-3个集成分支机构进行活动，并且该活动仅限于一组相互密切联系的人员。 （这意味着我怀疑我们可以使用变基，只要我们在最后一个整合分支上，至少有一半人的半数时间是真的）
涉及到相当多的人，所以我真的需要一些关于如何执行此操作的直接指导，既可以对分支/合并结构进行逻辑解释，也可以使用实用的git命令来执行此操作。有谁知道这样的描述非常适合这样的工作流程？
答案 0 :(得分：13)
分支/合并结构的逻辑解释
结构基本上遵循你所说的：集成分支，并具有分支 在这种工作流程中，正如您所做的那样理解所有开发都不会进入下一个版本是关键 但是使用DVCS，理解分支可以发布和克隆也是关键。
最后一点（发布）将对合并命令产生重大影响 ，即：
每当开发人员必须将他的工作合并到任何集成分支（他从“中央”存储库中取出）时，我建议：
# switch back to previous release tag (from where feature branches for next release where done)
$ git checkout previousReleaseTag
# create one's own private
$ git checkout -b myIntegrationBranch
# merge or cherry-pick what we want to actually put in the next release
$ git merge... from our feature branch
# rebase that private integration branch on top of actual integration branch
$ git rebase integrationBranch
最后一个rebase将重写您当地合并的历史记录，但在分支中您无论如何也不会发布（因此不会造成任何损害）。
一旦所有新功能都正常工作，您就可以将该专用分支合并回相关集成分支的当前HEAD。
“私人分支 - 合并或樱桃选择 - rebase - 本地解决方案 - 合并回来”是一个必要的工作流程，因为几个团队必须将他们的工作合并到一个公共分支。在将它们合并到公共分支之前，他们需要重放他们想要在私有分支中发布的内容，否则每个团队都可能破坏公共分支的HEAD所代表的内容。
问题中的其他细节：