git - fork on github, then how do I manage my contributions? -

i'm little unclear on forkflow follow fork on github.

what if have several small independent fixes of various bugs in original repository, of medium-sized project, say, opengrok?

• do create separate branches each relatively small unrelated bugfix?

• do create each branch master, or branch 1 unrelated branch next?

• do commit fixes master?

i mean, on time, still want preserve history , all, i'm afraid after while there'll complete mess in regards lot of meaningless branches relatively minor bug fixes.

i plan contribute number of non-related fixes given project, , trying planning of development approach.

there several possible workflows when forking project on github , plan submit changes upstream. 1 of workflows tend follow (i'm going call repo i've forked remote source , repo origin):

• fork main branch used source, let's master origin/my-dev.
• origin/mydev changes , main development go.
• i regularly rebase remote/master onto origin/master (this step redundant easy me have in 1 remote).
• merge either source/master or rebased origin/master origin/my-dev whenever want pick changes upstream.
• if submit patch or bugfix upstream, start new feature branch use pull-request. i'll call origin/my-feature-1. create branch off upto date origin/master (or source/master)
• i cherry-pick changes feature i've made in origin/my-dev origin/my-feature-1. perform testing after step.
• submit pull request origin/my-feature-1
• if pull-request gets approved, changes merged source/master (and origin/master too).
• perform merge origin/master (or source/master) origin/my-dev.
• as far lifetime of branches go, tend rid of short-lived topic or feature branches after i've merged upstream (branches lightweight pointers in git referencing commit).

keep repeating workflow on , over.

the key idea pull-request should not pose serious conflicts upstream maintainer or he/she going blindly reject contribution.

an example i've illustrated, when want contribute d2 , d3 origin/my-dev upstream. d2' , d3' rebased versions of d2 , d3. commits u upstream commits in source, d downstream commits in origin. ones m suffix merges.

visually like:

source/master             origin/my-dev      u1      u2   initial-fork      u3-----------\      |             \      |              \------------d1      |                           d2      u4 sync 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      |                           |      |                           |