cns*_*nst 5 git github git-branch
我有点不清楚接下来的叉流fork。
如果我对一个中型项目(例如 OpenGrok)的原始存储库中的各种错误进行了几个小的独立修复,该怎么办?
我是否为每个相对较小的不相关的错误修复创建单独的分支?
我是否从 中创建每个分支master,或者我可以从下一个分支中分支一个不相关的分支吗?
我是否将修复提交到master?
我的意思是,随着时间的推移,我仍然想保留历史和所有内容,但我只是担心一段时间后,对于相对较小的错误修复来说,许多无意义的分支会变得一团糟。
我计划为给定的项目提供一些不相关的修复,并尝试对开发方法进行一些规划。
在 github 上分叉项目并且您计划向上游提交更改时,有多种可能的工作流程。这是我通常遵循的工作流程之一(我将把我分叉的仓库称为远程仓库,将source我的仓库称为origin):
source,假设master进入origin/my-dev。origin/mydev这是我所有更改和主要开发的地方。remote/master(origin/master这一步是多余的,但有时我很容易将所有内容都放在一个遥控器中)。source/master或重新基合并origin/master到。origin/my-devorigin/my-feature-1。我根据最新的origin/master(或source/master)创建了这个分支origin/my-dev放入origin/my-feature-1. 在此步骤之后执行任何测试。origin/my-feature-1source/master(并且origin/master)。origin/master执行从(或source/master) 到 的合并 origin/my-dev。不断重复这个工作流程。
关键的想法是你的拉取请求不应该对上游维护者造成任何严重的冲突,否则他/她将盲目地拒绝贡献。
我举了一个例子,当你想从上游D2做出贡献时。和是和的重新基版本。的提交是 中的上游提交,是 中的下游提交。带后缀的是合并。D3origin/my-devD2'D3'D2D3UsourceDoriginM
从视觉上看,它是这样的:
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
| |
| |
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
897 次 |
| 最近记录: |