标签: feature-branch

" 特征分支 " 是指每个特征在其自己的分支中开发,并且仅在经过测试并准备发运时才合并到主线中.这允许产品所有者选择进入给定货件的功能以及如果更重要的工作进入而部分写入的"停放"功能(例如,客户打电话给MD进行投诉).

" 重构 "正在改变代码以改进其设计,从而降低变更成本.如果不继续这样做,你往往会得到更难以编写测试的代码库.

在现实生活中,总会有客户销售新功能,并且由于政治原因,所有客户都必须看到"他们的"功能组正在取得进展.因此很少有时间没有很多半成品功能坐在树枝上.

如果已经进行了任何重构,那么"特征分支"中的合并变得更加困难,如果不是不可能的话.

我们只是不得不放弃能够进行任何重构吗？

另请参阅" 如何处理重构与合并需求之间的紧张关系？"

我们使用TeamCity和GitHub Enterprise.我们使用git的开源式工作流程:mainline每个组件都有一个存储库,当人们想要进行更改时,他们会

• 叉mainline到他们自己的帐户(所以可能有很多叉子)
• 在他们的fork中创建一个分支
• 实施变革
• 及时更新mainline/master已发生的变化
• 提交fork/feature-branch- > 的拉取请求mainline/master

我们对这个工作流程非常满意; 它强制进行代码审查(好吧,至少是手动步骤,希望实际上涉及实际读取代码并运行其测试),然后主线才能看到任何变化,这在历史上一直是个问题.如果作者是查看拉取请求的人,我们想使用GH Status API(博客文章,API doc)将合并按钮变为非绿色,但这是为了以后.

我们将TeamCity 7.1设置为观察主线存储库并在看到更改时进行构建.但是,它当前设置的方式,CI仅在看到更改时构建mainline/master.

我们应该如何在TeamCity中配置我们的VCS根目录,以便我们可以拥有相同的工作流程,但CI将根据主线仓库的分支触发基于分支的构建？ 最好不要单独注册每个叉子？

我已经阅读了TeamCity 7.1的功能分支文档(博客文章,发行说明,文档),但我没有看到如何将它应用于我们的任意数量的forks模型,而不是每个人 - 提交 -到主线式特征支行.

我刚刚开始使用git flow,有一些我不太了解的东西.首先,我从不直接开发任何东西.如果我做某事我要么使用启动修补程序或功能.

当我开始一个新功能('sequentialUpgrades')时,我的插件是1.1.5版本.那是4天前.在过去的4天里,虽然还没有完成这个新功能,但我完成了2个修补程序,所以这些已经合并回主人,然后在完成它们时开发,当然我在这两个分支上都有最新的更改,包括修补程序和上午在版本1.1.7 ...如果我做了git diff master develop,没有区别.

现在当我回到我的功能分支继续开发这个新功能时,功能分支仍然回到1.1.5,所以我没有最新的2个修补程序.

所以我有两个问题:

1. 如果有任何方法可以获得最新的更改到我的功能分支而不会搞砸了什么？

我正在考虑将开发合并到功能分支中,但我认为这不是正确的方法.但是,我真的很喜欢,在开发这个新功能时,需要抓住最后2个修复程序.

2. 如果我无法做到这一点,那么当我完成这个功能时,它现在如何合并回到开发中而没有任何冲突？我无法绕过这个.

因为我在1.1.5开始这个功能.在功能分支中,我对文件access-level.php进行了重大更改.当我做了修补程序时,我在同一个文件中改变了5-6行.一个文件如何能够以1.1.5的形式重新回到一些重大的变化,并将它们合并到1.1.7的同一个文件中,从那时起它也发生了变化？

阅读本文之后,将主要分支的更改收集到我的功能分支是有意义的: Git工作流和rebase与合并问题

clone the remote repo
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

如果功能分支对我的机器是本地的,我可以很好地重写历史记录.

但是,如果我在功能分支上与其他人合作,该怎么办？现在我们的功能分支保存在远程存储库中,我们如何从主分支到我们的功能分支获得最新的更改？

那我们合并了吗？或者还有另一种灵巧的GIT方法吗？

提前致谢!

有很多关于如何在git中"撤消"合并并不容易的讨论.简短版本:如果撤消合并提交,它还会告诉git以后永远不会将这些更改合并.

在进行合并时我能做些什么来减轻这个问题吗？在很多情况下,只需在软件开发的正常过程中撤消合并就非常非常有用,更重要的是,在需要回滚更改时控制发布分支的状态.

编辑

我已经看到了本文中的解决方案,并没有真正认为它是一个解决方案,更多的是对问题的解释.这个需要

1. 总是使用--no-ff
2. 当你想要恢复依赖于它们的代码时,记住你所有的撤消合并(这可能是未来几小时,几天,几周或几个月......)

我想要的是

以下是它在Subversion中的工作原理.假设我有一个名为"release-candidate"的分支,这是我们在登台服务器上运行的以及我们尝试使用功能的地方.假设我在功能A分支中合并.在Subversion中,它只是一个变更集,并且所有文件的所有历史记录都已合并.假设我们不喜欢它,所以我们想把它拿出来.我们只是撤消单个变更集,而不必考虑其他任何事情.我们可以在将来的任何时候将功能分支A合并回来,而不必记住我们在某一点将其合并并将其取出.

