从开发到发布使用什么流畅的 Git 工作流程？
What smooth Git workflow to use to get from a development to a release?
我的问题（目前）还不是很清楚，我可能需要您的反馈来更好地理解我真正在寻找什么...
无论如何，我已经阅读了很多关于 git-flow 和 Git 上使用的其他流程的内容，但我仍然对如何解决我的情况存在分歧。
我目前有一个 master 分支，它同时发展为开发和发布。这主要是因为所有历史记录都是从我们以前的 SCM 导入的。我们还在每个版本上放置了一个 tag。
今天我们开始发布流程。对于我们唯一的 master 分支，我们被迫冻结开发，直到发布完成。或者我们可以：
- 从
master 创建一个 rc 分支，应用热修复。最终将 rc 合并到 release 分支上，然后对其应用标签。
- 从
master 创建一个 develop 分支，然后使用 master 作为 rc 分支。最终在 master 上应用 tag 并继续将 develop 作为主要开发分支。
对于解决方案 (1)，在第一个版本上创建分支然后将所有下一个版本反向合并到其中的问题是开放的。标签也应该移动，这可能会造成混淆。
对于解决方案 (2)，master 被视为发布分支，而不是应有的开发分支。
我不太相信 git-flow 这增加了一些复杂性。我希望 master 分支仍然是项目的 trunk，但在这种情况下我不知道哪种方案最适合。
用例：
我有这个 git 日志，我想从中开始发布验证过程。
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
第一个方案是保留master开发分支，然后创建release/v1.2rc分支
* v1.2 [v1.2] (release/releases)
| * merge next feature to master (master)
* | changing version rc to release (release/v1.2rc)
| * merged hotfix
|/|
* | hotfix
|/
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
要将所有版本保留在 release/releases 分支中，从头开始做这项工作会很有用：
* v1.2 [v1.2] (release/releases)
/|
/ |
/* | merge next feature to master (master)
* | | changing version rc to release (release/v1.2rc)
| * | merged hotfix
|/| |
* | | hotfix
|/ /
* * v1.1.1 [v1.1.1]
*/| some changes
* | v1.1.1
| * v1.1 [v1.1]
*/| hotfix
* | v1.1
* | merged feature foo into master
* | changes
| * v1.0 [v1.0]
*/
* v1.0
这允许做 git log release/releases
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]
然而，通过在单独的分支上移动标签和版本，我们失去了对 master 的可见性。此外，对先前版本 即 v1.1.2 的错误更正并不容易，在一天结束时我们会得到一个非常令人不安的 release/releases 日志：
* v1.1.2 hotfix [v1.1.2]
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]
这是我们正在使用的一种可能的选择。我们创建发布标签而不是发布分支。
git checkout master
#make some commits
git tag v1.0.0
git push <remote> v1.0.0
现在构建服务器可以获取标签 v1.0.0
mkdir buildspace
cd buildspace
git init
git fetch <remote_url> v1.0.0
git checkout FETCH_HEAD
#run the build job
如果发布需要额外的提交，我们可以获取并签出 v1.0.0，进行提交，并将标签 v1.0.0 更新为新的 HEAD，或者创建另一个标签，如 v1.0.1 并推送它.发布完成后，如果需要，我们可以将标签合并到 master 中。在某些情况下，master 并不需要发布的所有提交，我们可以通过 git cherry-pick 或 git rebase 将其中一些提交回 master。同时 master 不必被冻结。我们可以在 master 上进行其他提交并推送到远程 master，这与发布无关。
我的问题（目前）还不是很清楚，我可能需要您的反馈来更好地理解我真正在寻找什么...
无论如何，我已经阅读了很多关于 git-flow 和 Git 上使用的其他流程的内容，但我仍然对如何解决我的情况存在分歧。
我目前有一个 master 分支，它同时发展为开发和发布。这主要是因为所有历史记录都是从我们以前的 SCM 导入的。我们还在每个版本上放置了一个 tag。
今天我们开始发布流程。对于我们唯一的 master 分支，我们被迫冻结开发，直到发布完成。或者我们可以：
- 从
master创建一个rc分支，应用热修复。最终将rc合并到release分支上，然后对其应用标签。 - 从
master创建一个develop分支，然后使用master作为rc分支。最终在master上应用tag并继续将develop作为主要开发分支。
对于解决方案 (1)，在第一个版本上创建分支然后将所有下一个版本反向合并到其中的问题是开放的。标签也应该移动，这可能会造成混淆。
对于解决方案 (2)，master 被视为发布分支，而不是应有的开发分支。
我不太相信 git-flow 这增加了一些复杂性。我希望 master 分支仍然是项目的 trunk，但在这种情况下我不知道哪种方案最适合。
用例：
我有这个 git 日志，我想从中开始发布验证过程。
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
第一个方案是保留master开发分支，然后创建release/v1.2rc分支
* v1.2 [v1.2] (release/releases)
| * merge next feature to master (master)
* | changing version rc to release (release/v1.2rc)
| * merged hotfix
|/|
* | hotfix
|/
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
要将所有版本保留在 release/releases 分支中，从头开始做这项工作会很有用：
* v1.2 [v1.2] (release/releases)
/|
/ |
/* | merge next feature to master (master)
* | | changing version rc to release (release/v1.2rc)
| * | merged hotfix
|/| |
* | | hotfix
|/ /
* * v1.1.1 [v1.1.1]
*/| some changes
* | v1.1.1
| * v1.1 [v1.1]
*/| hotfix
* | v1.1
* | merged feature foo into master
* | changes
| * v1.0 [v1.0]
*/
* v1.0
这允许做 git log release/releases
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]
然而，通过在单独的分支上移动标签和版本，我们失去了对 master 的可见性。此外，对先前版本 即 v1.1.2 的错误更正并不容易，在一天结束时我们会得到一个非常令人不安的 release/releases 日志：
* v1.1.2 hotfix [v1.1.2]
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]
这是我们正在使用的一种可能的选择。我们创建发布标签而不是发布分支。
git checkout master
#make some commits
git tag v1.0.0
git push <remote> v1.0.0
现在构建服务器可以获取标签 v1.0.0
mkdir buildspace
cd buildspace
git init
git fetch <remote_url> v1.0.0
git checkout FETCH_HEAD
#run the build job
如果发布需要额外的提交，我们可以获取并签出 v1.0.0，进行提交，并将标签 v1.0.0 更新为新的 HEAD，或者创建另一个标签，如 v1.0.1 并推送它.发布完成后，如果需要，我们可以将标签合并到 master 中。在某些情况下，master 并不需要发布的所有提交，我们可以通过 git cherry-pick 或 git rebase 将其中一些提交回 master。同时 master 不必被冻结。我们可以在 master 上进行其他提交并推送到远程 master，这与发布无关。