内部开发的git使用的工作流程描述

Question

我工作的公司想要每月发布,我试图说服他们切换到git.我相信处理这个问题的正确方法是为每个版本(即每月)建立一个集成分支,并在集成分支上设置功能分支以进行新的开发和更改.环境中存在相互依赖关系,有时由于其他外部系统所需功能的延迟,功能必须推迟到不同的月份.这些项目通常会同时对2-3个集成分支机构进行活动,并且该活动仅限于一组相互密切联系的人员.(这意味着我怀疑我们可以使用变基,只要我们在最后一个整合分支上 - 至少有一半人的半数时间都是如此)

有相当多的人参与其中,所以我真的需要一些关于如何做到这一点的直接指导,既有分支/合并结构的逻辑解释,也有实际的git命令.有谁知道这样的描述非常适合这样的工作流程？

Answer 1

分支/合并结构的逻辑解释

结构基本上遵循你所说的:集成分支和功能分支.
在这种工作流程中,正如您所做的那样理解所有开发都不会进入下一个版本是关键.
但是使用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所代表的内容.

问题中的其他细节:

• git提交频率
• git发布管理(另一个合并工作流程)
• JC Hamano 文章(感谢JakubNarębski)