如何使用github，分支机构和自动发布进行版本管理？[关闭]

到目前为止，我已经了解了大多数基本的Git / Github概念，但是仍然很难理解全局。

到目前为止，我已经设法使这些事情起作用：

• 推送提交
• 与分支机构合作
• 将Github与Travis CI（一个持续集成系统）集成
• 通过Travis CI，可以自动构建对master的每次提交，并将该发行版作为ZIP放在Github上的发行版之下。

但是到目前为止，我只从事项目的alpha / beta版本工作，因此我还从未见过实践中的版本发布。

因此，我想了解更多有关版本控制，维护单独的版本，修复版本等信息。

我将如何确保发生以下情况：

• 我的项目有不同的版本，例如版本1.1.0和2.0.0
• 能够在版本上推送修补程序，将版本提高到1.1.1或2.0.1，等等。
• 使一个持续集成系统在提交时自动构建该版本，如果成功，则发布该特定版本的发行版。

我怀疑以下选项之间：

• 每个版本都需要使用标签吗？如果是这样，一个持续集成系统如何构建自动发布？
• 我应该为每个版本创建分支吗？如果是这样，那将不会创建大量的分支（例如1.1和2.0分支，修补程序当然会进入该分支）
• 我将如何指定版本号？是否可以使用一个指定版本号的配置文件，还是可以使用更智能的方法？在这种情况下，这很重要，这将是一个Java项目。

您应该看看git-flow。这是一个出色的（且受欢迎的）分支模型。

Git流摘要

分枝

永远存在的主要树干是develop和master。master拥有您的最新版本并develop拥有您的最新“稳定”开发副本。

贡献者根据以下条件创建feature分支（feature/按惯例前缀）develop ：

$ git checkout -b feature/my-feature develop

和hotfix分支（hotfix/按惯例前缀）master：

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

这些分支是“一次性的”，这意味着它们在合并回主干之前的寿命很短。它们旨在封装一些小的功能。

整理分支

当贡献者完成 feature分支后，他们将其合并回develop：

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

完成hotfix分支后，将其合并回两个分支中master及develop因此修复怀揣着：

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

这是持续集成方面。

发布

准备开始打包发行版时，可以release从“稳定” 创建分支develop分支创建分支（与创建feature分支相同）。然后，您可以在标签中添加版本号（如下所述）。

使用单独的release分支可以使您继续开发新功能，develop同时修复错误并为功能添加最后的修饰。release分支。

当您准备好完成发行时，可以将release分支合并到master和中develop（就像一个hotfix），以便所有更改都可以继续进行。

标记

创建release分支或hotfix分支时，可以在标记中适当地改变版本号。使用香草git，看起来像这样：

$ git tag -a <tag-name> -m <tag-description>

然后，您还必须将标签（分别）推送到远程存储库：

$ git push --tags

通常最好使用语义版本，其中版本采用形式major.minor.hotfix。主要颠簸是向后不兼容的，而次要和修补程序颠簸不是向后不兼容的（除非您处于测试版，0.x.x）。

合并中

如上所述，git-flow鼓励您使用以下命令合并分支：

$ git merge --no-ff <branch-name>

的 --no-ff选项使您可以维护所有分支历史记录，而不会在存储库的当前提交中留下一堆分支（因此，不用担心，您不会为每个版本都拥有一个分支）。

我们也鼓励您与

$ git pull --rebase

因此，您不会添加很多无用的合并提交。

您可以将git配置为在您的默认情况下同时执行这两项操作 .gitconfig。不过，我会让你看一眼;）

浏览版本

当某人正在寻找特定版本的代码库时，他们可以按名称签出标签：

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

或者，如果有人在github上浏览，则“分支”下拉菜单中还会有一个“标签”标签。

使用git-flow扩展名（推荐）

我最喜欢的使用此模型的方法是使用git flow扩展。

（编辑： Louis推荐了AVH前叉，它可以更好地git describe工作，现在可能会更活跃。谢谢Louis。）

