标签: git-flow

我一直在使用这里概述的git分支策略http://nvie.com/posts/a-successful-git-branching-model/

到目前为止,它一直很适合我.

我经常发现自己要问的问题是在处理功能分支时,我最终需要实现与整个项目相关的代码.处理这些情况的最佳方法是什么？

a)检查主开发分支,提交更改并重新设置开发的功能分支.

b)在功能分支上进行更改,然后合并回开发,以便其他功能分支可以访问该代码.

c)为公共代码创建一个新分支,并将其合并到Develop以及需要使用它的任何功能分支中.

这是另一个问题.您多久将一个功能分支合并回主开发分支？您是否等到功能完全完成然后合并并删除它？或者,如果它稳定的话,你会在整个生命周期中多次合并开发吗？

我正在为我的项目使用git flow.当一个版本被合并到主分支中时,它会被发布版本标记(例如1.2.0)并部署到我的生产服务器.

现在我想快速恢复到之前的版本标记(例如1.1.0),因为部署不应该发生.

阐述:

• 我将1.2.0版本分支合并到主分支中.
• 我用1.2.0标记主分支.
• 我将当地的回购推送到原产地.
• 我的结论是我发布得太早了.
• 我想恢复到标记为1.1.0的master状态.
• 我希望master @ origin也恢复到1.1.0状态.

我该怎么做？

我非常喜欢Scott Chacon描述的"github flow"工作流程:http://scottchacon.com/2011/08/31/github-flow.html

他描述了为什么github不使用Vincent Driessen所描述的git flow工作流程(http://nvie.com/posts/a-successful-git-branching-model/),我们不会出于同样的原因使用它,最重要的原因是,它不能很好地处理拉取请求,它不适合网站开发,你没有"正式发布的软件产品版本",但不断改进网站.

我们正在一个小团队中开发一个大型在线社区,其中包含许多旧的遗留代码(一些代码超过10年),测试覆盖率很差.我们使用与github类似的工作流程,目前我们使用功能分支进行开发,并使用拉取请求将它们集成到主分支中,进行同行评审,请求反馈等.当功能完成并被其他人批准时,它是合并为主人.我们每周几次将主人推送到我们的测试人员以及测试版用户使用的分期环境中.我们尝试每两周向公众发布一个主分支,因此每个合并的功能分支都必须进行足够好的测试,并且在过去几天内没有合并"更具风险的功能分支",直到公开发布为止.

这不是一个完美的工作流程,因为当再次将"风险特征"合并到大师时,我们不能再使用master将修补程序部署到公共.

Github使用持续交付进行部署,这对我们来说不是一个选择,我们确实需要人们在我们将其发布给公众之前对其进行测试.

拉取请求只能合并到一个分支中.所以这是github上一个简单的工作流程,只有一个长期运行的分支是master.也许我们不应该每两周发布一次,但是当它们合并到掌握时发布拉取请求？但是这样很难测试,我们可以在合并之前运行我们在功能分支上的单元测试,并且我们可以将分支部署到beta测试人员的分段,但这并不总是那么容易,有时你不得不做手动更改数据库(我们不能自动执行,因为我们的beta测试人员的临时服务器使用生产数据库,因此风险太大),因此您必须等到管理员完成此操作.更大的问题是,如果您只向beta用户发布功能分支,它们没有集成,他们会看到新功能,并且可能每天多次删除功能.并不是说你不能运行集成测试,或者你在发布之前很晚才运行它们,当一个功能分支刚刚合并到master时......

另一方面,如果我们使用2个长期运行的分支,比如git-flow中描述的develop和master,我们可以解决修补程序问题,我们可以使用pull-requests来合并功能分支来开发,我们可以使用pull请求用于将最近更改合并到master中的发布分支,但我们无法使用pull请求工作流合并回更改以进行开发.

正如您在github流文章中所看到的(#6 - 审核后立即部署),github工程师不仅可以部署到生产环境,还可以部署到临时环境.不仅工程师可以做到这一点,还有支持和设计师.但它如何只与一个集成分支一起工作？如果最后一次拉取请求在几小时或几分钟内无论如何都要进行生产,则不需要暂存环境.有时它们似乎将功能分支部署到分段,这是有意义的,但它们没有集成,所以我上面描述的将会发生,你会看到在临时环境中进出的功能,即使它们在部署功能之前合并了master的更改分到分段(你认为这会是一个好主意吗？).或者有多个临时环境是否有意义,每个功能分支一个？但是这样你再​​次失去了持续整合的优势.如上所述,我认为你不能在beta测试环境中这样做.

我在工作流程,git流程和github流程中都看到了问题,我更喜欢github流程,但是如果你没有良好的测试覆盖率并且需要人们进行更多测试,那么这似乎很难.

那么,当人们需要更多的测试(qa和beta测试人员)时,我如何集成和测试功能分支？

我在Git hub上设置了一个存储库,我正在使用git flow.我知道如何创建功能,发行版和修补程序,但是从我到目前为止所读到的内容看起来并不清楚如何推送到中央存储库(github),因此我有几个问题:

1. 一旦一个功能完成,你已经运行了git flow feature finish如何将其推送到github？
2. 一旦它被推送到Github我是否需要从Github拉出来或者我们是否从未触及中央仓库并且只是使用它以便其他开发人员/服务器可以从中获取？
3. 开发人员如何使用git flow从中央仓库中撤出？

谢谢

我们正在为我们的项目使用GitLab,我们认为它很棒.我们还使用git flow来管理功能,开发和主分支的变化.

你能在GitLab中使用Merge Request构建来管理git流风格的分支吗？

接受发布分支的合并请求时的含义,它会将发布分支合并到master AND中进行开发..或者我们应该始终在本地机器上使用git flow来接受合并请求.

当我在项目中发现一些错误时,我创建了一个修补程序分支:

git flow hotfix start fixSomeBug

当我做了一些更改和提交时,我想将这些提交合并到master,所以我输入了

git flow hotfix finish fixSomeBug

接下来我需要写三条消息:

• 写一条消息,合并到master

• 为标签写一条消息:fixSomeBug

• 写一个合并开发的消息

这很好,但我不想自动创建一个名为fixSomeBug的标签.

那么我该怎么办呢？

我们经常从master分支到大型功能分支.这些功能分支通常在与master合并之前工作数天甚至数周(尽管最佳实践要求我们需要尽可能频繁地合并,实际上它可能会有所不同).

因此,我们尽可能地尝试git pull --rebase origin master以便与master保持更新.但是,我们偶尔会遇到以下情况:

1)从master分支到分支feature/new-branch

2)进行更改feature/new-branch并提交更改.

3)git pull --rebase origin master把提交放在主人的头上.修复任何冲突和git add .+git rebase --continue

4)进行更多更改feature/new-branch并提交更改.

5)git pull --rebase origin master再次.

但是,在步骤5),该过程要求我们从步骤3)修复相同的冲突.哪个可能很乏味.

这是正确的最佳实践git流程,如果没有,我们还能做些什么来提高流程效率？

我们使用Gitflow进行Web构建,我对如何hotfixes工作有疑问.但首先我应该解释一下,我们并没有完全使用正常的Gitflow工作流程.

我明白,通常你会分支你的features,他们会develop在完成时合并,你会创建你的release,release合并到master你并部署它,作为一个真正的"版本化版本".

但是,由于这是客户端工作,我们不会执行"发布",而是在需要时部署功能,因此我们的feature分支的更改会master在临时基础上合并.

这确实会引起问题,因为feature分支从分支开始develop就超前了master; 合并这些feature分支到master会合并其他的改变到master的变化(即存在于develop在当时feature是支链的都还尚未master).我们知道这不是Gitflow的设计方式,但我们需要某种分支模型,所以我们(有点)通过提交提交而不是合并分支来解决这个问题.

所以,我理解这些问题,我不相信他们正在为我现在的问题做出贡献,但为了以防万一,这就是我们使用它的方式.不过我的问题是:

hotfixes 应该怎么合并？

在我看来,情景是:

• master 是"生产"
• develop 领先于 master

然后,您想要修补hotfix分支的即时问题.在Gitflow中,这个分支来自master,当你完成时hotfix,它会被合并到master 和 develop

但这怎么不会造成大问题呢？

最近,我尝试创建一个hotfix在一个文件中更改单行副本.我完成了hotfix,并且更改合并到master没有任何问题,但是当它厌倦了合并时develop,它创建了一个巨大的35文件差异,在我没有触及的文件中有几个合并冲突,由于develop和之间的差异master.

我明白,这是因为你被合并hotfix 的分支,其本身分支master …

我们已经使用git-flow了一段时间来开发软件框架.我们在一个存储库中有master和development分支.

最近,不同的客户开始对购买框架感兴趣,这需要为每个客户定制框架.

到目前为止,我们feature-customerXYZ从主服务器为每个客户分支了一个新分支,在那里进行了自定义并在自定义完成后保持分支打开(这可以防止产品master/ development分支的"感染" 来自定制).

与此相对应,在框架本身的发展继续使用该产品通常混帐流工作流程master,development,features,hotfixes和release分支机构.

在这种情况下发生了两种常见的情况,我认为我们的工作流程无法以最佳方式处理:

1. feature-customerXYZ分支的开发可以包含值得在产品master/ development分支中实现的提交.由于feature-customerXYZ分支永远不会被关闭,因此这些提交必须是rebased或者cherrypicked是产品分支,这需要在定制之后进行额外的工作并且容易出错.

2. 在feature-customer分支打开时发现的修补程序git-flow通过将hotfix修复后的已打开分支仅合并到产品master和development分支来处理,但不会合并到打开的feature-customer分支中(更准确地说:它们不会合并到所有打开的feature分支中).

是否有一个git工作流可以简洁地处理这个？是否有一个聪明的替代,而不是merge,cherrypick或rebase的提交到产品master/ develop或开feature分店,分别？

我使用 git-flow 并根据 Github 保护规则我有分支master和develop受保护，两者都带有选项Require linear history。

一切正常，但现在我想不只是从develop到合并master，而是开始使用“拉取请求”( develop -- PR --> master) 我想知道是否可以在保持历史线性的同时保持分支均匀/同步，而不需要对develop树枝施加力。

目前，如果我PR从developto创建一个拉取请求master，并且因为Require linear history选中了该选项，我无法合并，但只是squash and merge因为rebase and merge这样，如果我修改develop分支并进行另一次提交，它会提前 N 倍，但永远不会是“偶数” 。

我发现报复的唯一develop方法master就是

git pull origin master --rebase

但这随后意味着强制推动：

git push -f

不使用时PR，我只需将开发合并到master（FastForward）并保持历史线性，我可以合并拉取请求并通过禁用来防止强制推送Require linear history，但历史不会是线性的。（我认为 PR 没有使用 FastForward 合并）

我使用 git-flow 的原因是该develop …