使用git开发“多渠道”开发

Question

我正在为Windows Phone开发一个应用程序，使用SDK版本7.1（适用于WP7）并将其托管在git仓库中。为了使它在具有更高分辨率的Windows Phone 8设备上可用，我创建了一个分支WP8，其中我转换了Visual Studio项目并对代码进行了一些必要调整。

现在我继续开发master，我想更新WP8分支的功能相关更改。我首先想到的是merge这些分支，但我担心两个可能的问题：

1. 当使用 merge，一个分支会消失。 （不正确）
2. 固件相关更改（WP7→WP8）可能会被覆盖。

git是否有适当的方法来开发几个不同的（但相似的）目标SDK依赖于大量相同的代码？

Answer 1

当使用合并时，一个分支将消失。

没有，没有分支会消失

固件相关的更改（WP7→WP8）可能会被覆盖

首先，尝试宁可rebaseWP8上的master顶部。
也就是说，尝试应用WP8顶部的master（见merge vs. rebase）。
作为Gary Fixlercomments below，这对于历史较短的分支是有意义的（否则，在最近的工作之上重新应用非常陈旧的提交可能是麻烦的，并且历史没有意义）。

---

我只带了底垫中，因为它被认为是不好的做法，合并master任何其他分支（这被称为“back merge”，使Adam Dymitruk生气;））。

您应该使用Feature branches，然后你就可以合并master，和到WP8分支。
这利用了容易通过的git提供的分支，并留下master只用代码的稳定状态：任何进一步进化master应该在一个特性分支进行（再合并到master），而不是在master（导致从master“反向合并”到另一个分支，这是不好的做法）

查看更多关于亚当的文章“Branch Per Feature”。

---

关于配置文件，也可以存储值分隔的文件，并使用模板文件来建立正确的配置文件与正确的价值观，这取决于分支你。
请参阅“What's the easiest way to deal with project configuration files?”。

这样，你就想对不同分支中具有不同内容的文件产生任何合并问题，因为它们的值存储在不同的文件中。

Answer 2

固件相关更改（WP7→WP8）可能会被覆盖。

分支机构旨在成为不同发展阶段中相同事物的版本。如果你合并了一个分支，git会尝试将所有更改从一个移到另一个。没有简单的方法可以将与架构无关的更改从一个分支移动到另一个分支。

最好的情况是，你可以得到一个分支来构建两者。共享可共享的文件，并将项目特定的内容存储在不同的目录中，如arch/wp7和arch/wp8。

Answer 3

您可以通过分支机构或文件夹逃避这一点，但它是子模块的主要候选国际海事组织。我用它们来做这种事情。下面是一组3个回购的例子：

common/ (bare repo of common files) 
    .git/ 

wp7/ (regular repo of wp7 specifics) 
    .git/ 
    common/ (submodule) 

wp8/ (same as wp7, but for wp8) 
    .git/ 
    common/ (submodule) 

为了使常见的一种，你会只是采取正规回购和git clone --bare repo optional_bare_repo_name。如果你不给它一个名字，它会将common克隆到一个名为common.git的文件夹中，该文件夹是裸露的版本。现在你可以从wp repo内git subdmodule add path/to/common optional_folder_name（它使用repo文件夹名称，如果你没有指定）。这有效地将常见的回购克隆到每个wp回购中的文件夹中。这些也可以是单个回购的分支;您只需在每个分支上执行子模块添加。

子模块比分支稍微维护一些，但他们做一些分支不能。他们在你的回购中给你一条平行的发展线。当你在wp repo中修改公共repo时，你在那里提交它，然后你可以将它推回到普通的外部版本，并在其他wp repo的常见库中拉下来。这只是一个普通的回购，但它的克隆存在于wp回购中。在你的wp仓库中，你可以通过首先检查普通仓库中的正确提交，然后在wp仓库外部做git add common和git commit -m'Update common for feature X'来告诉它你现在想要哪个版本。这会在wp repo中创建一个提交，它只将提交的散列存储在公共子模块中。

当您在以后的wp repo中签出此提交时，它将检出wp代码，并在常用的回购中进行相应的提交。基本上，您可以跟踪特定时间的常见回购版本。这很好，原因有两个。首先，如果你不需要或不需要它，你不必在特定的wp repo中获得最新的共同点。这也意味着你可以在普通的repo中签出一个较旧的提交，添加它，并将其提交到wp repo中，然后在需要的时候针对较旧的提交进行处理。尽管如此，还是要多做一些工作，并且你必须记得一起工作在WP和通用回购协议。我每天都这样做，但我听到很多人说这太麻烦了。

您还可以添加和提交一个特定版本的公共文件以及wp repo中的文件，例如，您可以进入并重构共同的东西，跳出并修复对wp7中重构的更改，然后添加通用并且wp7在wp7中一起更改并提交它们来跟踪这两个更改。现在，如果您回滚1次提交，常用回购也将回滚到重构之前，因此您可以在每次提交时都有正确运行的代码。