标签: git-flow

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

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

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

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

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

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

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

我是新来的GIT和GIT-Flow.[在我的python-django项目中]

我做了什么 :

git flow feature start new_feature
# perform some commits on the feature/new_feature branch

git push origin feature/new_feature

git flow feature finish new_feature
# I suppose that merges feature/new_feature to develop and deletes feature/new_feature

git push origin develop # Pushes the new changes to remote

问题:

• 功能/ new_feature分支似乎在我的本地计算机上被删除.
• 但是在github[我的远程命名原点]上,我可以看到分支功能/ new_feature.
• 我很困惑,它不应该显示已删除的分支.
• 我四处寻找解决方案 - 但他们说你应该手动删除它们,这似乎不适合抽象 git flow

那么,你们每次使用时都要从所有遥控器中删除所有功能分支git-flow吗？

难道我做错了什么 ？

我正在为我的项目使用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流程.我们有一个不熟悉Git的同事昨天意外地合并了发展成师.

开发有很多功能,我们的下一个版本将启动,需要恢复合并.这创建了一个撤消所有更改的提交.当我们将master合并回develop时,revert commit会删除我们的功能生成的代码.

在保留新功能的同时,能够与master的修补程序同步开发的最佳方法是什么？

- 编辑 - 只是为了澄清,恢复是一个恢复.IE git revert -m 1 <sha>,因为提交已经被推送到远程存储库.

发布之后,我已经提出了一个可能的解决方案,通过分支主控并恢复还原,但是我很好奇是否有其他可能性可以最小化冲突.

您好,这是我的git工作流程.我正在尝试使用Sourcetree创建一个新的修补程序.不幸的是我收到此错误:

There is an existing hotfix branch (issue-#001). Finish that one first.

我已经完成了issue-#001.为什么我无法创建新的？

我试图将分支名称从TeamCity传递给OctopusDeploy,以便我们可以轻松跟踪部署来自哪个分支.

为此,我想将分支名称附加到版本号(或使用octopack构建的nuget包),以便我可以在OctopusDeploy UI中显示它.

这很好用,除了我们使用git-flow所以我们的一些分支包含斜线会导致octopack失败(因为文件名不能包含斜杠):

+:refs/heads/(feature/*)
+:refs/heads/(release/*)
+:refs/heads/(hotfix/*)

有没有办法用TeamCity中的其他东西替换斜杠而不改变我们命名分支的方式？

在master移动远远超出该版本之后,git flow如何处理修补程序？

脚本

1. 开发时执行的1.0工作,在发布/ v1.0发布分支上稳定并在快速合并中推送到主控标签v1.0指向主人的尖端和稳定分支的尖端
2. 版本1.1 - 3.2以相同的方式发布.

3. 我们需要修补1.0中的错误

   • 从v1.0标签分支
   • 执行修复
   • 合并到哪里？

师父在未来很远,任何合并都不是快进和乐趣,让我们说会发生冲突.

我会合并发布稳定分支并制作新标签吗？这是后续修补程序将用作起点吗？

我们正在使用git-flow分支模型开发包含Web工件的多个项目.

参考:Vincent Driessen的git flow分支模型

我们正在使用develop分支并jenkins自动构建和部署SNAPSHOTWeb工件以测试环境.

我们手动运行git flow release start并git flow release finish构建非快照工件,这些工件部署到我们的工件并最终部署在prod中.

(如何运行git flow xxx命令？这是一个备忘单)

我的问题:QA的工作流程应该如何运作？

鉴于:

1. 我们不希望将快照部署到QA
2. 如果我们在QA中测试的相同工件部署在PROD中,那就太好了
3. 我们可以git flow尽可能地使用脚本和分支模型

看看分支模型,我自己最好的理解是:

1. 制作发布分支(例如release/1.1).
2. 从发布分支构建工件并测试QA.
3. 在release/1.1分支中进行更改并根据需要返回到步骤2
4. 测试完成后,finish发布(合并为主)
5. 在prod中部署工件.

有没有人有这方面的经验,特别是一步2？如何唯一地标识发布分支中的工件？

我们正在考虑使用版本候选版本,其中maven版本1.1.RC1指示release-candidate1,跟随1.1.RC2,最后1.1(最终版本).

我在git-flow脚本上观看了一些视频,其中一个术语是"后合并" - 例如,将修补程序合并到master中,然后将其合并到develop中.

我假设返回merge是一个概念而不是本机git命令.什么确切的命令包含后合并操作？