Techniques for selectively submitting to a main repo

Question

Say you have cloned a local repo from a remote open source project (on Github for example). You make changes in your local repo adding branches and so on.

You have in mind the following goal: some of the changes you make are for your own purposes and won't be contributed back to the main repo, other changes are of interest to the community such as bug fixes and feature adds and those you would like to contribute back to main repo.

So based on that let's assume two main branches: a dev-proj for all the changes, an a dev-comm with the subset to be contributed back to main repo.

In the general case you would know that a given set of changes would go into dev-comm or not, so you can isolate them into a branch.

However, there are tangled cases where you don't want your branching to be dictated by whether the changes should be contributed upstream or not.

Take for example the case of localization of a web application - changes in translation and views and so on. You create a branch for it and you intend to keep it private, but while working on it you find out that there are i18n issues with the original code, so you fix those as part of your work on this branch. And these changes WRT to i18n that you would like to isolate and push back to main repo.

My question is: is cherry-picking the best way to handle this situation - I'm concerned it would involve some distraction to try to granularize the commits, and what happens if I make by mistake a commit that involves a lump of private and community changes, then I would have to try to apply fixes for that. Or is there some better technique even if it involves some manual elements.

Edit: I'll clarify with a rough sketch: p is for local project and c is for changes meant specifically to be pushed upstream for the community:

                    Ep--Fc--Gp--Hc--Ipc(commit not granular!)--Jc topicA
                  /
   A--B--C devProj
       |
        \ Q--R devComm
                      |
                       \ Fc--Hc--I2c--Jc topicAcomm

While working on topicA, we don't want to be concerned about which parts are meant for the community. But at the end of it we would like to have something like topicAcomm that can be merged in devComm and pushed upstream.

My question is whether cherry-picking is the way to handle this, which seems to be a plausible way from checking the docs/tutorials. Or is there some other tricks like annotating the code later on maybe or some other tricks that I'm not aware of.

Having the accidental mingled commit is just one issue that could arise.

Answer 1

You can take some ideas from the original git branches management, also detailed in "gitworkflows Manual Page".

I would rather re-order the history of your topic branch in order to make merges to a public branch, rather than to rely on individual cherry-picking (which can prove problematic later: see "How to merge a specific commit in git")

Any rebase would force your team to reset his/her topic branch to the newly ordered topic branch, but that is more manageable than asking the community (much larger group of people) to reset anything.

One trick for automatic reordering is git rebase --interactive --autosquash which would reorder and group commits (see "Trimming GIT Checkins/Squashing GIT History".

Answer 2

Take a look at 'git rebase --onto ...'. For your example, think of it as two steps: 1) isolate your 'i18n' changes onto their own branch with 'rebase' and 2) merge that branch with dev-proj. From 'git help rebase', one of the examples:

If we have the following situation:

                                         H---I---J topicB
                                        /
                         E---F---G  topicA
                        /
   A---B---C---D  master

  then the command

       git rebase --onto master topicA topicB

   would result in:

                        H'--I'--J'  topicB
                       /
                       | E---F---G  topicA
                       |/
   A---B---C---D  master

Then from this you can merge topicB onto master (dev-proj) and back on topicB (dev-comm).