标签: branching-strategy

过去

我使用subversion作为scm开发了一个软件项目.到目前为止,开发总是发生在trunk,所以当需要修复bug修复时会出现问题.现在,我们想重新考虑我们的分支策略,其要求是:我们希望能够同时处理多个未来版本.

任务

这意味着:假设,我们正在处理的当前版本是1.0.下一个计划版本是2.0,之后的版本是3.0.现在我们已经发布了1.0版本

• 维护1.0版
• 开发2.0的功能
• 同时开发3.0的功能

当然,在其他两个版本中也需要在1.0中应用的修补程序.此外,2.0的功能也必须在3.0.此外,可能会计划一个次要版本,例如1.1,其中还包括新功能,并且必须单独维护.

可能的解决方案

我提出了以下分支策略:

• 行李箱将被废弃
• 对于每个新的计划发布,都会创建一个源自最后一个发布分支的分支
• 更改在版本时间轴中"向上"传播

让我再详细说明一下:在给定的示例中,我们将从trunk分支1.0版.此外,我们将从版本1.0分支2.0版,从2.0版分支3.0版.当在1.0中进行更改时,它将合并到2.0,然后合并到3.0.

这个问题

这是一种有效的方法吗？它会在技术上有效吗？是否存在组织缺陷？有最佳做法吗？(所有互联网都会提出:"在主干中开发,在发布分支中维护").放弃后备箱对我来说特别奇怪 - 这是错的吗？

我想就如何满足以下要求的专业开发设置提供一些意见.

• 几个PHP开发人员(比如PHP)
• 每个开发人员属于一个组
• 每个小组都有一名代表任务的团队领导
• 每个开发人员都在一台Windows 7计算机上运行
• 并使用NetBeans或Eclipse进行开发
• 每个开发人员'拥有'一个虚拟测试服务器,在那里他可以运行代码
• 正在使用的VCS是SVN
• 有一个临时服务器,产品在发布/部署之前最终会经过测试

我给了一些特定的技术,不要太抽象和b/c我也会对插件等的具体建议感兴趣.

在该设置中,我想到了几个问题.

1)因此每个开发人员都将在个人分支机构工作.

2)该分支在工作副本中签出.

现在......这个工作副本在PC上使用dev的IDE进行本地编辑,并在服务器上执行/测试.

在这种情况下,最好/通常的做法是什么？我的意思是 - 如何在不造成太多开销的情况下在服务器上获取编辑后的代码？

开发人员会在他的本地磁盘上有代码吗？或者让IDE通过隧道或特定协议在远程虚拟服务器上写入会更好吗？

3)每天,开发人员都会将他的工作投入到他的个人分支中,该分支位于中央存储库中.

是否有关于存储库应该位于何处的最佳实践？一个单独的服务器？

4)然后在开发人员完成任务后,他/她或团队负责人将新代码合并到相应的主分支或主干中.

最令人困惑的部分是我在2)和3)之间写的内容.因为到目前为止我只使用本地服务器.例如,具有运行代码的服务器的VM位于共享文件夹中,因此我将能够直接编辑它.当服务器现在实际上是远程时,我不确定如何有效地弥合差距.有效地意味着不必通过FTP手动上传.

欢迎外部资源或书籍推荐.

编辑

我的问题是/准目标是准标准/最佳实践.我认为这几乎是一个标准的开发方案,因此必须有一个"通常"的解决方案.

编辑2

好的...所以让我们尝试一下图片:

V是一个或多个开发人员的虚拟测试服务器D. C和C'是两个代码版本.它们应尽可能保持一致.

我想到了两个解决方案:

1:编辑C,然后将其上传到C',然后执行C',然后提交C.

2:没有C存在.Just C',它是通过一些隧道技术编辑并执行和提交的.

我的胆量告诉我两种解决方案都是半最优的.那么什么是"专业"/最有效/最快/最方便/最无摩擦/最不容易出错/最佳实践/行业标准？

任何问题？

下面的 Git 分支模型似乎非常普遍。 http://nvie.com/posts/a-successful-git-branching-model/

在我们当前的项目中，我们没有开发分支，从 master 分支创建功能/错误修复分支并将它们合并回来并标记所有相关的里程碑（完成的功能/错误修复/发布）。

所以我想知道，拥有一个开发分支有什么好处？

我们有一个网络应用程序,我们有几个企业客户.我们最近决定将其作为SaaS应用程序提供,并遵循精益方法(与我们的公司产品并行).这意味着我们在旅途中进行了可能无法投入生产的实验.

