如何使用 Git 为一个标签打补丁？
我们使用git来管理我们的代码，并且在发布新版本时只创建一个标签。那么如果我们
在发布后发现了bug并且做了一些新的改变，那么如何处理呢？
顺便说一句：我们不使用 mutil 分支，因为我们想让流程变得简单
We use git to manage our code, and just create one tag when release new version. So if we
find bugs after we release and hava made some new changes, how to deal with case ?
BTW: we do not use mutil branch because we would like to make process easy
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种情况是分支存在的部分原因，所以我怀疑从长远来看，避免分支只会让事情变得更困难。不过，我想您可以这样做：
检查发布标签。
修复错误、提交、重新标记并发布修复。
将 master 重新设置为新标签的基准。
这将在发布后立即将您的修复插入时间线中（通过避免您已线性化提交图的分支）。
更新
正如 @cdhowie 在评论中指出的那样，“如果多个开发人员克隆了存储库，这种方法将无法无缝工作，因为它将改变历史记录并需要强制推送”。请参阅 git-rebase 手册页中“从上游 Rebase 恢复”部分，其中显示：
换句话说，您可以采用变基策略并保持历史线性，但实际上您可能会以这种方式为自己创造更多工作。为每个版本建立一个单独的分支是标准做法，这是有充分理由的。
This situation is part of the reason branches exist, so I suspect that in the long run you're just making things harder for yourself by avoiding branches. I suppose you could do something like this, though:
Checkout the release tag.
Make your bugfix, commit, re-tag and release the fix.
Rebase master off of your new tag.
This will insert your fix in the timeline (by avoiding branches you've linearized your commit graph) immediately after the release.
Update
As @cdhowie points out in the comments, "this approach will not work seamlessly if more than one developer has the repo cloned, since it will alter history and require a forced push". See the section of the
git-rebaseman page tilted "Recovering from Upstream Rebase" where it says:So in other words, you could go with a rebasing strategy and keep your history linear, but you're probably actually creating more work for yourself that way. Having a separate branch for each release is the standard practice for good reason.
使用可以提交修复的每个版本分支。这是管理版本的最简单方法。
...如果你不想使用 Git 的分支功能，为什么不使用带有 GUI 的东西，比如 Subversion？如果您担心 VCS 的简单性，那么 Git 是错误的选择。如果担心出色的分支功能，Git 是完美的选择。
Use a per-release branch that you can commit fixes to. This is the easiest way to manage releases.
... And if you don't want to use the branching feature of Git, why aren't you using something with a GUI, like Subversion instead? If simplicity of your VCS is a concern, Git is the wrong choice. If awesome branching features are a concern, Git is the perfect choice.