我对跟随 github 上的 fork
的 forkflow 有点不清楚。
如果我对一个中型项目(例如 OpenGrok)的原始存储库中的各种错误进行了几个小的独立修复怎么办?
我是否为每个相对较小的无关错误修复创建单独的分支?
我是从
master
创建每个分支,还是可以从下一个分支创建一个不相关的分支?我是否将修复提交到
master
中?
我的意思是,随着时间的推移,我仍然想保留所有历史记录,但我只是担心过一段时间后,对于相对较小的错误修复,许多无意义的分支会变得一团糟。
我计划为给定项目贡献一些不相关的修复,并尝试对开发方法进行一些规划。
最佳答案
在 github 上 fork 项目并且您计划向上游提交更改时,有几种可能的工作流程。这是我通常倾向于遵循的工作流程之一(我将调用我从中 fork 的 repo 作为远程 source
和我的 repo 作为 origin
) :
- 将
source
使用的主分支分支到origin/my-dev
。 origin/mydev
是我所有更改和主要开发的地方。- 我经常将
remote/master
rebase 到origin/master
(这一步是多余的,但有时我很容易把所有东西都放在一个 Remote 上)。 - 每当您想从上游获取更改时,将
source/master
或重新设置基础的origin/master
merge 到origin/my-dev
. - 如果我想向上游提交补丁或错误修复,我会启动一个新的功能分支,我可以将其用于 pull 请求。我将其命名为
origin/my-feature-1
。我从最新的origin/master
(或source/master
) 创建了这个分支
- 我将我在
origin/my-dev
中为此功能所做的更改精心挑选到origin/my-feature-1
中。在此步骤之后执行任何测试。 - 从
origin/my-feature-1
提交 pull 请求 - 如果您的 pull 请求获得批准,更改将 merge 到
source/master
(以及origin/master
)。 - 执行从
origin/master
(或source/master
)到origin/my-dev
的 merge 。 - 就分支的生命周期而言,我通常倾向于在将其 merge 到上游后摆脱短期存在的主题或功能分支(分支只是 git 中引用特定提交的轻量级指针)。<
不断重复此工作流程。
关键思想是你的 pull 请求不应该对上游维护者造成任何严重的冲突,否则他/她会盲目拒绝贡献。
我举了一个例子,当你想从 origin/my-dev
上游贡献 D2
和 D3
时。 D2'
和 D3'
是 D2
和 D3
的 rebase 版本。使用 U
的提交是 source
中的上游提交,D
是您在 origin
中的下游提交。带有M
后缀的是 merge 。
视觉上是这样的:
source/master origin/my-dev
U1
U2 Initial-fork
U3-----------\
| \
| \------------D1
| D2
U4 Sync up from upstream |
U5-----------\ D3
| \ |
U6 \------------DM4 origin/feature-1
| |
| | Starting point of feature-1
U7------------------------------------------------------------D2' (Rebased version of D2)
| | D3' (Rebased version of D3)
| D5 /
U8 D6 Pull-request /
| | getting merged upstream /
UM9--------------------------------------------------------/
| |
| Resync |
|-------------\ my-dev |
U9 \ |
U10 \-----------DM7
| |
| |
关于git - 在 github 上 fork,那么我如何管理我的贡献?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15823962/