Maintaining git branches with different file organization

问题

I am working on a project that I deploy both on gh-pages and as an android application using cordova/phone gap.

http://github.com/derekmc/html-sandbox

Currently, the code for both deployments is very similar and maintaining separate branches has not been a problem.

However, I recently tried to create a deeper file organization, but phonegapbuild didn't include the files from subdirectories.

I am afraid that to get this to work I am going to have to organize the files in the two branches differently, and move everything in the phonegap branch into a www folder.

I'm not a git expert, but in researching the problem, it appears this will complicate merging between the two branches.

All I found was this question: git merge: apply changes to code that moved to a different file

Is there a practical way to maintain parallel branches with different file organization? What would be the best way to do this?

Is there something I could do to keep the file organization of the two deployments the same?

回答1:

Maintaining different layouts may be partially addressed the answer to the question Why doesn't git attempt to merge changes to renamed files? .

"The default merging strategy merges only the final results, not each commit"

Presumably its just a matter of selecting the appropriate merge strategy?

回答2:

You could—I wouldn't, but you could—take the approach that merges are always done from, to, and with a "canonical form" of the tree. (Incidentally, a modified version of this, "canonicalizing" end of line attributes, is what the merge configuration control merge.renormalize is for. There's no equivalent for file names, unfortunately.)

That is, you would make sure that the merge base of any two commits to be merged is always the canonical layout (this will fall out naturally from regular merges, but you will have issues if you ever want to cherry pick a commit). Then, before doing a merge, you would check out each branch, modify the tree to put it into canonical form, and commit. This means that if we draw the graph of commits to be merged:

          o--o--o--A   <-- branch1
         /
...--o--*
         \
          o--o--B      <-- branch2

then the merge base * has the canonical layout, and commit A has the canonical layout, and B has the canonical layout, and Git can simply merge all the files by their canonical names. Let's say the merge goes onto branch2:

          o--o--o--A       <-- branch1
         /          \
...--o--*            \
         \            \
          o--o--B------M   <-- branch2

Now you check out both branches and "de-canonical-form" them if necessary:

          o--o--o--A----o     <-- branch1
         /          \
...--o--*            \
         \            \
          o--o--B------M--o   <-- branch2

and you're ready to continue using them. The future merge base will be commit A, which as we just saw/made, is in "canonical form".

(If the canonical form of the tree matches the form in some branches, those branches do not need transformative pairs applied around merges.)

In practice, we never¹ need to do this kind of silliness, as all² build systems can deal with layout sensibly, or—as jthill suggested in a comment—can be tricked into it.

---

¹"What, never?"

²"What, all... oh never mind." "What, never?"

来源：https://stackoverflow.com/questions/29569299/maintaining-git-branches-with-different-file-organization