1

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

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

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

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

4

3 回答 3

1

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

不，没有分支会消失

与固件相关的更改 ( WP7→ WP8) 可能会被覆盖

首先 ，尝试WP8在master.
也就是说，尝试WP8 在上面应用master（参见merge vs. rebase）。
正如Gary Fixler 在下面评论的那样，这对于历史较短的分支是有意义的（否则，在最近的工作之上重新应用非常旧的提交可能会很麻烦，而且历史也没有意义）。

我只提出变基，因为合并master到任何其他分支被认为是不好的做法（这被称为“反向合并”，并使Adam Dymitruk生气；））。

您应该使用Feature 分支，然后您可以将其合并到和master分支。 这利用了 git 提供的易于分支的优势，并且只保留了代码的稳定状态：任何进一步的演变都应该在功能分支中完成（然后合并到），而不是在（导致“从另一个分支向后合并” ，这是不好的做法）WP8
mastermaster mastermastermaster

更多关于 Adam 的文章“ Branch Per Feature ”。

关于配置文件，您还可以将值存储在单独的文件中，并使用模板文件构建具有正确值的正确配置文件，具体取决于您所在的分支。
请参阅“处理项目配置文件最简单的方法是什么？ ”。

这样，您希望对于那些在不同分支中具有不同内容的文件有任何合并问题，因为它们的值存储在不同的文件中。

于 2013-05-04T09:37:50.377 回答
1

您可以使用分支或文件夹来解决这个问题，但它是子模块的主要候选 IMO。我用它们来做这些事情。这是一组 3 个 repos 的示例：

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中，这是一个裸版本。现在您可以从任git subdmodule add path/to/common optional_folder_name一 wp repo 中执行（如果您未指定，它使用 repo 文件夹名称）。这有效地将公共 repo 克隆到每个 wp repo 内的文件夹中。这些也可以是单个 repo 的分支；您只需在每个分支上添加子模块即可。

子模块比分支稍微多一些维护，但它们做了一些分支不能做的事情。它们在您的存储库中为您提供了平行的开发线。当您在任一 wp 存储库中的公共存储库中进行更改时，您将其提交到那里，您可以将其推送回外部的、裸露版本的 common，然后将其拉到另一个 wp 存储库的公共存储库中。它只是一个常规的 repo，但它的克隆存在于 wp repos 中。在您的 wp 存储库中，您将通过首先检查公共存储库中的正确提交，然后在 wp 存储库外部执行git add commonand来告诉它您现在想要哪个版本git commit -m'Update common for feature X'。这会在 wp 存储库中创建一个提交，该提交仅将提交的哈希存储在公共子模块中。

当您稍后在 wp 存储库中签出此提交时，它将签出 wp 代码，以及公共存储库中的适当提交。基本上，您可以跟踪特定时间的通用回购版本。这很好，有几个原因。一方面，如果您不想要或不需要它，您不必在特定的 wp 存储库中获得最新的共同点。这也意味着您实际上可以在任一公共 repo 中检出较旧的提交，添加它，然后在该 wp repo 中提交它，然后根据需要对旧提交进行处理。不过，这需要做更多的工作，而且您必须记住在 wp 和 common repos 中一起工作。我每天都这样做，但我听很多人说这太麻烦了。

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

于 2013-05-04T10:12:44.813 回答
0

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

分支是同一事物在不同开发阶段的版本。如果你合并一个分支，git 将尝试将所有更改从一个移动到另一个。没有简单的方法可以仅将与架构无关的更改从一个分支移动到另一个分支。

最好的情况是你可以为两者建立一个分支。共享可以共享的文件，并将项目特定的东西存储在单独的目录中，例如arch/wp7和arch/wp8.

于 2013-05-04T09:45:59.620 回答