标签: git-flow

我们使用Subversion,除了像我这样的一些人,在Subversion中几乎没有分支和合并的经验.我的Subversion经验仅限于简单的功能分支,其中合并和树冲突虽然不是很罕见,但并不是很难解决.

鉴于此,我正在帮助管理一个项目,其中我们当前对trunk方法的提交根本不可持续地满足我们的需求.我介绍了功能分支和合并到我的本地化团队,我们取得了一些成功.然而,简单的功能分支仍然无法回答我们的所有问题,例如:

1. 我们如何为此版本和后续版本并行开发代码？
2. 什么代码被认为是稳定的？
3. 什么(开发中)代码将进入下一个版本？
4. 什么(开发中)代码将进入后续版本？
5. 我们的测试,验收或生产环境的代码版本是什么？
6. 我们如何将并发开发活动与已知的稳定版本集成,以减少引入错误和不完整的工作？
7. 我们如何为发布的代码提供热修复？
8. 从源头控制中我们如何知道目前正在进行的开发活动？
9. 我们如何在不中断当前代码库的情况下进行实验或研发而不会受到影响？

似乎 这里定义的git-flow将很长一段时间来回答很多这些问题.我在Mercurial中尝试了这个方法,似乎也可以在那里实现这个方法.可悲的是,此时迁移到DVCS已不在考虑范围之内.

但是,我在Subversion中模仿此方法的简短尝试因许多合并和树冲突而失败.合并选项和边缘案例众多且令人费解.

可以使用Subversion来实现git-flow,如果是,那么痛苦程度是多少？

我正在学习git-flow,我刚刚做了git flow feature finish <feature-name>,它合并了我的功能分支来开发和删除它.

而不是这个,我想将功能分支推送到github,所以我可以在同行评审后合并它.

所以问题是,如何"撤消"这个命令.或者换句话说,如何将我的最后两次提交从开发移动到我的功能分支？

我见过的大多数git工作流建议branch在合并到master之后删除它.例如,这个gitflow建议如下:

# Incorporating a finished feature on develop 
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

我为什么要删除分支？我也好奇当以后发现一个由该功能引入的错误时该怎么做 - 我是否应该再创建一个具有相同名称的分支,修复那里的bug,合并到master并再次删除分支？

在使用Gitflow时,将分支命名与功能与错误修复和修补程序分开的原因是什么？

也就是说,为什么不只是,例如,而不是:

feature/
bugfix/
hotfix/

做就是了:

change/

通过feature/bugfix/hotfix分开购买什么？

我一直在使用git flow.我正在寻找分支模型来修复开发分支中发现的问题和错误.我知道我们可以使用修补程序,但它适用于主分支,或快速修复生产.

修复开发中的错误不是一个功能.我总是可以重新初始化git flow并将默认前缀分支覆盖到bug /.但如果我还需要启动新功能,它需要重新初始化.这是一个很好的做法还是有一些技术可以解决这个问题？

我正在使用Atlassian的名为'Souretree'的Git GUI,特别是'Gitflow'模块来管理各个分支.

我刚刚创建了一个'release'分支,我不想将它合并回master或develop分支.我怎么摆脱它？我可以删除它吗？我担心的是我弄乱了gitflow配置.

我只对这个我不关心的分支做了一次提交.

警告:我对git和GitHub都很新.

因此,在我目前的设置中,我的团队使用git flow Hotfixes(通常由GitKraken或IntelliJ等图形工具启动和完成)进行更改,这些更改必须合并到两个分支中并在两个分支中向上推送.例如,流程将是:

1. 从大师拉最新
2. 启动修补程序
3. 提交更改
4. 将修补程序分支合并到主服务器中并开发并推送上游两者

我们现在正在考虑将代码移到GitHub中,并希望开始使用Pull Requests,原因如下:

• CI挂钩运行测试和东西
• 放置代码特定注释的地方与底层"问题"没有直接关系
• 避免每个人不断地将最新的master/develop拉到他们的本地机器上,以便他们可以合并更改

但在Hotfixes的情况下,我不知道该怎么办,因为我正在合并到两个分支但它真的是一个"动作"所以手动创建两个拉动请求似乎很奇怪,特别是因为我们当前的流程中的步骤4)单击一下.

有一种聪明的方法来处理这个问题吗？我理想的情况是推动Pull Request上的Merge按钮只会合并到两者中,但这似乎不是一个可用的选项.

我们一直在进行持续集成和持续交付,因为Subversion会在管道触发时提交.最近,我们开始在git-flow的一些项目中使用git,我们正在尝试决定使用git-flow的哪个分支来触发持续集成和连续交付管道.

这有两种方法:

1.使用开发分支

问题:使用git-flow我们应该在生产中部署发布(或主)分支,因此我们必须构建两个不同的管道,一个用于持续集成(分支开发),一个用于连续交付(分支主服务器).这可能会在生产中引入错误,因为生产中的版本与其他环境中的版本(集成,测试,登台)不同.

2.使用主分支:

问题:这样,我们就不会有真正的持续集成,因为对这些分支的更改不会频繁推送.

哪个是在管道中使用的rigth分支？

是否有任何大型软件项目使用git-flow,如果是这样,它会如何发展？

(参见http://nvie.com/posts/a-successful-git-branching-model/和http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

我想在我的团队中采用 git-flow 工具。

问题是“ git flow feature finish ”在本地合并了分支。我想创建一个拉取请求。因此，合并将发生在原点。

那么，在处理拉取请求的团队中使用 git-flow 工具的正确方法是什么？

试图谷歌它，但找不到有意义的东西。