我对于在github上跟随fork
的forkflow有点不清楚。
如果我在原始存储库中有一些针对各种错误的小型独立修复,如中型项目,比如OpenGrok怎么办?
我是否为每个相对较小的无关错误修复程序创建单独的分支?
我是否从master
创建每个分支,还是可以从下一个分支一个不相关的分支?
我是否将修正提交到master
?
我的意思是,随着时间的推移,我仍然希望保留历史记录和所有内容,但我只是害怕在一段时间之后,对于相对较小的错误修复,很多无意义的分支将会完全混乱。
我计划为给定项目贡献一些不相关的修复程序,并尝试对开发方法进行一些规划。
答案 0 :(得分:4)
在github上分支项目时,有几种可能的工作流程,并且您计划在上游提交更改。这是我通常会遵循的工作流程之一(我将调用我作为远程source
和我的仓库作为origin
分叉的仓库):
source
使用的主分支,假设master
为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
的合并。一遍又一遍地重复此工作流程。
关键的想法是,你的拉动请求不应该对上游维护者构成任何严重的冲突,或者他/她将盲目地拒绝该贡献。
我想说明的一个例子,当你想从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
| |
| |