我正在做一个项目，我将该项目部署在gh页面上，并使用cordova/phone gap作为android应用程序。
http://github.com/derekmc/html-sandbox
目前，这两种部署的代码非常相似，维护单独的分支并不是问题。
然而，我最近尝试创建一个更深层次的文件组织，但phonegapbuild没有包含子目录中的文件。
我担心要想让它发挥作用，我将不得不以不同的方式组织两个分支中的文件，并将phonegap分支中的所有内容移到www文件夹中。
我不是git专家，但在研究这个问题时，这似乎会使两个分支之间的合并变得复杂。
我发现的只是这个问题：gitmerge：将更改应用于移动到不同文件的代码
有没有一种实用的方法来维护具有不同文件组织的并行分支？最好的方法是什么？
我能做些什么来保持两个部署的文件组织不变吗？
维护不同的布局可能部分解决了为什么不；t git尝试合并对重命名文件的更改。
"默认的合并策略只合并最终结果，而不是每次提交">
这大概只是选择合适的合并策略的问题吧？
你可以——我不会，但你可以——采取的方法是，合并总是从、到，并使用树的"规范形式"。(顺便说一句，合并配置控件merge.renormalize的作用是对其进行修改，"规范化"行尾属性。不幸的是，没有等效的文件名。)
也就是说，您应该确保要合并的任何两个提交的合并基础始终是规范布局(这将从常规合并中自然脱落，但如果您想要挑选一个提交，则会遇到问题)。然后，在进行合并之前，您将检查出每个分支，修改树使其成为规范形式，然后提交。这意味着，如果我们绘制要合并的提交的图形：
o--o--o--A <-- branch1
/
...--o--*
o--o--B <-- branch2
则合并基*具有规范布局，提交A具有规范布局、B具有规范布局。Git可以简单地按规范名称合并所有文件。假设合并进入branch2:
o--o--o--A <-- branch1
/
...--o--*
o--o--B------M <-- branch2
现在，您可以检查这两个分支，并在必要时对其进行"去规范化形式"：
o--o--o--A----o <-- branch1
/
...--o--*
o--o--B------M--o <-- branch2
并且您已准备好继续使用它们。未来的合并基础将是提交A，正如我们刚刚看到/制作的，它是"规范形式"。
(如果树的规范形式与某些分支中的形式匹配，则这些分支不需要在合并周围应用转换对。)
在实践中，我们从来没有1需要做这种愚蠢的事情，因为所有2构建系统都可以明智地处理布局，或者——正如jthill在评论中所建议的那样——可以被欺骗
1"什么，从来没有？">
2"什么，都…哦，没关系。"什么，从来没有？">