首先，一些理论来证实实际建议。希望你不会觉得无聊。

一般情况下发生了什么，开发和发布分支来自哪里

你提到的文章是关于一个叫做 git flow 的工作流模型的。总体而言，这是一个很好的模型。它旨在为大型项目中代码协作的混乱和无政府状态带来秩序，而这正是它有效的地方。如果你有一百个人在一个应用程序上工作，如果你被迫支持旧版本（修复错误和严重漏洞），如果每天进行数百次提交 - 接受它，你不会后悔。

对于那些

• 很少，最多约10人；
• 处理敏捷和拆分任务，以便在一两天内完成；
• 主要使用最新版本的产品，不要拖旧版本；

...根本不需要git flow。它制造的问题多于它解决的问题。

如何让它更容易

但是，如果我的开发分支中的一切都已经准备就绪，我为什么还要创建一个发布分支

正确！您甚至不需要开发人员。

对于小型团队和单独开发，“轻量级”工作流模型更合适。最受欢迎的是 GitHub Flow，它在一些细节上与 GitLab Flow 和Simple Git workflow (Atlassian)的开发深度有所不同。

所有简单工作流模型的本质

1. 有一个稳定的（永久的，长期存在的）分支master。
2. 任何功能或错误修复都在一个单独的分支中完成，该分支从master.
3. 一旦功能或错误修复准备就绪，经过审查和测试，相应的分支就会合并到master. 然后必须移除树枝以免堆积垃圾。

除了明显的简单之外，优点是代码不写在“台面上”，不在发布分支，而是尽快发布。从创意到生产的路径越短，对企业越有利。客户（用户）更快地获得新功能，你也能更快地从客户那里获得反馈并从这些功能中获得资金。

如何创建和命名分支

在问题跟踪器中，功能分支名称通常以问题编号开头。

git checkout master
git checkout -b 123-featurebranch

你在某处保留待办事项清单吗？如果没有，请开始，原因如下：

1. 为了不让他们记住，tk。它不可靠并且会消耗大脑资源
2. 这样你就可以评估、计划、优先考虑它们
3. 存储有关错误以及如何重现错误的信息。
4. 团队合作培训；你可能不会一辈子都在独奏。
5. 如果项目是开源的，那么有人会来给你一个任务愿望或任务错误报告。或者他会接过你的任务然后去做，就像那样，一无所获。你不能做没有描述的任务，对吧？

制定小的、原子的任务，使分支机构的工作只需要 1-3 天，不会更多。这对单独工作很重要，对团队工作也很关键。

将本地分支推送到远程服务器也是可取的，这是一个很好的方法，当你把茶洒在笔记本电脑rm -rf /上、火灾、盗窃、陨石......时，不会丢失代码。

git push -u origin 123-featurebranch:

如何合并分支

主要有两种方式：

1. 可以在本地手动冻结分支。在命令行上它是这样的：

   git checkout master
   git merge --no-ff 123-featurebranch
   git push
   

2. 如果你使用 GitHub、GitLab、Bitbucket，你可以打开一个 pull/merge 请求，然后冻结它。在这种情况下，远程分支实际上被合并了，那么你将需要拉出合并的结果（git pull）。这种方法有助于在团队中进行代码检查和各种自动化测试，但如果你一个人工作，几乎不需要合并请求。

特点：

• 您需要合并分支，--no-ff以便始终创建合并提交。它可以帮助您查看历史记录，它可以帮助您找到进行提交的分支，并且可以准确指出该分支被冻结的位置，它可以通过git revert. 喜欢合并提交，你会需要它们。
• 没有必要合并到master没有准备好、没有完成等的东西中。分支master是神圣的，它必须始终包含工作代码。
• 你永远不应该将一个分支合并master到一个特性分支中。例外是将代码从一个主要版本中拉到一个长期存在的分支中，不同的分支用于不同的测试环境，以及其他在 solo 一个小项目时几乎不会发生的情况。

发布

当您准备好发布时，只需进行所需的合并提交并在其上放置一个标签。使用带注释的标签。它们存储日期和作者，就像在提交中一样。因此，有关发布版本的确切决定者和时间的信息将被保留。

git tag -a v1.0 -m "Version 1.0"

要将标签推送到远程服务器，请执行以下操作：

git push --follow-tags

如果您突然拥有它们，则需要该参数--follow-tags以便仅推送带注释的标签而不推送轻量级（轻量级）。

不要使用发布标签标记功能分支中的提交。我们冻结，测试结果，标记生成的合并提交。任何不在里面的东西master都不能成为释放。

使用语义版本控制生成版本号。

尽可能经常发布

由于分支master总是需要包含工作代码，并且您始终只将已完成的功能合并到其中，因此每次合并实际上都是一个小版本。在这种情况下，请确保每次都重建应用程序。并不是说它需要立即发布给所有用户——过于频繁的应用程序更新会惹恼他们。

但是尝试聚集一组 beta 测试人员（从你自己开始），你将在每个分支合并后为他们发布应用程序master。通过这种方式，您可以获得更快的反馈，并且操作系统周期越快，您的应用程序和技能发展就越快。这就是敏捷的本质。

实践

鉴于以上情况，我提出这样一个行动计划。

1. 冻结（合并）发展成高手。
2. 将标记附加到生成的合并提交。
3. 删除develop分支，暂时先不管它。

在本地开发分支上进行提交是否正确，在上面贴上标签......

可能是这样。

我只是不确定这个概念是否正确

它可以同时是正确的，而不是特别适合你的项目。

我不确定是否可以在远程分支上合并...

这是被禁止的。您可以将本地分支与远程分支同步（获取/拉取）、合并，以及将远程分支与本地分支同步（推送）。其实连origin/master分支也是本地的。

建议如何做对？

IT 是一个非常有趣的领域，有很多正确答案。

特别是，对于一个只有一个开发人员的项目，您可以通过一个主分支和标签发布来完成。

git flow 和其他技术只有在您确切了解它们解决的问题时才能发挥作用。只要您的项目不包含此类问题，这些技术本身只会使生活复杂化。

1 创建 rc 分支
2 从你的开发中
合并 3 合并 rc 分支

这样做是为了在发生崩溃时，您可以安全地切换到以前的稳定分支，修复新的 rc 分支并再次发布。我不建议删除分支。实际上，您经常需要从其他分支获取更改。但是如果你有超过 N 个分支并且你已经对它们感到困惑，那么你只能在本地清理它（git branch -d <branch>）

但是，如果我的开发分支中的一切都准备就绪，我为什么要创建一个发布分支......

分支的美妙之处不仅在于您可以获得项目的副本，还在于您的提交将在逻辑上合并：

*   4873cb7 Merge branch 'allow_different_debuggers_for_each_instance' into develop
|\  
| * 75b5384 Reduce TTL for variable
| * 4d0552a Figure out context for debugger methods automatically from current debugger instance
| * 1e4b894 Allow &DB::state to return current debugger instance
| * 19de6dc Make debugger instances typed (objects)
| * b5a7cfe Call methods of current debugger instance through &DB::mcall
|/  
* ec61d37 Code comments
* ecbc39a Rename _all_frames -> orig_frames
* 7aa54f9 Do not hide DB:: from PAUSE indexer

那些。然后你会看到这 5 次提交是作为该功能实现的一部分进行的

不要听任何人的，因为 如果您是独立开发人员，那么您不必遵循所有这些 gitflow 规则。从一开始就学会工作！

通过使用该模型git-flow并使用 pure git，是的，您将执行不必要的命令，这会减慢您的速度。但这不是这个模型的问题，而是你的问题，因为。你没有使用必要的实用程序 ;-) 例如，我使用gitflow-avh，配置.gitconf

[alias]
        tree        = log --graph --decorate --pretty=oneline --abbrev-commit
        prb         = pull -v --rebase
        br          = branch

        fs         = flow feature start
        ff         = flow feature finish
        fc         = flow feature checkout
        hs         = flow hotfix start
        hf         = flow hotfix finish

并将别名添加到.bashrc

alias gn="git-number"
alias gb="gn -c git blame"
alias ge="gn -c $EDITOR"
alias ga="gn add"
alias gr="gn -c git reset"
alias gap="EDITOR='$EDITOR -w' gn add -p"
alias gd="gn -c git diff -b -w --ignore-blank-lines"
alias gds="gd --staged"
alias gc="gn -c git checkout"
alias gcf="git flow feature checkout"
alias gl="gn -c git log -w -b -p --ignore-blank-lines"
alias gls="git log --stat"
alias cm="EDITOR='$EDITOR -w' git commit"
alias grb="git stash save 'REBASE' && EDITOR='$EDITOR -w' git rebase -i"
alias grbc="EDITOR='$EDITOR -w' git rebase --continue"

gcd() {
    test -n "$1" && cd $(dirname $(git list $1))
}

source ~/.git-completion.bash
__git_complete gn  _git
__git_complete ga  _git_add
__git_complete gap _git_add
__git_complete gd  _git_diff
__git_complete gds _git_diff
__git_complete gc  _git_checkout
__git_complete gcf _git_checkout
__git_complete gl  _git_log
__git_complete gls _git_log
__git_complete cm  _git_commit

source ~/.git-flow-completion.bash

而且我在控制台中使用所有这些“不必要的”分支比使用各种图形工具更快，而且我得到了一个美丽的故事作为奖励，因为 跟随git-flow。此外，所有功能都在手边git（通常图形实用程序不会实现所有功能，但大多只实现基本功能）。可以在此处
找到有关如何设置环境的更多信息。

我不了解你，但在一开始，当我结识时git，我对有分支的理解感到困惑master，，。因此，我自己决定了。恕我直言：productiondevelop

• 我们滚动到战斗服务器的分支 -production
• 正在进行开发的分支（合并功能的地方）-develop

是的，在许多文章中，分支master意味着production

但是我本地只有一个开发分支，远程我有一个开发和一个master...

回答你的问题如何正确地做，我会提请你注意你的工作总是在本地发生的事实，你只与远程存储库同步。这就是为什么

1. 您将本地开发人员合并为本地主控
2. 您正在将本地主机推送到远程主机

好吧，那么我将支持这个详细的答案，但有几点除外：

只有一个稳定的 master 分支。

在您测试之前，它不能称为稳定的。在测试期间，您可能会发现一个错误，您将在master. 因此，在上一次提交时，您的分支是不稳定的。

为此，他们想出了一个分支release。您可以在其中进行任意数量的测试迭代，完成后您可以发布您的版本并将分支合并到master/production和develop。

让他们不要说什么，但无论如何，你应该有以下分支：

• production分支是保证任何提交都可以部署的分支。
• developbranch - 这是您将功能合并到的分支
• hotfixbranch - 这个分支（以免从 prod 到 dev 中挑选）你在其中进行修复
• releasebranch - 用于轻松创建发布

因此，即使你是一个孤独的程序员，我也建议你遵循git-flow模型，以便能够正确地工作。

在您描述的情况下，您可以采用两种方式：

1. 通过创建发布分支并立即提交来遵循 git 流路径。
2. 自己与 master 和 [可选] tag master 合并开发。

这两种方法都会给出相同的结果，但是使用第二种方法，您需要做的工作更少。因此，在我看来，值得使用它。

那么为什么我们需要发布分支呢？问题是，任何方法论都是由一位作者或一组作者多年来发展起来的一组原则。Git flow 从团队开发发展而来，通常会有不同的人参与测试产品，也可能有一些人必须接受产品。

这是发布分支很适合的地方。例如，您的团队已经完成了发布所需的一组特定功能，比如 1.0 版。这一切都在 develop 分支，你没有信心代码是正确的（它没有被正确测试，而且主要经理也没有研究功能）。您可以发布 develop 的结果，但是那些不能将新功能推入 develop 的闲置开发人员呢？是否有明确界定的发布功能范围？

为了不让开发人员闲着，我们发布了一个发布分支，其中不能添加新功能，但必须纠正发现的任何错误和不准确之处。当发现的所有错误都已修复并考虑到评论时，发布分支将关闭，并与 master 合并并发布产品。

如您所见，您不需要发布分支作为独行者。因此，如果您不想做额外的工作，请跳过此步骤，并记住任何方法都是一组通用原则和规则，几乎总是需要根据特定案例的需要调整方法——如果您不这样做的话了解如何使用某些东西，那么你几乎肯定不需要它。

确保你有一个本地主分支。而且你需要合并，当然是在本地，然后上传到中央仓库。

至于是否需要创建发布分支，这可能完全取决于您如何开发项目以及如何组织流程。在有 Scrum、持续集成和 DevOps 的 21 世纪，只需单击一个按钮即可部署项目，无需在单独的分支中每次发布都使用文件进行修改。

在这里，而是向关于哈布雷的文章的作者提出问题。

另一件事，永久分支release。它可以用于实现相同的一键扩展。有几种不同的方法可以实现这种行为，其中之一是在分支上挂一个push钩子release，根据这个钩子，新代码将被部署到生产服务器（又名production）。

然后你只需在一个分支中编写和测试代码，我们称之为dev，当你认为代码工作正常时，将更改推送到release，你的构建服务器构建安装包或将代码部署到 Web 服务器。

同时，当然，你把标签，放在你方便的地方。线dev正好合适。

GitFlow 是一个经过验证的经典和简单的概念。然后，如果你改变它，那么它就会在 GitLab Flow 上，在 pre-prod 分支中以额外稳定的形式应用复杂化。

develop 分支包含最新的开发代码的想法是显而易见的，并且更符合任何流程之前应用的开发方法，这使得从其他 CVS（Subversion，TFS）切换到它更容易，其中发布支持逻辑是相似的。

如果您开始实施Git Flow方法，我建议您使用俄语进行演示：https ://medium.com/ruopsdev/git-flow-presentation-b80643390888

有指向 IDE（Visual Studio Code、JetBrains IntelliJ IDEA、Atlassian SourceTree）的 git-flow 插件的链接，以及与 GitHub Flow 和 GitLab Flow 的比较。