Question

我正在开发一个项目，我在gh-pages上部署，并使用cordova / phone间隙作为Android应用程序。

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

目前，两个部署的代码非常相似，维护单独的分支并不是问题。

但是，我最近尝试创建一个更深层次的文件组织，但phonegapbuild没有包含子目录中的文件。

我担心要让它工作，我将不得不以不同方式组织两个分支中的文件，并将phonegap分支中的所有内容移动到www文件夹中。

我不是git专家，但在研究这个问题时，似乎这会使两个分支之间的合并变得复杂。

我发现的只有这个问题： git merge: apply changes to code that moved to a different file

是否有实用的方法来维护具有不同文件组织的并行分支？最好的方法是什么？

我能做些什么来保持两个部署的文件组织相同吗？

Answer 1

维护不同的布局可以部分解决问题Why doesn't git attempt to merge changes to renamed files?的答案。

“默认合并策略仅合并最终结果，而不是每次提交”

大概只是选择合适的merge strategy？

Answer 2

你可以 - 我不会，但是你可以采取合并的方法总是从树的“规范形式”完成。（顺便提一下，这个“规范化”行结束属性的修改版本是合并配置控件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，正如我们刚刚看到/制作的那样，是“规范形式”。

（如果树的规范形式与某些分支中的形式匹配，那些分支不需要在合并周围应用变换对。）

在实践中，我们从不¹需要做这种愚蠢，因为所有²构建系统都可以合理地处理布局，或者作为jthill suggested in a comment - 可以欺骗它。

¹ "What, never?"

²“什么，所有......哦，没关系。” “什么，永远不会？”

使用不同的文件组织维护git分支

2 个答案: