V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
rationa1cuzz
V2EX  ›  git

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

  •  
  •   rationa1cuzz · 2021-03-24 11:32:52 +08:00 · 2741 次点击
    这是一个创建于 1100 天前的主题,其中的信息可能已经有所发展或是发生改变。
    比如我提交记录是:1.0--1.1--1.2--1.3--1.4--now
    现在发现 1.1 有个 bug 如何操作才能保证修改后不影响后面版本?
    20 条回复    2021-03-25 11:04:49 +08:00
    QingStone
        1
    QingStone  
       2021-03-24 11:35:25 +08:00 via iPhone
    你想只修复 1.1 里的 bug,然后以后的版本里还保留这个 bug ?
    Vegetable
        2
    Vegetable  
       2021-03-24 11:38:04 +08:00
    这个 bug 应该在 1.5 上边修复,而不是 1.1
    wgbx
        3
    wgbx  
       2021-03-24 11:38:39 +08:00
    回退 1.1,cherry-pick 后面多个,但是这种很强迫症,没有人能保证每一个 commit 都是上线标准,tag 才是做这个的
    xarthur
        4
    xarthur  
       2021-03-24 11:40:35 +08:00 via iPhone
    没懂什么意思。
    如果是在 1.1 引入 bug,之后版本可以不要的话就回滚到 1.0,如果后面版本的内容还需要就在 1.5 修复这个 bug
    340244120w
        5
    340244120w  
       2021-03-24 11:44:57 +08:00 via iPhone
    切换到 1.0,新开一个 1.0.1 分支,修改好 bug 。然后把这个 1.0.1 分支直接合并到后面的版本里。
    hsfzxjy
        6
    hsfzxjy  
       2021-03-24 11:45:12 +08:00 via Android
    建议在 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
        7
    dynastysea  
       2021-03-24 11:45:35 +08:00
    我猜测 lz 的意思是 1.1 发现了 bug,想悄悄的修复不被人知道,这是不可能的
    SjwNo1
        8
    SjwNo1  
       2021-03-24 12:22:28 +08:00
    revert 1.1
    mwzdouks
        9
    mwzdouks  
       2021-03-24 12:29:04 +08:00 via Android
    如果你不想让人知道的话
    1.1 出来一个 fix branch 然后再 rebase 回去?
    Delbert
        10
    Delbert  
       2021-03-24 12:35:06 +08:00   ❤️ 2
    https://semver.org/lang/zh-CN/

    标记版本号的软件发行后,禁止( MUST NOT )改变该版本软件的内容。任何修改都必须( MUST )以新版本发行。
    baiyi
        11
    baiyi  
       2021-03-24 13:05:03 +08:00
    建议提交一个修复的 commit 。你在 1.1 这个 commit 上的任何操作都会导致之后的 commit ID 变化,不可能不影响的。
    chinvo
        12
    chinvo  
       2021-03-24 13:11:38 +08:00 via iPhone
    git 的作用就是保留历史

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

    如果这个 bug 后续都有, 就在 1.5 修复.
    rationa1cuzz
        13
    rationa1cuzz  
    OP
       2021-03-24 13:17:26 +08:00
    @QingStone 现在才发现有问题,实际上 1.1 是个正式版本,但是问题想修复,以后的版本肯定也要修改
    @xarthur 只是在后面才发现之前的问题,
    @hsfzxjy 还能这样 bugfix 能 rebase 到 1.1 ?好神奇啊
    @mwzdouks 并不是,只是不想正式版本有 bug 而已
    目前是 checkout 1.1 然后 fix bug 重新发版本打了个 tag,同时在 now 也修复这个 bug
    hsfzxjy
        14
    hsfzxjy  
       2021-03-24 13:21:02 +08:00 via Android
    @rationa1cuzz rebase 命令干什么都行,先把 bugfix 挪到 1.1 的下一个,然后改成 squash,就能合进 1.1
    msg7086
        15
    msg7086  
       2021-03-24 13:23:31 +08:00
    我司的做法是主干修复然后 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
        16
    ZzFoo  
       2021-03-24 15:00:27 +08:00
    @rationa1cuzz 从 1.1 切出一个分支,修复完,分别 merge 到 1.1 和 now 上
    ZzFoo
        17
    ZzFoo  
       2021-03-24 15:03:19 +08:00
    @ZzFoo 不对,听你的描述,你们应该只有一个分支。那你只要从 1.1 切出另一个分支,修复完在这个分支上 build 就好了,并把这个分支 merge 到现在有的分支上
    Chenamy2017
        18
    Chenamy2017  
       2021-03-24 15:43:10 +08:00
    目前是 checkout 1.1 然后 fix bug 重新发版本打了个 tag,同时在 now 也修复这个 bug
    ---这样就可以了
    codehz
        19
    codehz  
       2021-03-24 22:24:19 +08:00
    开发分支和发布分支独立(每个大版本都弄一个独立分支,同时也要打 tag )然后修复通用问题的时候就是去开发分支上 cherry pick,然后再打 tag
    faceRollingKB
        20
    faceRollingKB  
       2021-03-25 11:04:49 +08:00
    我的想法:从 now 分支 checkout 一个 bug 分支,reset 到 1.1 版本,修复 bug 之后再与 now 进行 merge

    没试过不知道行不行
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1180 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 18:17 · PVG 02:17 · LAX 11:17 · JFK 14:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.