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

[rationa1cuzz]

比如我提交记录是：1.0--1.1--1.2--1.3--1.4--now
现在发现 1.1 有个 bug 如何操作才能保证修改后不影响后面版本？

[QingStone]

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

[Vegetable]

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

[wgbx]

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

[xarthur]

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

[340244120w]

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

[hsfzxjy]

建议在 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

[dynastysea]

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

[SjwNo1]

revert 1.1

[mwzdouks]

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

[Delbert]

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

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

[baiyi]

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

[chinvo]

git 的作用就是保留历史

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

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

[rationa1cuzz]

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

[hsfzxjy]

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

[msg7086]

我司的做法是主干修复然后 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 规则。
如果你本来就是滚动更新的话，那老版本也就没必要修复了，直接让人用新版就行了。

[ZzFoo]

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

[ZzFoo]

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

[Chenamy2017]

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

[codehz]

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

[faceRollingKB]

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

没试过不知道行不行