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

Question

我所在的公司希望每月发布一次，我正试图说服他们转换到git。 我相信正确处理这个问题的Git方式是为每个发布（即每月）设置一个集成分支，并从集成分支中设立特性分支进行新开发和更改。该环境具有相互依赖性，有时由于其他外部系统所需功能的延迟，必须将特性推迟到不同的月份。项目通常会在2-3个集成分支上并行活动，而且活动范围仅限于一组人员，他们之间联系比较紧密。(这意味着只要我们在最后的集成分支上，就可以使用变基，对于至少一半的人来说，这是真实的情况)

由于涉及到较多人员，我真的需要一些明确的指导方针，包括分支/合并结构的逻辑解释和实际的git命令操作。是否有人知道这样一个描述，足以适用于这样的工作流程？

- krosenvold

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

最后一次变基将会重写本地合并的历史记录，但在一个你不发布的分支中（所以不会造成任何损害）。当你所有的新功能都可用时，你可以将私有分支合并到相关集成分支的当前 HEAD。"私有分支-合并或挑拣-变基-本地解决-合并回去"是必需的工作流程，因为多个团队将不得不将他们的工作合并到一个共同的分支中。他们需要在将其合并到公用分支之前在私有分支中重播他们想要发布的内容，否则每个团队都可能破坏由公用分支的 HEAD 表示的内容。其他问题中的细节：

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

- VonC

---

如果开发者想要包含发布在外部机器上的功能，则最后的“git rebase”将重写这些提交的历史记录。更干净的方法是将所有功能合并到公共集成分支（主分支？）中。 - Marius K

@Marius：但是当我提到“最后一次变基将重写您本地合并的历史记录，但在您不会发布的分支中（因此不会造成任何损害）”时怎么办？ - VonC