1

寻找有关如何设置 git 以支持多个开发人员开发功能的建议，以及我们如何推送到我们的各种环境，如 dev、qa 和 uat。

我在想这样的事情：

dev_branch
- new features get a feature branch i.e. dev_branch_feature_x
- once feature is completed, it gets merged into the dev_branch
- dev_branch then merges into main_branch

main_branch
- code must be merged into main to push to UAT
- once uat is signed off, it gets pushed to production

一个问题是，拥有一个 feature_branch 是否意味着我们需要为每个 feature_branch 提供单独的开发和 qa 环境？

如果 2 个开发人员正在开发一个功能，他们不能直接将他们的更改推送到 QA 环境，因为他们会相互覆盖。而且我不确定他们是否可以将两个更改合并到同一个分支中，然后推送，因为它们可能存在冲突。

上述分支模型是否可行，或者您有其他建议吗？

4

1 回答 1

1

A very popular workflow for use with git is described in http://nvie.com/posts/a-successful-git-branching-model/

Basically, what you are most successful doing is to have a development environment that is on a long-running branch, which can be the trunk if you wish or can be a separate branch, in this document one named 'develop'.

Issue branches and development branches would be branched off from this, developed and tested, and then merged back when the author believes they are stable. Then if whatever testing you require in development to qualify it to go to the next test level passes, you tag and build that and deploy it into the test environment.

When you are getting close to a release, you would branch from the running development branch for a release branch, which then is only touched to improve its stability for release. This makes it a dead-end branch, but a great place to apply hot-fixes later.

And if you are in one of those places that wants the trunk to be the most recent version deployed to production, then whenever something has passed all testing and is deployed to production, you merge it onto the trunk. This is option; in my opinion it is unnecessary overhead and complexity, but it is a Management Demand you run into quite often.

于 2012-06-25T22:46:04.410 回答