我工作的公司希望每月发布一次,我试图说服他们切换到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所代表的内容。
问题中的其他细节: