git 提交不同的文件集来开发和掌握答案

【问题标题】：git commit different set of files to develop and mastergit 提交不同的文件集来开发和掌握
【发布时间】：2012-11-24 16:08:28
【问题描述】：

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

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

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

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

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

我已经浏览了上述博客页面上的每一个 cmet，在互联网上搜索过，也在 StackOverflow 上搜索过这里。从搜索结果来看，这个帖子GIT repositories with some different files 似乎是唯一一个接近我的问题的帖子。这些都没有帮助我找出解决方案。

【问题讨论】：

标签： git version-control dvcs release-management git-flow

【解决方案1】：

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

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

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

【讨论】：

感谢您的回复。让我澄清一点。 “支持文件” 受版本控制。我只希望他们不致力于主分支。您是否建议“包脚本”应该有选择地从客户端的主节点签出特定文件（即跳过所有“支持文件”）？这可能是可行的，只是想澄清一下你是否是这个意思。
差不多了。我不知道使用 git 有选择地签出特定文件的方法。但这个想法是正确的，您可以在客户端过滤不需要的文件。我的 Web 开发世界中的一个示例是创建一个 Capistrano 脚本，该脚本在本地编译 scss 和 coffee 脚本文件，然后 scp 将它们发送到服务器。通过这种方式，您将您的回购与客户的需求分开，并将您的回购用于开发需求。我希望这能为您指明正确的方向。

【解决方案2】：

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

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

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

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

【讨论】：