维护具有不同文件组织的git分支 [英] Maintaining git branches with different file organization

问题描述

我正在开发一个项目，该项目可以使用cordova/phone gap作为gh-pages和Android应用程序进行部署.

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.

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

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

恐怕要使它正常工作，我将不得不以不同的方式组织两个分支中的文件，并将phonegap分支中的所有内容移动到www文件夹中.

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.

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

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

我发现的只是这个问题: git merge:将更改应用于代码移到了另一个文件

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?

推荐答案

您可以-我不会，但是您可以-采用始终从，到，并与树的规范形式". (顺便说一句，合并配置控件merge.renormalize的目的是对行末尾属性进行规范化"修改.不幸的是，文件名没有等效项.)

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

然后合并基础*具有规范的布局，提交A具有规范的布局，而B具有规范的布局，Git可以简单地按其规范名称合并所有文件.假设合并进入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

，您就可以继续使用它们了.将来的合并基础将是提交A，正如我们刚刚看到/制作的那样，它是规范形式".

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, all... oh never mind." "What, never?"

这篇关于维护具有不同文件组织的git分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！