CODEWITHSUNDEEP
gitgithubgit-branch
cnst
cnst

Reputation: 27218

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

I'm a little unclear on the forkflow that is to follow a fork on github.

What if I have several small independent fixes of various bugs in the original repository, of a medium-sized project, say, OpenGrok?

I mean, over time, I still want to preserve the history and all, but I'm just afraid that after a while there'll be a complete mess in regards to a lot of meaningless branches for relatively minor bug fixes.

I plan to contribute a number of non-related fixes for a given project, and trying to do some planning of the development approach.

Upvotes: 5

Views: 945

Answers (1)

Tuxdude
Tuxdude

Reputation: 49473

There are several possible workflows when forking a project on github and you plan to submit changes upstream. This is one of the workflows I usually tend to follow (I'm going to call the repo from which I've forked as the remote source and my repo as origin):

  • Fork the main branch used by source, let's say master into origin/my-dev.
  • origin/mydev is where all my changes and main development go.
  • I regularly rebase remote/master onto origin/master (this step is redundant but sometimes it is easy for me to have everything in one remote).
  • Merge either source/master or the rebased origin/master into origin/my-dev whenever you want to pick up changes from upstream.
  • If I would like to submit a patch or a bugfix upstream, I would start a new feature branch that I could use for the pull-request. I'll call it origin/my-feature-1. I create this branch off an upto date origin/master (or source/master)
  • I cherry-pick the changes for this feature that I've made in origin/my-dev into origin/my-feature-1. Perform any testing after this step.
  • Submit a pull request from origin/my-feature-1
  • If your pull-request gets approved, the changes would be merged into source/master (and origin/master too).
  • Perform a merge from origin/master (or source/master) into origin/my-dev.
  • As far as the lifetime of the branches go, I usually tend to get rid of the short-lived topic or feature branches after I've merged it upstream (Branches are just lightweight pointers in git referencing certain commit).

Keep repeating this workflow over and over.

The key idea is that your pull-request should not pose any serious conflicts for the upstream maintainer or he/she is going to blindly reject the contribution.

An example I've illustrated, when you want to contribute D2 and D3 from origin/my-dev upstream. D2' and D3' are rebased versions of D2 and D3. Commits with U are upstream commits in source, D are your downstream commits in origin. The ones with the M suffix are merges.

Visually this is what it would look like:

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
     |                           |
     |                           |

Upvotes: 4

Related Questions