在 github 上 fork 一个项目并且您计划向上游提交更改时,有几种可能的工作流程。这是我通常倾向于遵循的工作流程之一(我将调用我从中分叉的 repo 为 remote source
,我的 repo 为origin
):
- fork 使用的主分支
source
,比如说master
into origin/my-dev
。
origin/mydev
是我所有变化和主要发展的地方。
- 我经常重新定位(这一步是多余的,但有时我很容易将所有东西都放在一个遥控器上)
remote/master
。origin/master
- 每当您想从上游获取更改时,合并其中一个
source/master
或重新设置origin/master
为。origin/my-dev
- 如果我想在上游提交补丁或错误修复,我会启动一个新的功能分支,我可以将其用于拉取请求。我会打电话
origin/my-feature-1
的。origin/master
我根据最新(或source/master
)创建此分支
- 我挑选了我
origin/my-dev
在origin/my-feature-1
. 在此步骤之后执行任何测试。
- 提交拉取请求
origin/my-feature-1
- 如果您的拉取请求获得批准,则更改将被合并
source/master
(origin/master
也)。
- 执行从
origin/master
(或source/master
)到的合并origin/my-dev
。
- 就分支的生命周期而言,我通常倾向于在将其合并到上游之后摆脱短暂的主题或特性分支(分支只是 git 中引用某个提交的轻量级指针)。
一遍又一遍地重复这个工作流程。
关键思想是你的拉取请求不应该对上游维护者造成任何严重的冲突,否则他/她会盲目地拒绝贡献。
当您想从上游做出贡献时D2
,我已经举例说明了一个示例。和是和的变基版本。提交是上游提交,是您的下游提交。带后缀的是合并。D3
origin/my-dev
D2'
D3'
D2
D3
U
source
D
origin
M
从视觉上看,这就是它的样子:
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
| |
| |