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

目录

1.合并冲突

• 在实际分⽀合并的时候，有时候可能会遇到代码冲突的问题，例如：- dev分支在写一部分代码，而master分支也没闲着，也在写着同一份代码- 两份代码都将自己的代码commit了，此时再合并分支，就会出现问题$ git merge devAuto-merging dev.txtCONFLICT (content): Merge conflict in dev.txtAutomatic merge failed; fix conflicts and then commit the result.
• 解决方案：在发生冲突的文件内手动调整解决，并进行一次 修改 && 提交 操作- Git会用<<<<<<<, =======, >>>>>>>来标记出不同分支的冲突内容$ cat dev.txtI'm in dev_branch :P<<<<<<< HEADFrom master_branch=======From dev_branch>>>>>>> dev- 删除冲突内容后，重新git add, git commit``````$ git add .$ git commit -m "chose the master version"[master ab30dfd] chose the master version
• git log添加--graph --abbrev-commit参数可以看到分支的合并情况

2.分支管理策略

• 通常合并分⽀时，如果可能，Git会采⽤Fast forward模式- 换句话说，只要条件允许，Git就会尽可能地采用Fast forward模式
• 但是如果采用Fast forward模式之后，形成的合并结果是怎样的呢？- 在Fast forward模式下，删除dev分支后，查看分支历史时，会丢失分支信息- 导致看不出来最新提交到底的merge进来的还是正常提交的$ git logcommit 23bed4ed226e91a17d6c7fd09303c9a152057f42 (HEAD -> master, dev)Author: DieSnowK <[email protected]>Date: Wed Jul 24 15:19:38 2024 +0800 md dev.txt
• 在合并冲突时，通过手动调整解决冲突，会再进行一次 修改 && 提交 操作- 此时就不是Fast forward模式了- 好处：从分支历史上可以看出分支信息 - 例如：已经删除了dev分支，但是仍然可以看到master是由其他分支合并得到的$ git logcommit 7d05eb48eccc9ca23297791d5ee41b2e1862ab5e (HEAD -> master)Merge: 23bed4e 923a843Author: DieSnowK <[email protected]>Date: Wed Jul 24 15:30:16 2024 +0800 merge dev with no-ff
• 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 statusOn branch devChanges 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.txtno changes added to commit (use "git add" and/or "git commit -a")$ git stashSaved working directory and index state WIP on dev: 2c93d33 Done$ git statusOn branch devnothing to commit, working tree clean
• 实际操作流程： - 切回master分支，新建并切换至fix_bug分支，修复bug，重新add, commit``````$ git checkout master$ git checkout -b fix_bugSwitched 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(-)- 修复完成后，切换到master分支，完成合并，最后删除fix_bug分支$ git checkout masterSwitched to branch 'master'$ git merge --no-ff -m "merge stable branch from fix_bug" fix_bugMerge made by the 'ort' strategy. SnowK.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)- 至此，bug已经修复完，可以继续回到dev分支进行开发，恢复之前的开发现场- 查看所有的存储情况：git stash list- 恢复现场并删除该stash：git stash pop- git stash apply也可以恢复现场- 但是恢复后，stash内容并不会删除，需要用git stash drop来手动删除$ git checkout devSwitched to branch 'dev'$ cat SnowK.txtHey I'm SnowK :PMay be bug?$ git stash liststash@{0}: WIP on dev: 2c93d33 Done$ git stash popOn branch devChanges 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.txtno changes added to commit (use "git add" and/or "git commit -a")Dropped refs/stash@{0} (122edfbb91bc4a378c38cb7b5bde9dcdf8a1cd61)$ cat SnowK.txtHey I'm SnowK :PMay be bug?dev: I'm codeing...
• 状态图梳理 && 实际开发中的建议- 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 deverror: The branch 'dev' is not fully merged.If you are sure you want to delete it, run 'git branch -D dev'.$ git branch -D devDeleted branch dev (was d009d1d).