1

我最近开始开发一个新库，并使用 Git 进行版本控制。我决定关注广受欢迎的博客文章A successful Git branching model来管理分支。现在是我发布第一个版本的时候了，我想要一些关于管理特定文件集的建议，如下所述。

在开发分支和功能分支上，我想要所有的“支持文件”，例如用于编译的 makefile 和 doxygen 用于生成文档的 readme.md 文件。（请注意，这些只是几个示例。我还有更多“支持文件”。）

博客文章还说，提交到 master 分支是定义上的发布。我希望该版本包含所有“二进制文件”（例如，包括编译产生的目标文件和包含文档的 html 文件）。这些文件应该提交到主分支，以便客户可以从带有标签的存储库中克隆并获得所需的版本。

我不想在版本中包含“支持文件”（因为我不想给客户一堆他们不想要或不能使用的文件）。同样，我不希望在开发和功能分支中对“二进制文件”进行版本控制。因此，我想提交一组文件来开发，另一组文件来掌握。（当然，还有一组文件对两个分支都是“通用的”。）但是，我对保持主分支和开发分支不同步持怀疑态度，就像刚才描述的那样。

我提出的模型听起来不错吗？如果是这样，我应该如何处理提交开发和掌握的不同文件？有没有更好的方法来处理这种情况？

我浏览了上述博客页面上的每一条评论，搜索了互联网，也在 StackOverflow 上搜索了这里。从搜索结果来看，这个带有一些不同文件的帖子 GIT 存储库似乎是唯一一个接近我的问题的地方。这些都没有帮助我找出解决方案。

4

2 回答 2

1

IMO 提出的解决方案并不好。您的问题的常见解决方案是：

  • 版本控制所有“支持文件”。如果您关心这些文件是否被修改或删除，那么它们应该受版本控制
  • 不要对“二进制文件”进行版本控制，如果它们只是由编译过程生成的话。编译的代码和 Makefile 是最重要的。如果它们用于编译代码，您可能会在“bin”文件夹中包含二进制文件。
  • 围绕要交付给客户端的包创建构建过程。您可以为他们可以访问的客户端构建一个包，或者您可以让他们自己运行您的“包脚本”。“包脚本”只需在命令行上执行即可克隆 repo、构建包和删除 repo。

要了解有关 git 分支模型以及它们如何应用于开发的更多信息，请查看http://git-scm.com/book/en/Git-Branching

于 2012-11-24T16:52:14.727 回答
1

使用 git-flow，主分支包含最新版本的提示，该语句中的缺陷是当您处理需要编译的软件时。

在这种情况下，主分支是您从中创建实际版本的源版本分支。如果您根据定义查看分支模型，您还需要主分支中的所有支持文件。这样，您始终可以创建最新版本的二进制文件。

在您的情况下，您说您不希望客户拥有一堆他们不需要的文件，这意味着您在发布后需要一些额外的工作。在 git-flow 术语中，完成 git flow 发布后，您需要执行额外的步骤来编译您的发布。编译结果不应受修订控制。使用原始的 git-flow 软件，您需要手动启动编译过程，如果您使用我的 fork，git-flow (AVH 版)，您实际上可以使用钩子自动完成此操作。

我愿意说 github 上 99% 的需要某种编译的项目的所有支持文件也都在 master 分支中。

于 2012-11-24T19:03:29.810 回答