I have 2 separate develop branches in Git, develop1 and develop2. These 2 branches have a common ancestor, commit C1 on master. These 2 branches contain 2 product releasecycles will will be joined in about 6 months (both merged into master).
Before the big merge in 6 months, branches develop1 and develop2 will be kept separate, no merging between develop1 <-> develop2 will be done.
However, some changes (like project structure, script changes) will be done on both branches.
My idea is to perform these changes on develop1, then cherry-pick them to develop2.
My questions:
The reason I'm asking this is because I've read that cherry-picking may result in problems because new commits are created.
One reference listing the possible problem: http://blog.founddrama.net/2013/07/git-cherry-pick/
I ma always referring to the same issues with cherry-picking (as in "git - cherry-pick - HOWTO / WHYTO")
The second issue is not relevant here, as you are chrry-picking only commits that work on their own and are tested/validated on the second branch well before they are merged on master.
But the first one can be an issue when develop1, then develop2 will be merged to master. The merge itself should be fine.
But, as explained in "Git cherry pick and datamodel integrity", a change will appear twice in the history of a merged commit.
If possible, once develop1 is merged to master, I would rebase develop2 on top of an updated origin/master, before merging develop2 back to master: that would detect identical commits and not apply them twice.