济南网络建站模板,wordpress 畅言 右下角链接,免费安装电脑wordpress,动漫制作与设计专业git的基础操作以及常用命令在上篇博客哦~ git原理与基本使用
1.分支管理
1.主分支
在版本回退⾥#xff0c;我们已经知道#xff0c;每次提交#xff0c;Git都把它们串成⼀条时间线#xff0c;这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前#xff0c;只有⼀条时间线我们已经知道每次提交Git都把它们串成⼀条时间线这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前只有⼀条时间线在Git⾥这个分⽀叫主分⽀即 master 分⽀ HEAD 严格来说不是指向提交⽽是指向mastermaster才是指向提交的所以HEAD 指向的就是当前分⽀ 主线可以理解为master主分支根据master就可以获得这条时间线 既然存在主分支那么是不是也存在其他的分支就像下面这样
2.分支管理命令
1.查看当前本地所有分支
# 查看当前本地所有分支
git branch创建本地仓库会创建一个master分支此时HEAD默认指向master分支但是HEAD并非只能指向master分支 HEAD可以指向任意分支HEAD所指的分支才是当前的工作分支
2.创建分支
# 新建一个dev分支
git branch [分支名]dev指向最新提交是因为dev是在当前版本上创建的分支
3.将HEAD指向指定分支
# 切换HEAD指针到指定分支
git checkout [分支名]
# 查看当前HEAD所指分支
git branch此时就如下图所示
4.在分支上修改文件并将其提交至版本库
# 修改ReadeMe文件
vim Reade
# 保存并推出
:wq
# 提交至暂存区
git add ReadeMe
# 提交至版本库
git commit -m在dev上的commit
# 此时切换回master分支
git checkout master
# 查看当前所指分支
git branch
# 查看ReadeMe文件
cat ReadeMe
// 此时发现在dev分支上添加的代码不见了
# 切换回dev分支
git checkout dev
# 重新查看ReadeMe文件
cat ReadeMe
// 此时发现修改的文件又回来了,那么这是因为什么呢因为我们是在dev分⽀上提交的⽽master分⽀此刻的提交点并没有变查看.git文件中的Head指向就可以发现master分支依然指向之前HEAD指向master时的最新版本如下图所示
5.合并分支
为了在 master 主分⽀上能看到新的提交就需要将 dev 分⽀合并到 master 分⽀
# 将HEAD指向master分支
git checkout master
# 在master分支下合并分支dev
git merge dev
# 在master分支下查看ReadeMe文件
cat ReadeMe
// 此时发现可以看见最新的修改了Fast-forward 代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度⾮常快 当然也不是每次合并都能 Fast-forward我们后⾯会讲其他⽅式的合并 合并后master 就能看到 dev 分⽀提交的内容了此时的状态如图如下所⽰
6.删除分支
合并完成后, dev 分⽀对于我们来说就没⽤了 那么dev分⽀就可以被删除掉注意如果当前正处于某分⽀下就不能删除当前分⽀
# 切换当前HEAD指向master分支
git checkout master
# 在master分支上删除dev分支
git branch -d dev
# 查看当前所有分支
git branch
// 此时就只剩下master分支了此时的状态如图如下所⽰: 因为创建、合并和删除分⽀⾮常快所以Git⿎励你使⽤分⽀完成某个任务合并后再删掉分⽀这和直接在master分⽀上⼯作效果是⼀样的但过程更安全
7.分支冲突
可是在实际分⽀合并的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题
我们按照下面的步骤进行操作
# 创建本地分支dev1
git branch dev1
# 切换dev1分支
git checkout dev1
# 上面两行操作可以合并成一个创建并且切换分支
git checkout -b dev1
# 修改ReadeMe文件为dev1
vim ReadeMe
# 将ReadeMe文件提交至暂存区
git add ReadeMe
# 将ReadeMe文件提交至版本库
git commit -m在dev1中修改ReadeMe为dev1dev1
# 此时切换为master分支
git checkout master
# 在master分支下修改ReadeMe文件为master
vim ReadeMe
# 将ReadeMe文件提交至暂存区
git add ReadeMe
# 将ReadeMe文件提交至版本库
git commit -m在master中修改ReadeMe为master此时状态如下图所示
# 现在我们合并的时候git就没办法知晓我们到底需要保存哪个版本的文件就会发生合并冲突
git merge dev1 这种情况下Git 只能试图把各⾃的修改合并起来但这种合并就可能会有冲突就像下面这样 此时我们查看ReadeMe文件就会发现
8.手动解决冲突
# 打开ReadeMe文件,手动修复文件
vim ReadeMe
# 将ReadeMe文件提交至暂存区
git add ReadeMe
# 将ReadeMe文件提交至版本库
git commit -m在master中修改ReadeMe为master不要忘了提交哦到这⾥冲突就解决完成此时的状态变成了 最后不要忘记 dev1 分⽀使⽤完毕后就可以删除了
# 在master分支上删除dev1分支
git branch -d dev19.git log参数意义
# 查看历史提交日志
# --graph 图示的意思
# --abbrev-commit 将commit id缩写
git log --graph --abbrev-commit10.分⽀管理策略
通常合并分⽀时如果可能Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后形成的合并结果是什么呢回顾⼀下: 在这种 Fast forward 模式下删除分⽀后查看分⽀历史时会丢掉分⽀信息看不出来最新提交到底是 merge 进来的还是正常提交的 但在合并冲突部分我们也看到通过解决冲突问题会再进⾏⼀次新的提交得到的最终状态为 那么这就不是 Fast forward 模式了这样的好处是从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev 分⽀但依旧能看到 master 其实是由其他分⽀合并得到
11.不使用Fast forward进行合并建议使用
Git ⽀持我们强制禁⽤ Fast forward 模式那么就会在 merge 时⽣成⼀个新的 commit 这样从分⽀历史上就可以看出分⽀信息
# --no--ff 不使用Fast forward进行合并
# -m 并且进行提交
git merge --no-ff -m提交时的信息 [需要合并的分支]可以看到不使⽤ Fast forward 模式merge后就像下图这样 所以在合并分⽀时加上 --no-ff 参数就可以⽤普通模式合并合并后的历史有分⽀能看出来曾经做过合并⽽ fast forward 合并就看不出来曾经做过合并
2.分⽀策略
1.团队合作分支管理 在实际开发中我们应该按照⼏个基本原则进⾏分⽀管理 ⾸先master分⽀应该是⾮常稳定的也就是仅⽤来发布新版本平时不能在上⾯⼲活 那在哪⼲活呢 ⼲活都在dev分⽀上也就是说dev分⽀是不稳定的到某个时候⽐如1.0版本发布时再把dev分⽀合并到master上在master分⽀发布1.0版本 你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活每个⼈都有⾃⼰的分⽀时不时地往dev分⽀上合并就可以了。 所以团队合作的分⽀看起来就像这样
2.bug 分⽀ 假如我们现在正在 dev2 分⽀上进⾏开发开发到⼀半突然发现 master 分⽀上⾯有 bug需要解决。在Git中每个 bug 都可以通过⼀个新的临时分⽀来修复修复后合并分⽀然后将临时分⽀删除 可现在 dev2 的代码在⼯作区中开发了⼀半还⽆法提交怎么办
# 切换到dev2分支上
git checkout dev2
# 在dev2分支上开发代码
vim ReadeMe
# 切换到master分支
git checkout master
# 查看ReadeMe文件
cat ReadeMe此时我们发现master分支上可以看见dev2分支对ReadeMe文件的修改 因为是在工作区中查看并且master和dev2指向同一个版本 但是我们不想让dev2影响到master分支应该怎么办呢
3.将工作区中的信息进行储藏 Git 提供了 git stash 命令可以将当前的⼯作区信息进⾏储藏被储藏的内容可以在将来某个时间恢复出来 # 切换到dev2分支
git checkout dev2
# 将dev2工作区中的内容保存
git stash
# 查看工作区状态
git status储藏 dev2 ⼯作区之后由于我们要基于master分⽀修复 bug所以需要切回 master 分⽀再新建临时分⽀来修复 bug # 切换到master分支
git checkout master
# 创建并切换分支
git checkout -b fix_bug
# 修复BUG
vim ReadeMe
# 别忘记add以及commit
git add ReadeMe
git connit -m修复BUG版本
# 切换回master
git checkout master
# 不使用fast合并分支
git merge --no-ff -m修复bug fix_bug
# 查看ReadeMe
cat ReadeMe
# 删除分支
git branch -d fix_bug
# 切换回dev2分支
git checkout dev2
# 查看文件
cat ReadeMe⼯作区是⼲净的刚才的⼯作现场存到哪去了⽤ git stash list 命令看看
# 查看存储区
git stash list⼯作现场还在Git 把 stash 内容存在某个地⽅了但是需要恢复⼀下如何恢复现场呢我们可以使⽤ git stash pop 命令恢复的同时会把 stash 也删了
4.恢复存储区的代码
# 恢复存储区的代码
git stash pop另外恢复现场也可以采⽤ git stash apply 恢复但是恢复后stash内容并不删除你需要⽤ git stash drop 来删除 但我们注意到了修复 bug 的内容并没有在 dev2 上显⽰。此时的状态图为 Master 分⽀⽬前最新的提交是要领先于新建 dev2 时基于的 master 分⽀的提交的所以我们在 dev2 中当然看不⻅修复 bug 的相关代码 我们的最终⽬的是要让 master 合并 dev2 分⽀的那么正常情况下我们切回 master 分⽀直接合并即可但这样其实是有⼀定⻛险的 是因为在合并分⽀时可能会有冲突⽽代码冲突需要我们⼿动解决在 master 上解决。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉因为在实际的项⽬中代码冲突不只⼀两⾏那么简单有可能⼏⼗上百⾏甚⾄更多解决的过程中难免⼿误出错导致错误的代码被合并到 master 上。 此时的状态为: 解决这个问题的⼀个好的建议就是最好在⾃⼰的分⽀上合并下 master 再让 master 去合并dev 这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试⽽不影响 master 。此时的状态为
5.修复bug流程
# 将dev2上的代码进行存储
git stash
# 切换到master分支
git checkout branch
# 新建一个修复bug的分支并切换到bug分支上
git checkout -b fix_bug
# 在bug分支上修复bug
vim ReadeMe
# 别忘记add和commit
git add ReadeMe
git commit -m修复bug
# 切换回master分支
git checkout master
# 不使用master合并修复bug的分支
git merge --no-ff -m合并bug分支 fix_bug
# bug修复完成删除fix_bug分支
git branch -d fix_bug
# 回到dev2工作分支
git checkout dev2
# 恢复存储
git stash pop
# 开发完成进行提交
git add ReadeMe
git commit -m在dev2上开发完成ReadeMe
# 在dev2分支合并master
git merge --no-ff -m在dev2分支上合并master master
# 切换到master
git checkout master
# 在master分支上合并dev2
git merge --no-ff -m在master分支上合并dev2 dev2
# bug修复彻底完成6.删除临时分⽀ 如果我们今天正在某个 feature 分⽀上开发了⼀半被产品经理突然叫停说是要停⽌新功能的开发。虽然⽩⼲了但是这个 feature 分⽀还是必须就地销毁留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的 这时候把d改成D就可以强制删除成功了
# 强制删除分支
git branch -D [分支名]7.总结分支的作用 分⽀在实际中有什么⽤呢假设你准备开发⼀个新功能但是需要两周才能完成第⼀周你写了50%的代码如果⽴刻提交由于代码还没写完不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交⼜存在丢失每天进度的巨⼤⻛险。 现在有了分⽀就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀别⼈看不到还继续在原来的分⽀上正常⼯作⽽你在⾃⼰的分⽀上⼲活想提交就提交直到开发完毕后再⼀次性合并到原来的分⽀上这样既安全⼜不影响别⼈⼯作。 并且 Git ⽆论创建、切换和删除分⽀Git在1秒钟之内就能完成⽆论你的版本库是1个⽂件还是1万个⽂件
