I am trying to reorganize GIT repository, which is full of unorganized branches. Now we want to make some structure there (devel, production, features, ...branches) and delete/squash many small changes too. But something is needed to keep yet as it is, as there are people working on it.
So I created the big structure, squashed old things together (nobody longer interested in small typo fixes years old) and basically fixed everything to begin of this year.
But now the problem came - some branches are active, cannot be squashed fully, cannot be deleted/moved (until new schema proves to work for some time) and contains a lot of small merges inside, like this:
jacks_branch
A-B-C-F-G-H-I-J-M-N-O-P ...
\D-E/ \K-L/
I would like to COPY this on top of appropriate feature branch, like
feature_123
XX-YY
=>
XX-YY-C'-F'-G'-H'-I'-J'-M'-N'-O'-P' ...
\D'-E'/ \K'-L'/
(the schema is more complicated, this is the problematic part)
I would like to do something like
git checkout feature_123
git cherry-pick C..P
but it results on conflict on all those merges
error: could not apply E
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
the I commit (merge) solves all those conflicts, but it is not applied and cherry-picking stops
What is the best way out (except having it good organized from the start) ?
Edit - added example:
I have
* 3b0a2b4 3.line Adam (HEAD, Adam)
* c04efb0 Just fixed merge from other computer
|\
| * 3e5f111 2.line Adam_a
* | 897bfc3 2.line Adam_b
|/
* 308a3c5 1.line Adam
* 33f3119 === new year ==== (master)
* 436619b 1000.line
.............
* 0a12c01 4.line
* 41d763d 3.line
* dd1feb0 2.line
* 55aa2c2 1.line
* 84b12e9 Point zero
Please see, that the branch Adam have conflict in it (3e5f111 and 897bfc3 adds respectively line Adam_a and Adam_b to the same place), which the developer Adam somehow solved in c04efb0 (by writing there something totally different, like Adam_* # it does not matter or so)
and I want to add new branch develop - that is easy squash of master
* 75675e1 === new_year === squashed 1.000 lines (HEAD, develop)
* 84b12e9 Point zero
and now I want to add branch feature_1 (over develop) with content from Adam (but not have to manually solving all those already solved conflicts, I want the merge (4444567) be just the same as on branch Adam)
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|\
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
* 84b12e9 Point zero
to get this:
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|\
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
| * 3b0a2b4 3.line Adam (Adam)
| * c04efb0 Just fixed merge from other computer
| |\
| | * 3e5f111 2.line Adam_a (Adam_a)
| * | 897bfc3 2.line Adam
| |/
| * 308a3c5 1.line Adam
| * 33f3119 === new year ==== (master)
| * 436619b 1000.line
| * 0a12c01 4.line
| * 41d763d 3.line
| * dd1feb0 2.line
| * 55aa2c2 1.line
|/
* 84b12e9 Point zero
(and later I will delete Adam and master )
I think that rather than trying to rewrite history, you (and your team) should focus now on using the workflow you want to use going forward. That brings me to my next point, which is that if you move forward with a particular git workflow while other members of your team continue to use your current one, you will probably not be successful.
Assuming that the various branches in your repository have not diverged too much, you and your team should start merging and consolidating towards whatever you want your repository to look like, e.g. a master branch and feature branches.
Rewriting history (e.g. with a rebase) is tricky because it means that every commit since the one you're modifying or squashing must also be rewritten, which means that your new versions of those commits no longer match everyone else's "old" versions. When used sparingly on recent history, it can be useful, but rewriting the history of an entire repository and expecting to reconcile that with active development is not something I would ever attempt.