git用于内部开发的工作流程描述 [英] Workflow description for git usage for in-house development

问题描述

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

有相当多的人参与其中，所以我真的需要一些直接的指导方针来做到这一点，无论是分支/合并结构的合理解释还是实际的git命令。有没有人知道这样的描述适合这样的工作流程？

解决方案

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

该结构基本上遵循您所说的：集成分支和功能分支。

在这种类型的工作流中，理解为你做了，所有的开发都不会让它到达下一个版本。

但是对于DVCS，它也是了解分支可以发布和克隆的关键。

最后一点（出版物）对合并命令
有很大的影响，即：
$ b

• 合并


• rebase。

每当开发人员必须在任何集成分支他从一个中央仓库中取出），我会建议：

＃切换回上一个发布标签（从哪里功能分支下一个版本完成）
$ git checkout previousReleaseT ag
＃创建自己的私有
$ git checkout -b myIntegrationBranch
＃合并或者樱桃选择我们想要在下一个版本中实际添加的内容
$ git merge ...从我们的功能分支
＃rebase，在实际集成分支之上的私有集成分支
$ git rebase integrationBranch


最后一个rebase会重写本地合并的历史记录，但是在分支中，您不会发布任何内容（因此不会造成任何损害）。

一旦您的所有新功能都有效，您可以将该专用分支合并回相关集成分支的当前HEAD。

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

<问题中的其他细节：

• git commit frequency


• git发布管理（另一合并工作流程） JC Hamano文章（感谢 JakubNarębski）

The company I work for wants to have monthly releases, and I am trying to convince them to switch to git. I believe the proper git-way to handle this is to have a integration branch for each release (i.e. monthly) and have feature branches off the integration branches for new development and changes. The environment is loaded with interdependencies and sometimes a feature has to be postponed to a different month because of delays in required features from other external systems. The projects will generally have activity on 2-3 integration branches in parallel and the activity is confined to a group of people who are in fairly close contact. (Which means I suspect we can use rebasing as long as we're on the last integration branch¸which is true at least half of the time for half of the people)

There's a fair amount of people involved, so I really need some straight guidelines of how to do this, both a logical explanation of the branch/merge structure and the practical git commands to do this. Does anyone know of such a description that is reasonably well fit for such a workflow ?

解决方案

a logical explanation of the branch/merge structure

The structure basically follows what you said: an integration branch, and features branches.
In this kind of workflow, it is key to understand, as you did, that all development will not make it to the next release.
But with a DVCS, it is also key to understand a branch can be published and clone.

That last point (publication) will have a big influence on the merge commands , namely:

• merge
• rebase.

Whenever a developer has to merge his work on any integration branch (he pulled from a "central" repository), I would recommend:

# 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

The last rebase will rewrite the history of your local consolidations, but in a branch you will not publish anyway (so no harm done).
Once all your new features are working, you can merge back that private branch to the current HEAD of the relevant integration branch.

The "private branch - merge or cherry pick - rebase - local resolution - merge back" is a necessary workflow since several team will have to merge their work to a common branch. They need to replay what they want to publish in a private branch before merging it to the common branch, otherwise each team could break what is represented by the HEAD of the common branch.

Other details in the questions:

• git commit frequency
• git releases management (another merge workflow)
• JC Hamano articles (thanks to Jakub Narębski)

这篇关于git用于内部开发的工作流程描述的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！