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

Question

我工作的公司希望每月发布一次，我正在努力说服他们改用 git。 我相信处理这个问题的正确 git 方式是为每个版本（即每月）建立一个集成分支，并在集成分支上建立功能分支以进行新的开发和更改。 该环境充满了相互依赖性，有时由于其他外部系统所需功能的延迟，某个功能必须推迟到不同的月份。 这些项目通常会在 2-3 个集成分支上并行进行活动，并且活动仅限于一组联系相当密切的人员。 （这意味着我怀疑只要我们在最后一个集成分支上，我们就可以使用变基——对于一半的人来说，至少有一半的时间是这样）

有相当多的人参与其中，所以我真的需要一些直接的如何执行此操作的指南，分支/合并结构的逻辑解释以及执行此操作的实用 git 命令。 有谁知道这样的描述非常适合这样的工作流程？

Answer 1

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

该结构基本上遵循您所说的：集成分支，以及功能分支。
在这种工作流程中，关键是要像您一样理解所有开发都不会进入下一个版本。
但对于 DVCS，了解分支是否可以发布和克隆也很关键。

最后一点（发布）将对合并命令产生很大影响
，即：

• 合并
• rebase。

每当开发人员必须在任何集成分支上合并他的工作（他从“中央”存储库中提取）时，我会建议：

# 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

最后一个变基将重写本地合并的历史记录，但在分支中您无论如何都不会发布（因此没有造成任何伤害）。
一旦所有新功能都正常工作，您可以将该私有分支合并回相关集成分支的当前 HEAD。

“私有分支 - 合并或樱桃选择 - 变基 - 本地解析 - 合并回来”是一个必要的工作流程，因为多个团队必须将他们的工作合并到一个公共分支。 他们需要在将其合并到公共分支之前重播他们想要在私有分支中发布的内容，否则每个团队都可能破坏公共分支的 HEAD 所代表的内容。

问题中的其他详细信息：

• git 提交频率
• git 发布管理（另一个合并工作流程）
• JC Hamano 文章（感谢 Jakub Narębski）