该扩展程序可自动执行所有混乱的部分（例如merge --no-ff合并后使用和删除分支），以便您继续生活。

例如，使用扩展名，您可以创建一个功能分支，如下所示：

$ git flow feature start my-feature-name

像这样完成它

$ git flow feature finish my-feature-name

修补程序和发行版的命令类似，尽管它们使用版本号代替分支名称，如下所示：

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

然后，Git flow为您创建版本标记，并提醒您在任何配置或清单文件中更改版本（可以使用任务管理器（如grunt）来完成）。

希望能对您有所帮助：）我不确定您如何将其与Travis CI设置完全集成，但是我猜githooks可以帮助您。

每个版本都需要使用标签吗？

不，你不需要使用标签。如果您想标记每个发行版，那很好，或者如果您想标记每次构建CI系统的时间，也可以这样做。标记实际上只是为提交赋予用户友好的名称，因此您可以轻松地将其上拉并稍后查看。

我应该为每个版本创建分支吗？

当然！在Git中分支是便宜/免费的，因此我每有机会就利用它。您还可以相当快地合并和删除分支。如果您认为您需要许多分支，则可以随时通过选择性合并将它们缩减。如果您想使用久经考验的真实方案，也可以使用大量的Git分支方案。

我将如何指定版本号？

标签通常是您指定版本号的方式，因为它与git有关。如果您正在谈论如何对项目进行版本控制或执行此操作的最佳方法，则必须进行一些挖掘，因为这是一个非常基于意见的问题。有些项目会永远保留在Beta版中，而其他项目则会增加整数版本，就像它们过时了一样（看着您chrome）

每个版本都需要使用标签吗？

如果用“版本”来表示一组构成发行版或候选发行版的文件，那么我强烈建议标记每个版本。如果您需要一路参考版本1.2.7，是要查找提交的哈希还是仅使用版本号？

同样，如果您git describe习惯于在某个地方记录构建信息（如我所做的那样），那么使用标签可以使其提供更好的输出。

如果是这样，一个持续集成系统如何构建自动发布？

持续集成系统可以构建发行版，无论您如何使用标签。您可以告诉它基于提交的哈希值构建发行版。标签使您的生活更轻松。

我应该为每个版本创建分支吗？如果是这样，那将不会创建大量的分支（例如1.1和2.0分支，修补程序当然会进入该分支）

我不认为分支是“每个版本”的事情。我有几个项目，所有版本都在master分支上提交。我现在不需要比这更复杂的东西，因为没有一个项目处于稳定阶段，也不需要长期支持较旧的版本。但是，假设我发布了1.0、1.1、1.2，然后发布了2.0，但我仍然必须通过安全修复程序来支持1.0系列，等等。然后我肯定会有一个分支来发布1.x系列的维护版本。 。

我将如何指定版本号？是否可以使用一个指定版本号的配置文件，还是可以使用更智能的方法？在这种情况下，这很重要，这将是一个Java项目。

最好使用单一版本号源（例如配置文件），因为它可以防止如果必须在多个位置更新版本号时可能会发生的粗线错误。我是从...嗯...令人尴尬的经历。您发布1.3只是发现该软件仍报告它是1.2版。糟糕！

在另一个答案中，mxdubois向您推荐了gitflow。如果您决定使用gitflow，建议您使用AVH版本。原始版本不再有效维护。一个显着的区别是AVH版本执行允许git describe智能工作的发行合并。原始版本以跳闸git describe的方式执行合并。

正在扫描您的列表，我将版本视为重点，因此...

维护版本的一种方法是使用分支和合并（或重新定级）。

所以你有了：

master

然后创建一个分支

v1

然后您将更多更改添加到

master(diff1)

然后创建一个分支

v3

然后您将更多更改添加到

master(diff2)

现在：

现在要更新版本2

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

更新版本3

git checkout v3
git merge master

以上是批发更新。

尽管您可能会希望针对其中存在的特定变化进行选择，但很有可能

git cherry-pick

有关樱桃采摘的更多信息，请访问http://git-scm.com/docs/git-cherry-pick