哈尔滨网站建设咨询,最安全的软件下载网站,上海小程序开发报价,网站域名登录不了前言 那么这里博主先安利一些干货满满的专栏了#xff01; 首先是博主的高质量博客的汇总#xff0c;这个专栏里面的博客#xff0c;都是博主最最用心写的一部分#xff0c;干货满满#xff0c;希望对大家有帮助。 高质量博客汇总 然后就是博主最近最花时间的一个专栏…前言 那么这里博主先安利一些干货满满的专栏了 首先是博主的高质量博客的汇总这个专栏里面的博客都是博主最最用心写的一部分干货满满希望对大家有帮助。 高质量博客汇总 然后就是博主最近最花时间的一个专栏《Git企业开发控制理论和实操》希望大家多多关注 Git企业开发控制理论和实操 Git的分支管理 我们继续在上一章创建的本地仓库中继续进行分支的学习。 分支创建、切换、合并的简单尝试 git branch # 查看本地有哪些分支前面的*是什么 我们前面说到HEAD一开始是指向master的但HEAD不是只能指向master的而是可以指向其他分支。 然后被HEAD指向的分支才是工作分支。 如何创建一个本地的分支呢 git branch dev # 创建一个名为dev的分支发现多了一个dev 但此时HEAD还是指向master的。我们打印一下HEAD就能看到。 同样tree一下.git/也可以看到新建的dev 此时我们可以把dev和master的内容都打印一下。 我们知道master里面是上一次提交的commit id我们发现dev里面也是。所以现在分支的状态如下图所示。 两个“指针”都指向最新的提交HEAD指向master。 然后现在我想在dev分支上进行操作我们就要让HEAD指针指向dev而不是master。 git checkout dev通过这个命令可以把HEAD指向dev分支让dev成为工作分支。 现在的工作分支就是dev了。 现在我们对README.md文件进行一下修改。 然后提交。 此时的README.md(dev分支上的)是有hello branch的。 我们切换回master分支再看看README.md长啥样。 我们发现是没有hello branch的 因为我们刚才的修改在dev分支上。 刚才的这几个步骤的图示如下。 现在我们想要在master上也拿到dev上的代码那就要合并 注意现在是想要在master上获得dev的分支就是dev合并到master中注意表达和顺序是反过来是不一样的。 首先先要checkout到master上来。 git checkout master然后使用合并命令。 git merge dev # 合并我们看到这里面的Fast-forward表示快速提交。本质上就是把master的指针改一下就行了所以是很快的。 到后面我们会讲不是Fast-forward的情况。 流程就是这个样子的。 当然在这过程中还会存在很多的问题我们在后面再一一解释。 删除分支 我们在上一小节创建了dev分支然后做一些修改然后合并了。 意味着dev分支的使命已经结束了。我们就要删除dev分支。 git branch -d dev注意 只能在其他分支上删除分支也就是说我们不能在dev上删除dev分支否则会报错。 为什么需要分支 因为创建、合并和删除分支非常快所以Git鼓励你使用分支完成某个任务合并后再删掉分支这和直接在master分支上工作效果是一样的但过程更安全。 合并冲突 合并的时候是最容易出现问题的。 比如说现在有一个README.md文件创建dev分支后多加了一行bbb on dev branch master也没闲着也多加了一行ccc on dev branch 那git是不知道在合并的时候保留bbb的这一行还是保留ccc的这一行的。 这种情况叫做合并冲突。 我们先把上述的情况准备好。 其实有一行命令可以同时做到创建分支checkout到这个新创建的分支上。 git checkout -b dev1 # 创建dev1分支并切换到dev1分支下此时的状态就是这样的。 此时merge就会发生冲突我们来试一下。 合并失败。 此时git帮我们修改了一下代码如图所示把HEAD和dev1中的都放在一起了。 然后刚才的冲突提示是Automatic merge failed; fix conflicts and then commit the result. 因此就是让我们自己手动改一下然后重新提交。 所以现在我们选择保留bbb那一行直接删掉其他代码就行了。 重新提交后即可此时仓库的状态是这样的。 注意因为是master去merge了dev所以master此时是最新的提交也就是我们fix冲突后的提交但是此时dev依旧还是刚才dev的提交。 其实 git log 可以帮我们画这些图画给我们看。 git log --graph --abbrev-commit效果如下所示 (base) [yufcALiCentos7:~/Src/Bit-Courses/GitDevelopment/gitcode]$ git log --graph --abbrev-commit * commit ce635d4 |\ Merge: c007412 fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:51:22 2023 0800 | | | | fix conflict | | | * commit fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:42:45 2023 0800 | | | | bbb on dev1 | | * | commit c007412 |/ Author: Yufccode xxxqq.com | Date: Wed Aug 23 22:42:03 2023 0800 | | ccc on master | * commit 48cc733 | Author: Yufccode xxxqq.com | Date: Tue Aug 22 23:27:07 2023 0800 | | modify readme :...skipping... * commit ce635d4 |\ Merge: c007412 fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:51:22 2023 0800 | | | | fix conflict | | | * commit fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:42:45 2023 0800 | | | | bbb on dev1 | | * | commit c007412 |/ Author: Yufccode xxxqq.com | Date: Wed Aug 23 22:42:03 2023 0800 | | ccc on master | * commit 48cc733 | Author: Yufccode xxxqq.com | Date: Tue Aug 22 23:27:07 2023 0800 | | modify readme | * commit 130a873 | Author: Yufccode xxxqq.com | Date: Mon Aug 21 23:04:55 2023 0800 | | modify README.md | * commit f42df14 :...skipping... * commit ce635d4 |\ Merge: c007412 fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:51:22 2023 0800 | | | | fix conflict | | | * commit fd4e0b0 | | Author: Yufccode xxxqq.com | | Date: Wed Aug 23 22:42:45 2023 0800 | | | | bbb on dev1 | | * | commit c007412 |/ Author: Yufccode xxxqq.com | Date: Wed Aug 23 22:42:03 2023 0800 | | ccc on master | * commit 48cc733 | Author: Yufccode xxxqq.com | Date: Tue Aug 22 23:27:07 2023 0800 | | modify readme | * commit 130a873 | Author: Yufccode xxxqq.com | Date: Mon Aug 21 23:04:55 2023 0800 | | modify README.md | * commit f42df14 | Author: Yufccode xxxqq.com | Date: Mon Aug 21 12:26:23 2023 0800 | | my second add | :最上面的就是最新我们的操作。 合并模式 其实在这一章节里面我们的实验有两次merge分别对应了两种合并模式。 第一种其实就是Fast-forward模式前面讲过的。 第二种就是第二次我们merge需要解决冲突称为no-ff模式 在Fast forward模式下删除分支后查看分支历史时会丢掉分支信息看不出来最新提交到底是merge进来的还是正常提交的。 但在合并冲突部分我们也看到通过解决冲突问题会再进行一次新的提交。 no-ff模式这样的好处是从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支但依旧能看到 master 其实是由其他分支合并得到。 Git允许我们禁用Fast-forward模式。 git merge --no-ff -m merge dev2 dev # 禁用ff模式进行merge, 因为no-ff模式需要再次进行提交所以要-m带上提交的信息分支策略 首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活。 那在哪干活呢? 干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到master上在master分支发布1.0版本;你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。 所以团队合作的分支看起来就像这样 因此Git的分支功能是非常重要的 BUG分支 如果master上有bug呢 想象一种场景master正在运行然后dev2分支正在做开发但是还没有提交此时master突然出现bug了。 我们先模拟一下这种场景。 此时我们dev2分支上正在开发然后此时master遇到了bug。 能不能在dev2分支上处理bug呢肯定是不行的因为dev2分支是用来开发某个功能的。 那好现在我们就要切回去master上去处理但是此时我dev2上还没提交所以切过去处理我工作区的东西就不见了。所以需要一个命令先把dev2上工作区的内容先保存一下先然后再到master上去操作。 git stash # 暂时保存工作区的内容注意要保存dev2的内容HEAD就要在dev2上其实是保存到这里来了。 注意git stash命令只能暂存已经被git管理的文件因为README.md已经被git管理了所以可以用git stash暂存。但是如果你说现在touch一个new_file让git stash去暂存是不行的。 此时我们就要checkout到master上去处理bug了。 然后创建一个bug分支。 然后去修复bug。 此时的状态就是在fix_bug分支上bug已经被修复了master上还是bug然后dev2在做某项开发。 此时就要让master上的bug也被修复就是合并一下fix_bug分支。 此时我们的bug修复完了 此时我们要切回dev2分支继续进行开发。 此时我们工作区的内容在stash里面所以先把stash的东西放出来先。 git stash list # 这个命令可以显示stash里面有哪些内容git stash pop # 把stash里面的内容放出来恢复到工作区中但是此时dev2分支还是处于一个bug未修复的状态的不过没关系master已经修复了。 继续对dev2进行开发。 提交一下。 此时仓库的状态是这样的。 此时如果合并可能会出现问题。 如果我们合并我们就要手动解决冲突如果手动改代码就有可能会改出master的bug怎么办 所以此时我们一般这么办。 让dev2去合并master而不是master合并dev2然后在本地测试dev2把所有问题排除。然后让master去合并dev2此时这次合并就不需要解决冲突了 这种处理方式才是正确的处理方式 我们现在就来模拟这个过程。 这个就是整套流程 这就是工作中开发中比较好的流程 强制删除分支 设想开发中的一个场景 产品经理你给我新增一个功能 我好。我现在开始做 然后我就拉了一个dev分支开始做这个功能 开发到一半 产品经理算了这个功能取消了。 我… 好的。 那我就只能删除这个dev分支。 我们之前学的git branch -d 是merge之后删git是允许我们删的。 但是现在我在dev分支上做了若干commit了git是会保护我们的分支的不让删。 此时要用强制删除命令 git branch -D dev # 把-d改成-D就是强制删除当然还是要记得切到master上才能删dev