V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
rationa1cuzz
V2EX  ›  git

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

  •  
  •   rationa1cuzz · Mar 24, 2021 · 3593 views
    This topic created in 1860 days ago, the information mentioned may be changed or developed.
    比如我提交记录是:1.0--1.1--1.2--1.3--1.4--now
    现在发现 1.1 有个 bug 如何操作才能保证修改后不影响后面版本?
    20 replies    2021-03-25 11:04:49 +08:00
    QingStone
        1
    QingStone  
       Mar 24, 2021 via iPhone
    你想只修复 1.1 里的 bug,然后以后的版本里还保留这个 bug ?
    Vegetable
        2
    Vegetable  
       Mar 24, 2021
    这个 bug 应该在 1.5 上边修复,而不是 1.1
    wgbx
        3
    wgbx  
       Mar 24, 2021
    回退 1.1,cherry-pick 后面多个,但是这种很强迫症,没有人能保证每一个 commit 都是上线标准,tag 才是做这个的
    xarthur
        4
    xarthur  
       Mar 24, 2021 via iPhone
    没懂什么意思。
    如果是在 1.1 引入 bug,之后版本可以不要的话就回滚到 1.0,如果后面版本的内容还需要就在 1.5 修复这个 bug
    340244120w
        5
    340244120w  
       Mar 24, 2021 via iPhone
    切换到 1.0,新开一个 1.0.1 分支,修改好 bug 。然后把这个 1.0.1 分支直接合并到后面的版本里。
    hsfzxjy
        6
    hsfzxjy  
       Mar 24, 2021 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
    digitv
        7
    digitv  
       Mar 24, 2021
    我猜测 lz 的意思是 1.1 发现了 bug,想悄悄的修复不被人知道,这是不可能的
    SjwNo1
        8
    SjwNo1  
       Mar 24, 2021
    revert 1.1
    mwzdouks
        9
    mwzdouks  
       Mar 24, 2021 via Android
    如果你不想让人知道的话
    1.1 出来一个 fix branch 然后再 rebase 回去?
    Delbert
        10
    Delbert  
       Mar 24, 2021   ❤️ 2
    https://semver.org/lang/zh-CN/

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

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

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

    没试过不知道行不行
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1242 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 59ms · UTC 23:35 · PVG 07:35 · LAX 16:35 · JFK 19:35
    ♥ Do have faith in what you're doing.