在我们精益求精之前,我们对以下分支策略感到满意(我相信它非常标准):

• 掌握 - 永远稳定
• 开发 - 经常不稳定(功能分支切断开发新功能进入下一个主要版本)
• major_release_x - live(在dev被合并到master之后切断master,这是bug修复发生并合并回master和dev的地方)

现在我们除了上面的内容之外还有以下内容,并且效果不佳:

• lean_release_branch - live(切断major_release_x并包含实验)
• experiment_x - 切断major_release_x(这是我们一起攻击该功能然后将其合并到lean_release_branch的地方)

我们现在的情况是,我们需要快速而且经常在精益方法的指示下发布,当我们对任意事物得到可靠的反馈时,我们需要生成它并尽快释放它(从lean_release_branch开始).

问题是我们无法创建dev的功能分支(因为它很可能不稳定),我们无法创建lean_release_branch的功能分支,原因有两个:

1. 它已被实验代码污染,因此此更改/功能将无法恢复到主控
2. 在lean_release_branch总是需要准备发布的,所以我们不能忙着做它的测试和修正,如果有需要进行固定和释放的关键问题(合并更改/功能进去后)

有谁知道我们的设置更好的策略？

这个问题不是特定于iOS的,但为了清楚起见,我在此处包含了实际用例

我运行一个名为iOS的项目Foobar,显然是在版本控制之下.在iOS项目环境中的项目文件中,有一个名为Foobar-Info.plistXML文件,它存储有关项目的有趣信息,例如版本和我所构建的构建数量.

每次我构建项目时,我都会将存储在此文件中的构建计数递增,如下所示:

...
<key>BuildCount</key>
<string>2203</string>
<key>CFBundleShortVersionString</key>
<string>0.0.4</string>
<key>CFBundleVersion</key>
<string>0.0.4-release/0.0.4.2203</string>
...

其中'0.0.4-release'是git-flow分支名称,2203是内部版本号.这是在CFBundleVersion现场使用的,所以对我来说,构建来自哪里是非常明显的.

想象一下,在另一个分支中,自发布以来我已经取得了很多进展,并且相同的字段看起来像:

...
<key>BuildCount</key>
<string>2754</string>
<key>CFBundleShortVersionString</key>
<string>0.0.4</string>
<key>CFBundleVersion</key>
<string>0.0.4-feature/add-quux-and-baz.2754</string>
...

假设我完成了发布,它已合并到主线develop分支中.

问题

为了获得发布分支中的最新更改,我想将功能分支重新绑定到develop.

当发生这种情况时,Foobar-Info.plist将在rebase进程中的每次提交时引发冲突.这是因为每次提交都会增加构建号; 我必须通过选择手动指定具有最新版本的行来手动合并.请注意,3向差异的基本版本也会有所不同.

<string>2000</string>  // Base
<string>2754</string>  // Local   ** always pick this one; it's the latest
<string>2203</string>  // Remote

我怎么能告诉git对于一个特定的文件,Foobar-Info.plist我希望它通过最新的更改来解决我的冲突？

编辑:该文件必须保持在源代码管理下.我想保留BuildCount它,因为它是我项目中努力的一个很好的指示,我想保留它!我知道这个数字只表示完成的MINIMUM数量,但这对我来说已经足够了.

我们正在采用一种新的分支策略来与Agile合作,并使我们能够逐个功能发布,我们有一个master分支和一个QA分支作为永久分支.每晚构建将基于QA和发布将来自master.开发人员将为每个故事创建一个功能分支.所有要素分支都要分支master,然后合并到QA测试中,然后将要素分支合并到master后续版本中.这很好,直到以下场景:

• 开发人员A("Rod")创建feature/RodsFeature,执行了一些工作并合并到QA(但还没有master)
• 开发人员B("简")创建feature/JanesFeature,执行了一些工作,现在正在尝试合并QA
• Jane现在正在发生合并冲突,这是QA由Rod合并引入的变化引起的feature/RodsFeature

如果Jane要绕过QA并合并feature/JanesFeature进去master,那么就没有冲突,因为feature/RodsFeature还没有master.但是,Jane必须合并QA,原因很明显.为了解决冲突,她可以将Rod的变化拉入并整合到她的特征分支中,解决冲突然后进行合并 - 一旦她将她的特征分支合并到master其中,会产生不良后果,也会引入Rod的变化.还在等待QA测试.

所以 - 解决方法是直接解决QA分支上的冲突,保留Jane的功能分支,以便以后合并master.但是,这会破坏代码审查策略,因为合并应该由对等方批准 - 通过这样做,她已合并到QA本地并推送到远程而没有任何拉取请求或同行评审.

