我们使用git来管理我们的代码，并在发布新版本时创建一个标记。所以，如果我们
我们发布后发现bug和hava做了一些新的改动，如何处理案例？BTW：我们不使用mutil分支，因为我们希望简化过程
答案 0 :(得分：8)
这种情况是分支存在的部分原因，所以我怀疑从长远来看，你只是通过避免分支来让自己变得更难。我想你可以做这样的事情，但是：
签出发布代码。
进行错误修正，提交，重新标记和解除修复。
重新启用新标记的主程序。
这将在发布后立即在时间轴中插入您的修复程序（通过避免使您的提交图线性化的分支）。
正如@cdhowie在评论中指出的那样，“如果不止一个开发人员克隆了repo，这种方法将无法无缝地工作，因为它将改变历史并需要强制推送”。请参阅git-rebase手册页倾斜的部分“从上游Rebase恢复”，其中显示：
重新定位（或任何其他形式的重写）其他人拥有的分支 基于工作是一个坏主意：它下游的任何人都被迫 手动修复其历史记录。本节介绍如何进行修复 从下游的角度来看。然而，真正的解决办法是 首先避免重新定位上游。
换句话说，你可以采用变基策略并保持你的历史线性，但你实际上可能正在为自己创造更多的工作。每个版本都有一个单独的分支是有充分理由的标准做法。
答案 1 :(得分：6)
使用可以提交修复程序的每个发行版分支。这是管理版本的最简单方法。
...如果您不想使用Git的分支功能，为什么不使用带有GUI的东西，比如Subversion？如果您的VCS的简单性是一个问题，Git是错误的选择。如果令人敬畏的分支功能是一个问题，Git是一个完美的选择。