杭州大的做网站的公司,沈阳seo代理计费,软件开发在大学属于什么专业,东莞网站建设优化技术#x1f4d8;北尘_#xff1a;个人主页 #x1f30e;个人专栏:《Linux操作系统》《经典算法试题 》《C》 《数据结构与算法》 ☀️走在路上#xff0c;不忘来时的初心 文章目录 一、理解分⽀二、创建分支三、切换分⽀四、合并分⽀五、删除分⽀六、合并冲突七、分⽀管理策略… 北尘_个人主页 个人专栏:《Linux操作系统》《经典算法试题 》《C》 《数据结构与算法》 ☀️走在路上不忘来时的初心 文章目录 一、理解分⽀二、创建分支三、切换分⽀四、合并分⽀五、删除分⽀六、合并冲突七、分⽀管理策略八、分⽀策略 一、理解分⽀
本章开始介绍 Git 的杀⼿级功能之⼀注意是之⼀也就是后⾯还有之⼆之三……分⽀。分⽀就是科幻电影⾥⾯的平⾏宇宙当你正在电脑前努⼒学习 C 的时候另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。 如果两个平⾏宇宙互不⼲扰那对现在的你也没啥影响。不过在某个时间点两个平⾏宇宙合并了结果你既学会了 C ⼜学会了 JAVA 在版本回退⾥你已经知道每次提交Git都把它们串成⼀条时间线这条时间线就可以理解为是一个分⽀。截⽌到⽬前只有⼀条时间线在Git⾥这个分⽀叫主分⽀即 master 分⽀。 再来理解⼀下HEADHEAD 严格来说不是指向提交⽽是指向mastermaster才是指向提交的所以HEAD 指向的就是当前分⽀。 每次提交master分⽀都会向前移动⼀步这样随着你不断提交master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。 通过查看当前的版本库我们也能清晰的理出思路 二、创建分支 Git ⽀持我们查看或创建其他分⽀在这⾥我们来创建第⼀个⾃⼰的分⽀ dev 对应的命令为 当我们创建新的分⽀后Git 新建了⼀个指针叫 dev * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外可以通过⽬录结构发现新的 dev 分⽀ 发现⽬前 dev 和 master 指向同⼀个修改。并且也可以验证下 HEAD ⽬前是指向 master 的 ⼀张图总结 三、切换分⽀ 那如何切换到 dev 分⽀下进⾏开发呢使⽤ git checkout 命令即可完成切换⽰例如下 我们发现 HEAD 已经指向了 dev就表⽰我们已经成功的切换到了 dev 上 接下来在 dev 分⽀下修改 ReadMe ⽂件新增⼀⾏内容并进⾏⼀次提交操作 现在dev 分⽀的⼯作完成我们就可以切换回 master 分⽀ 切换回 master 分⽀后发现ReadMe⽂件中新增的内容不⻅了赶紧再切回 dev看看 在 dev 分⽀上内容还在。为什么会出现这个现象呢我们来看看 dev 分⽀和 master 分⽀指向发现两者指向的提交是不⼀样的 看到这⾥就能明⽩了因为我们是在dev分⽀上提交的⽽master分⽀此刻的提交点并没有变此时的状态如图如下所⽰ 当切换到 master 分⽀之时HEAD 就指向了 master当然看不到提交了 四、合并分⽀ 为了在 master 主分⽀上能看到新的提交就需要将 dev 分⽀合并到 master 分⽀⽰例如下 git merge 命令⽤于合并指定分⽀到当前分⽀。合并后master 就能看到 dev 分⽀提交的内容了。此时的状态如图如下所⽰。 Fast-forward 代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度⾮常快。 当然也不是每次合并都能 Fast-forward我们后⾯会讲其他⽅式的合并。 五、删除分⽀ 合并完成后, dev 分⽀对于我们来说就没⽤了 那么dev分⽀就可以被删除掉注意如果当前正处于某分⽀下就不能删除当前分⽀如 ⽽可以在其他分⽀下删除当前分⽀如 此时的状态如图如下所⽰。 因为创建、合并和删除分⽀⾮常快所以Git⿎励你使⽤分⽀完成某个任务合并后再删掉分⽀这和直接在master分⽀上⼯作效果是⼀样的但过程更安全。 六、合并冲突 可是在实际分⽀合并的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题。 为了演⽰这问题创建⼀个新的分⽀ dev1 并切换⾄⽬标分⽀我们可以使⽤ git checkout -b dev1 ⼀步完成创建并切换的动作⽰例如下 在 dev1 分⽀下修改 ReadMe ⽂件更改⽂件内容如下 aaa改成 bbb 并进⾏⼀次提交如 切换⾄ master 分⽀观察 ReadMe ⽂件内容 我们发现切回来之后⽂件内容由变成了⽼的版本这种现象很正常我们现在也完全能理解。 此时在 master 分⽀上我们对 ReadMe ⽂件再进⾏⼀次修改并进⾏提交如下 现在 master 分⽀和 dev1 分⽀各⾃都分别有新的提交变成了这样 这种情况下Git 只能试图把各⾃的修改合并起来但这种合并就可能会有冲突如下所⽰ 发现 ReadMe ⽂件有冲突后可以直接查看⽂件内容要说的是 Git 会⽤ 来标记出不同分⽀的冲突内容如下所⽰ 此时我们必须要⼿动调整冲突代码并需要再次提交修正后的结果再次提交很重要切勿忘记 到这⾥冲突就解决完成此时的状态变成了 ⽤带参数的 git log也可以看到分⽀的合并情况具体⼤家可以⾃⾏搜索 git log 的⽤法 最后不要忘记 dev1 分⽀使⽤完毕后就可以删除了 七、分⽀管理策略
通常合并分⽀时如果可能Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后形成的合并结果是什么呢 在这种 Fast forward 模式下删除分⽀后查看分⽀历史时会丢掉分⽀信息看不出来最新提交到底是 merge 进来的还是正常提交的。 但在合并冲突部分我们也看到通过解决冲突问题会再进⾏⼀次新的提交得到的最终状态为 那么这就不是 Fast forward 模式了这样的好处是从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀但依旧能看到 master 其实是由其他分⽀合并得到 Git ⽀持我们强制禁⽤ Fast forward 模式那么就会在 merge 时⽣成⼀个新的 commit 这样从分⽀历史上就可以看出分⽀信息。 下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先创建新的分⽀ dev2 并切换⾄新的分支 修改 ReadMe ⽂件并提交⼀个新的 commit 切回 master 分⽀开始合并 请注意 --no-ff 参数表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit 所以加上 -m 参数把描述写进去。 合并后查看分⽀历史 可以看到不使⽤ Fast forward 模式merge后就像这样 所以在合并分⽀时加上 --no-ff 参数就可以⽤普通模式合并合并后的历史有分⽀能看出来曾经做过合并⽽ fast forward 合并就看不出来曾经做过合并。 八、分⽀策略
在实际开发中我们应该按照⼏个基本原则进⾏分⽀管理 ⾸先master分⽀应该是⾮常稳定的也就是仅⽤来发布新版本平时不能在上⾯⼲活 那在哪⼲活呢⼲活都在dev分⽀上也就是说dev分⽀是不稳定的到某个时候⽐如1.0版本发布时再把dev分⽀合并到master上在master分⽀发布1.0版本 你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活每个⼈都有⾃⼰的分⽀时不时地往dev分⽀上合并就可以了。 所以团队合作的分⽀看起来就像这样
