不懂就问， git 如何修改旧代码，并且不影响新代码或者合并到新代码

你想只修复 1.1 里的 bug，然后以后的版本里还保留这个 bug ？

这个 bug 应该在 1.5 上边修复，而不是 1.1

回退 1.1，cherry-pick 后面多个，但是这种很强迫症，没有人能保证每一个 commit 都是上线标准，tag 才是做这个的

没懂什么意思。
如果是在 1.1 引入 bug，之后版本可以不要的话就回滚到 1.0，如果后面版本的内容还需要就在 1.5 修复这个 bug

切换到 1.0，新开一个 1.0.1 分支，修改好 bug 。然后把这个 1.0.1 分支直接合并到后面的版本里。

建议在 1.5 改，不过也可以这样
1.0--1.1--1.2--1.3--1.4--bugfix
rebase squash
1.0--1.1bugfix-1.2--1.3--1.4

我猜测 lz 的意思是 1.1 发现了 bug，想悄悄的修复不被人知道，这是不可能的

revert 1.1

如果你不想让人知道的话
1.1 出来一个 fix branch 然后再 rebase 回去？

https://semver.org/lang/zh-CN/

标记版本号的软件发行后，禁止（ MUST NOT ）改变该版本软件的内容。任何修改都必须（ MUST ）以新版本发行。

建议提交一个修复的 commit 。你在 1.1 这个 commit 上的任何操作都会导致之后的 commit ID 变化，不可能不影响的。

git 的作用就是保留历史

如果这个 bug 只在 1.1 有, 那么就从 1.1 的位置开新分支做个 1.1a

如果这个 bug 后续都有, 就在 1.5 修复.

@QingStone 现在才发现有问题，实际上 1.1 是个正式版本，但是问题想修复，以后的版本肯定也要修改
@xarthur 只是在后面才发现之前的问题，
@hsfzxjy 还能这样 bugfix 能 rebase 到 1.1 ？好神奇啊
@mwzdouks 并不是，只是不想正式版本有 bug 而已
目前是 checkout 1.1 然后 fix bug 重新发版本打了个 tag，同时在 now 也修复这个 bug

@rationa1cuzz rebase 命令干什么都行，先把 bugfix 挪到 1.1 的下一个，然后改成 squash，就能合进 1.1

我司的做法是主干修复然后 cherry pick 移植到老版本。

你现在应该有 release-1.1 release-1.2 release-1.3 等等的发布分支吧。
比如你现在的版本修复了，发布了 1.5.0，那么你把修复 bug 的这个修改补丁，打到 1.4 、1.3 、1.2 、1.1 的发布分支上，他们就分别变成了 1.1.1，1.2.1，1.3.1，1.4.1 版本。

当然这前提是你遵循 semver 规则。
如果你本来就是滚动更新的话，那老版本也就没必要修复了，直接让人用新版就行了。

@rationa1cuzz 从 1.1 切出一个分支，修复完，分别 merge 到 1.1 和 now 上

@ZzFoo 不对，听你的描述，你们应该只有一个分支。那你只要从 1.1 切出另一个分支，修复完在这个分支上 build 就好了，并把这个分支 merge 到现在有的分支上

目前是 checkout 1.1 然后 fix bug 重新发版本打了个 tag，同时在 now 也修复这个 bug
---这样就可以了

开发分支和发布分支独立（每个大版本都弄一个独立分支，同时也要打 tag ）然后修复通用问题的时候就是去开发分支上 cherry pick，然后再打 tag

我的想法：从 now 分支 checkout 一个 bug 分支，reset 到 1.1 版本，修复 bug 之后再与 now 进行 merge

没试过不知道行不行