[Git][分支管理][下]详细讲解

1.合并冲突

• 在实际分⽀合并的时候，有时候可能会遇到代码冲突的问题，例如：

  • dev分支在写一部分代码，而master分支也没闲着，也在写着同一份代码
  • 两份代码都将自己的代码commit了，此时再合并分支，就会出现问题

    $ git merge dev
    Auto-merging dev.txt
    CONFLICT (content): Merge conflict in dev.txt
    Automatic merge failed; fix conflicts and then commit the result.
    1
    2
    3
    4

    

• 解决方案：在发生冲突的文件内手动调整解决，并进行一次 修改 && 提交 操作

  • Git会用<<<<<<<, =======, >>>>>>>来标记出不同分支的冲突内容

    $ cat dev.txt
    I'm in dev_branch :P
    
    <<<<<<< HEAD
    From master_branch
    =======
    From dev_branch
    >>>>>>> dev
    1
    2
    3
    4
    5
    6
    7
    8

  • 删除冲突内容后，重新git add, git commit

    $ git add .
    $ git commit -m "chose the master version"
    [master ab30dfd] chose the master version
    1
    2
    3

    

• git log添加--graph --abbrev-commit参数可以看到分支的合并情况
  

2.分支管理策略

• 通常合并分⽀时，如果可能，Git会采⽤Fast forward模式

  • 换句话说，只要条件允许，Git就会尽可能地采用Fast forward模式

• 但是如果采用Fast forward模式之后，形成的合并结果是怎样的呢？

  • 在Fast forward模式下，删除dev分支后，查看分支历史时，会丢失分支信息
  • 导致看不出来最新提交到底的merge进来的还是正常提交的

    $ git log
    commit 23bed4ed226e91a17d6c7fd09303c9a152057f42 (HEAD -> master, dev)
    Author: DieSnowK <1752351098@qq.com>
    Date:   Wed Jul 24 15:19:38 2024 +0800
    
    	md dev.txt
    1
    2
    3
    4
    5
    6

    

• 在合并冲突时，通过手动调整解决冲突，会再进行一次 修改 && 提交 操作

  • 此时就不是Fast forward模式了
  • 好处：从分支历史上可以看出分支信息
    • 例如：已经删除了dev分支，但是仍然可以看到master是由其他分支合并得到的

    $ git log
    commit 7d05eb48eccc9ca23297791d5ee41b2e1862ab5e (HEAD -> master)
    Merge: 23bed4e 923a843
    Author: DieSnowK <1752351098@qq.com>
    Date:   Wed Jul 24 15:30:16 2024 +0800
    
    	merge dev with no-ff
    1
    2
    3
    4
    5
    6
    7

    

• Git支持用户强制禁用Fast forward模式，那么就会在merge时生成一个新的commit

  • 命令：git merge --no-ff branch_name
    • --no-ff参数表示禁用Fast forward模式
    • 禁用Fast forward模式后合并会创建一个新的commit，所以还需要加上-m参数
  • 综上，完整命令：git merge --no-ff -m "msg" branch_name
  • 这样从分支历史上就可以看出分支信息了
    

• 总结：

  • 合并分⽀时，加上--no-ff参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并
  • ⽽Fast forward合并就看不出来曾经做过合并

3.分支策略

1.基本原则

• master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活
• 干活都在dev分⽀上，也就是说，dev分⽀是不稳定的，
  • 某个版本发布时，再把dev分⽀合并到master上，在master分⽀发布该版本
• 每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了
  

2.bug分支

• 在Git中，每个bug都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除
• 情景：假如正在dev2分⽀上进⾏开发，开发到⼀半，突然发现master分⽀上⾯有bug，需要解决，可现在dev的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？
  • 解决方案：使用git stash命令，将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来
    • 此时，就可以放心地创建分支来修复bug了

    $ git status
    On branch dev
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    		modified:   SnowK.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")
    
    $ git stash
    Saved working directory and index state WIP on dev: 2c93d33 Done
    
    $ git status
    On branch dev
    nothing to commit, working tree clean
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15

• 实际操作流程：
  • 切回master分支，新建并切换至fix_bug分支，修复bug，重新add, commit

    $ git checkout master
    $ git checkout -b fix_bug
    Switched to a new branch 'fix_bug'
    
    # Fix bugs
    
    $ git add SnowK.txt
    $ git commit -m "Bugs Fix Done"
    [fix_bug 8b8fe09] Bugs Fix Done
     1 file changed, 1 insertion(+), 1 deletion(-)
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10

  • 修复完成后，切换到master分支，完成合并，最后删除fix_bug分支

    $ git checkout master
    Switched to branch 'master'
    
    $ git merge --no-ff -m "merge stable branch from fix_bug" fix_bug
    Merge made by the 'ort' strategy.
     SnowK.txt | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    1
    2
    3
    4
    5
    6
    7

  • 至此，bug已经修复完，可以继续回到dev分支进行开发，恢复之前的开发现场
    • 查看所有的存储情况：git stash list
    • 恢复现场并删除该stash：git stash pop
      • git stash apply也可以恢复现场
      • 但是恢复后，stash内容并不会删除，需要用git stash drop来手动删除

      $ git checkout dev
      Switched to branch 'dev'
      
      $ cat SnowK.txt
      Hey I'm SnowK :P
      May be bug?
      
      $ git stash list
      stash@{0}: WIP on dev: 2c93d33 Done
      
      $ git stash pop
      On branch dev
      Changes not staged for commit:
        (use "git add <file>..." to update what will be committed)
        (use "git restore <file>..." to discard changes in working directory)
              modified:   SnowK.txt
      
      no changes added to commit (use "git add" and/or "git commit -a")
      Dropped refs/stash@{0} (122edfbb91bc4a378c38cb7b5bde9dcdf8a1cd61)
      
      $ cat SnowK.txt
      Hey I'm SnowK :P
      May be bug?
      
      dev: I'm codeing...
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25

• 状态图梳理 && 实际开发中的建议

  • master分支的bug修复后，修复后的代码在此时的dev分支里是没有的

    • 毕竟dev里留存的是master上一版的代码
      

  • 最终目的是要让master合并dev分支，正常情况下肯定是切回master分支直接合并

    • 但这样存在一定的风险
    • 因为在合并分⽀时可能会有冲突，⽽代码冲突需要⼿动解决(在master上解决)
    • 我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，解决的过程中难免手误出错，导致错误的代码被合并到master上
      

  • 解决以上问题的⼀个好的建议：

    • 最好先在⾃⼰的分⽀上合并下master ，再让master去合并dev

    • 这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响master
      

      

3.删除临时分支

• 添加⼀个新功能时，肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了
  • 所以每添加⼀个新功能，最好新建⼀个分⽀，可以将其称之为feature分支
  • 在上面开发，完成后合并，最后删除该feature分⽀
• 如果正在某个feature分支上开发了一半，被产品经理突然叫停，停止该新功能的开发
  • 此时该feature分支就必须就地销毁，留着无用
• 此时使用传统的git branch -d branch_name命令删除分支是行不通的
  • 因为该分支还没有被merge到master分支或者其他分支上
  • Git默认只要是被新建出来的分支，都是有用的，会自动保护没有被merge的分支
• 强制删除：git branch -D branch_name

  $ git branch -d dev
  error: The branch 'dev' is not fully merged.
  If you are sure you want to delete it, run 'git branch -D dev'.
  
  $ git branch -D dev
  Deleted branch dev (was d009d1d).
  1
  2
  3
  4
  5
  6