在这种情况下,什么被视为"最佳做法"？

我们正在尝试遵循gitflow分支模型,但有一个转折点.

我们有四个可以部署产品的服务器环境,每个服务器都有一个目的:开发,内部测试,外部测试和生产.

• DevServer,开发人员在开发时测试他们的不同功能.开发人员无法在他们的计算机上进行本地测试,他们必须在DevServer上进行更改才能进行测试
• TestServer,一旦开发人员完成,QA测试人员就会测试多个功能
• ReleaseServer,在将版本移至生产环境之前对其进行单独测试
• ProductionServer.生产服务器

我们试图尽可能简化合并/冲突解决方案,因此我们创建了两个不属于gitflow模型的额外分支.

正常的gitflow分支

• 开发
• master(匹配'ProductionServer')
• featureXXX
• releaseXXX(每周版本部署到'ReleaseServer')

但这两个分支也不标准,可能需要改变......

• dev-release(DevServer的副本)
• 测试版(TestServer的副本)

然后过程如下:

• 开发人员从'develop'创建'featureXXX'
• 多个开发人员将他们不同的"功能"合并到"dev-release"分支中,并且"dev-release"分支被发布到"DevServer",然后所有开发人员都可以测试他们的不同功能.并非所有这些功能都将在下一个版本中
• 一旦开发人员对上面的开发测试感到满意,他们就将'featureXXX'合并到分支'test-release'中,并将其部署到'TestServer'.并非所有功能都属于同一个下一个版本.
• 一旦对featureXXX进行'TestServer'测试,开发人员就可以将他们的featureXXX关闭为'develop'.
• 开发人员然后创建一个新的'releaseXXX'或将他们的'featureXXX'合并到现有的'releaseXXX'中.
• 'releaseXXX'分支部署到'ReleaseServer'并进行测试.
• 一旦'releaseXXX'测试签署,'releaseXXX'将合并到develop和master中,并部署到'ProductionServer'

我们搞乱了整个gitflow模型吗？

这是我们的分支流程:

我正在尝试配置 GitVersion 以使用发布流分支策略。

基本上，我有一个主线 Master 分支、Release、Feature 和 Fix 分支。功能和修复分支是从主分支创建的，并通过拉取请求合并回主分支。在冲刺结束时，我从 Master 创建一个发布分支，该分支将持续到下一个冲刺结束，届时将创建一个新的发布分支。Release 分支不会合并回 master 分支。它们甚至可以在创建新的发布分支后被删除。如果需要修补程序，它将在从创建并合并回 master 的 Fix 分支上开发，然后精心挑选到当前的 Release 分支中。我只在主要版本中使用 git 标签。

回到 GitVersion，我想对其进行配置，以便在创建新的发布分支时次要版本号会增加，并且当发布分支上有新的提交（从修复分支中挑选）时补丁号会增加。

有人已经这样做并且可以帮助我吗？

我有一个Team Foundation Server 2013代码结构,如下所示......

$/TeamProject/Application/AllTheCodeFiles

......但我想重构......

$/TeamProject/Application/Trunk/AllTheCodeFiles

这将允许我通过在与"Trunk"相同的级别创建"Release"分支来实现分支和合并策略.

如果我尝试分支或将Application目录移动到Trunk,我收到错误消息:

目标项$/TeamProject/Application/Trunk不能位于源项$/TeamProject/Application下.

所以,这是我遵循的过程,感觉不对,我猜测有更有效的方法.

1. 重命名$/TeamProject/Application为$/TeamProject/Application-trunk
2. 创建一个新$/TeamProject/Application目录
3. 移动$/TeamProject/Application-trunk到$/TeamProject/Application/Trunk

这样做之后,历史与之$/TeamProject/Application无关$/TeamProject/Application/Trunk.我的问题是,知道更多的人会以什么方式做到这一点？

我在git树中遇到了意外情况。我已经从master创建了一个分支，但是当我在新分支上执行提交时，好像这些提交与master在同一代码行中进行...

如您所见，在最左侧是master（深蓝色）的代码行，在顶部，我们可以看到Sprint_15，它是master的分支，似乎在同一行上有提交...不知道为什么会这样。由于功能已合并到Sprint_15中而不是母版中，因此我希望代码会换行，

我的想法是，通过将Sprint_14和Sprint_15合并在一起，这在历史上做得很时髦，但是我不确定为什么。

我对git还是很陌生，因此它的某些基础仍然让我感到困惑。