用于维护项目扩展叉的Git工作流? [英] Git workflow for maintaining an project extension fork?

查看:94
本文介绍了用于维护项目扩展叉的Git工作流?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们在GitHub上派生了一个OSS项目,并为其添加了一些自定义扩展。我们希望发送一些我们对原始项目所做的更改(错误修复等),但其他更改是原始项目维护人员目前不感兴趣的功能扩展。我试图找出管理这种情况的最佳工作流程。



我想让我们的主分支包含(原始项目提交)+(我们的错误修复贡献)+(我们的自定义扩展)。我想我们会需要一个按功能分支的模型,以便我们可以将错误修复与定制扩展分开。我们可以从我们的主分支开始自定义的扩展分支,但是我想我们也想维护一个本地的origin分支或者跟踪原始项目的东西,这样我们就可以从那里开始那些没有被我们污染的bugfix分支定制的东西。或者别的。

任何人都可以提出构建这个工作流程的最佳方式,这样所有的各种提交都会去他们应该去的地方,而没有去他们不去的地方应该去?

解决方案

这听起来像你已经回答了你自己的问题。创建一个名为vanilla的分支或跟踪上游主分支的分支,并拥有一个包含您的自定义扩展的主分支。为你做的每件事创建分支。对于错误修正,从香草开始。为了你自己的东西,从主人开始。每过一段时间,香草就会变成主人。为了将错误修正到你的自定义扩展分支中,你可以直接将他们的分支合并到master中,或者等待上游接受你的错误修正pull请求,然后从vanilla到master的下一个合并将包含错误修正。这似乎是一个非常正常的工作流程。


We've forked an OSS project on GitHub and are adding some custom extensions to it. We'll want to send some of the changes we make back to the original project (bug fixes and the like) but other changes are feature extensions that the original project maintainers aren't interested in at the moment. I'm trying to figure out the best workflow for managing this situation.

I want our master branch to contain the sum of (commits from the original project) + (our bug fixes for contribution) + (our custom extensions). I imagine we'll want a branch-per-feature model so that we can keep bug fixes separate from custom extensions. We can start custom extension branches from our master branch, but I guess we'll also want to maintain a local "origin" branch or something that tracks the original project so that we can start bugfix branches from there that aren't polluted with our custom stuff. Or something.

Can anyone suggest the best way to structure this workflow such that all the various commits go where they're supposed to go and none go where they're not supposed to go?

解决方案

It sounds to me like you have already answered your own question. Create a branch called "vanilla" or something which tracks upstream's master branch, and have a "master" branch which contains your custom extensions. Create branches for each thing you do. For bugfixes, start them off of "vanilla". For your own stuff, start them off of master. Every once in a while, merge vanilla into master. To get the bugfixes into your custom extensions branch, you could merge their branches into master directly, or just wait for upstream to accept your bugfix pull requests, and then the next merge from vanilla to master would contain the bugfixes. This seems like a very normal workflow.

这篇关于用于维护项目扩展叉的Git工作流?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