2

开发人员开始开发一项功能，我们称之为“修复硬编码链接”，一旦完成，它就会传递给另一个开发人员进行同行评审。同行评审员对代码更改和将功能分支合并到测试分支没问题。“修复硬编码链接”现在在测试服务器上等待技术测试。

test是功能分支在经过其他开发人员同行评审后合并的staging地方，是功能分支通过同行评审、TT 和 UAT 后合并的分支。

下一位开发人员开始处理下一张卡片并创建一个如下所示的分支：

git checkout test
git checkout -b story/bar

开发人员完成工作并将其传递给同行评审。同行审阅者对传递到 TT 和 UAT 的代码感到满意，所有人都很高兴并进入 PO。PO 很高兴，然后他将功能分支合并到 staging

git checkout staging
git merge origin/story/bar

通过这样做，我发现我们不仅应用了附加到特定卡修复程序的补丁，而且还应用了分支附带的整个历史记录。结果是提交“修复硬编码链接”正在暂存，但尚未完成该过程。

  • 我们的方法有什么问题以及改进它的任何建议吗？
  • 我们应该在 staging 之外创建我们的功能分支吗？
4

1 回答 1

1

基本上，您需要考虑发布工作流程（推/拉），而不仅仅是合并工作流程（featureto testto stagingto...）：此发布工作流程与合并工作流程正交。

任何新feature分支都必须在您要使用的最新官方版本之上开发feature。

如果是staging，则表示：

git fetch
git checkout -b newFeature origin/staging
# hack...

# make sure newFeature still works on top of staging as right now
# since staging might have received other feature 
# during the development of newFeature

git fetch
git rebase origin/staging
# local and/or unit tests...
# push for review
git push -u origin newFeature

当您合并 afeature到testorstaging时，您应该重新newFeature设置在 之上test，然后在 之上，然后才staging合并newFeature（快进合并）。
变基期间的任何冲突都意味着该功能被拒绝（开发人员必须获取，然后newFeature在导致问题的基础上本地变基该分支，以查看为什么存在冲突）。

于 2013-03-27T06:49:44.810 回答