目录
- 1.合并冲突
- 2.分支管理策略
- 3.分支策略
- 1.基本原则
- 2.bug分支
- 3.删除临时分支
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.
-
解决方案:在发生冲突的文件内手动调整解决,并进行一次 修改 && 提交 操作
- Git会用
<<<<<<<, =======, >>>>>>>
来标记出不同分支的冲突内容$ cat dev.txt I'm in dev_branch :P <<<<<<< HEAD From 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会用
-
git log
添加--graph --abbrev-commit
参数可以看到分支的合并情况
2.分支管理策略
-
通常合并分⽀时,如果可能,Git会采⽤
Fast forward
模式- 换句话说,只要条件允许,Git就会尽可能地采用
Fast forward
模式
- 换句话说,只要条件允许,Git就会尽可能地采用
-
但是如果采用
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
- 在
-
在合并冲突时,通过手动调整解决冲突,会再进行一次 修改 && 提交 操作
- 此时就不是
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
- 例如:已经删除了
- 此时就不是
-
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
- 解决方案:使用
- 实际操作流程:
- 切回
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(-)
- 修复完成后,切换到
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(-)
- 至此,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...
- 查看所有的存储情况:
- 切回
- 状态图梳理 && 实际开发中的建议
-
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).