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。

“私人分支 - 合并或樱桃挑选 - 重新分配 - 本地分辨率 - 合并回来”是一个必要的工作流程，因为几个团队将不得不将他们的工作合并到一个公共分支。他们需要在合并到公共分支之前重播他们想要在私人分支中发布的内容，否则每个团队可能会破坏公共分支的HEAD所代表的内容。

的问题，其他细节：

• git commit frequency
• git releases management（另一个合并工作流程）
• JC Hamano articles（感谢Jakub Narębski）