我希望能够尽可能接近这种流程.我想优化"不必记住未来的东西",即使它让事情在某种程度上采取了更多的步骤.(这可能是不可能的......)

我们使用Vincent Driessen 成功的Git分支模型作为我们的分支模型.一切都很好,但我还没有真正看到一个特定的问题.

根据我的理解,当需要新功能时,您可以分支development并创建一个新feature分支.你会在这方面工作,当你完成后,你会将这个分支合并到development分支中.

如果开发人员创建一个功能然后将该功能合并回来,却development发现功能代码中存在一些错误,该怎么办？应该在哪里修复？是否应该从开发中启动新的fix/ bugfix分支并在那里修复代码？我看不到另一种方式.

应该怎么做呢？

谢谢

什么是实现以下工作流的首选方法与任何Git或Subversion (我在更多的利益Git版本,但比较肯定将是有益的):

• 假设我们最近发布了该产品的主要版本,并且有一个特定的polisihin分支release-2.0.x.

  然后开发继续进行,并将几个功能分支合并到master/trunk(它们将成为即将到来的部分release-2.1.x).

• 现在,在某些时候,另一个特征(即,critical-feature)被开发并合并回来master/trunk.我们意识到这个功能非常重要,我们必须将它向后移植release-2.0.x.

这是针对所述情况的小型伪图.请注意,顶部的所有内容都会导致release-2.0.x和当前之间的树差异master/trunk并导致合并问题(否则我可以简单地合并critical-feature并避免编写此问题:)

    (features added since 2.0.x, which
     should not be backported)
              ^   ^    ^
              |   |    |    (code refactorings done
              |   |    |     in master/trunk)
              \   |    /     (*) (*) (*)          
-------------------------------------------------------> master/trunk
      |                                          |
      |                                          |
      |                                          |
      \ release-2.0.x                            \ critical-feature
                                                   (should be backported)

问题:

• 从 …

我们的开发/发布周期如下:

1. 开发人员创建功能分支,实现功能
2. 开发人员指示功能已准备好进行验收测试(UAT)
3. 测试人员部署功能分支并接受(或拒绝)功能

接受的功能然后由测试人员合并到主分支中,因此将在下一个发布周期中释放(我们每周部署主干/主代码).

我们对合并冲突感到沮丧,因为当测试人员使用UAT的功能并发现它不会干净地合并时,在其中工作的开发人员通常会转向别的东西.

我们正在考虑一个解决方案,TeamCity会针对当前主分支自动合并每个功能分支,导致合并冲突的任何构建都被视为失败的构建 - 这将使我们能够及早了解有问题的合并,以便我们可以修复他们早点.

TeamCity似乎没有对此工作流的内置支持(即,当推送分支X,结帐主,将分支X合并到其上,构建,单元测试,创建包时).有没有人使用TeamCity和Github创建类似的工作流程 - 可能使用自定义的msbuild目标？

编辑:我应该澄清我们正在使用Github,但我们目前没有使用拉取请求 - 听起来这是我应该调查的事情.:)

当我B从分支创建一个新分支A并执行单个提交时,TeamCity会触发多个构建B,尽管我只期望一个构建.
我将"在每次签入时触发构建"设置为true,但是应该只有一个构建,因为只有一个新的提交.似乎TeamCity在当前月份内触发每个提交的构建.A完成所有分支构建,并使用相同的构建配置来构建分支A和B.我是否可以将TeamCity配置为仅针对尚未构建的提交创建构建(无论在哪个分支上)？

我正在按照这里描述的工作流程进行操作,因为我发现很多参考文献指出这个页面是一个很好的工作流程.正如文章中提到的,"功能"分支在开发人员之间共享,但不会转到中央存储库.

假设开发人员"A"启动了一个新的功能分支git checkout -b newfeature develop.现在让我们说开发人员"B"也需要处理这个功能.这是我的问题.

我做了什么:

1. 开发人员"B"将开发人员A的计算机添加为远程计算机
2. 开发人员"B"运行 git branch remoteA/newfeature
3. 开发人员"B"在这个分支上工作,提交他的工作并将更改推送回remoteA.

现在,第3步无效.我收到一条消息:

remote:错误:默认情况下,更新非裸存储库中的当前分支被拒绝,因为它会使索引和工作树与您推送的内容不一致,并且需要'git reset --hard'来匹配工作树对HEAD.

remote:错误:您可以在远程存储库中将'receive.denyCurrentBranch'配置变量设置为'ignore'或'warn'以允许推入其当前分支; 但是,除非您安排更新其工作树以匹配您以其他方式推送的内容,否则不建议这样做.

remote:error:要压制此消息并仍然保持默认行为,请将receive.denyCurrentBranch'配置变量设置为'refuse'.

我已经设定了sharedRepository = true,但没有帮助.

我有两个问题:

1. 在开发人员之间共享功能分支的正确方法是什么？
2. 如何将开发人员B的存储库中的更改推回给开发人员A的原始存储库？