git分支原理命令图文解析

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: <div class="markdown_views"><h1 id="本地分支解析">本地分支解析</h1><p>git 通过可变指针来实现对提交数据的历史版本的控制,每当我们提交新的更新,当前分支(设为master)则指向最后一个提交更新A,而最后一个提交对象则存在一个指针指向前一次的提交更新Q。如果我们创建一个新的分支,child,它和master共同指向A,这时,

本地分支解析

git 通过可变指针来实现对提交数据的历史版本的控制,每当我们提交新的更新,当前分支(设为master)则指向最后一个提交更新A,而最后一个提交对象则存在一个指针指向前一次的提交更新Q。如果我们创建一个新的分支,child,它和master共同指向A,这时,如果我们向child分支提交更新B,我们会发现child指向B,而master依然指向A。无论我们在child分支进行了任何开发,只要回到master分支,就能恢复到更新A的数据状态了。
这里写图片描述
在图片里,我们还注意到有一个head指针,一般来说,它会指向我们目前所在的工作分支。现在它指向了我们的master分支,意思是master是我们目前的工作分支。一旦提交更新,就会在master分支上提交。现在,让我们看看与git分支有关的操作命令:
1. git branch [option] [name]
如果不使用任何参数,它可以用来查看所有的分支,而在分支名前有*标记的则为主分支,如果加上name为创建新分支,,如git branch child,则会创建一个名为child的分支,此外,它有一些常用的参数:

参数 解释
-v 用于查看各个分支的最后一次commit信息
-d 删除分支。
-r 查看远程主机分支
-a 查看所有分支。
–merge 查看哪些分支已被当前分支合并
–no-merge 查看尚未合并的工作,如果其中的分支还包含尚未合并的工作,而我们尝试使用git branch -d 删除时,我们会被提示:error: The branch 'xxxxx' is not an ancestor of your current HEAD.,如果想要强制删除的话,可以使用git branch -D xxxxx,即使用大写的D来实现。

2. git checkout [name]
切换到对应的分支,对于上图,如果我们是使用 git checkout child,我们的head指针就会指向child分支了。这时候,如果我们提交新的更新D,我们会发现:
这里写图片描述
我们的D指向C,而C依然指向A,也就是说,以后我们在child分支上做的任何更新,都不会对master分支所在的之路造成任何影响!一旦使用了checkout命令,我们还会发现,不仅head指针会指向新的分支,而且当前工作目录中的文件也会换成了新分支对应的文件了。
此外,我们还可以使用git checkout -b [name]命令,它会新建一个分支,并自动将当前的工作目录切换到该分支上。
3. git merge [name]
合并分支,有的时候,我们创建次要分支,可能是为了修改原有程序的bug,或为了拓展新的功能,这时候如果我们想把次要分支的修改何并进主分支中,我们可以使用git merge 命令来实现。
1. “Fast forward”(快进)式合并:
如果像上图所示,我们要把child分支合并进master中,因为child分支所指向的更新在master分支的直接上游,git会使用“Fast forward”(快进)式合并,直接将master分支指针指向child分支所指向更新,如下图所示:
这里写图片描述
这时候,如果我们觉得child分支没什么用了,我们可以使用git branch -d child来删除分支。

2. 基本合并
如果我们这次要合并的分支不在我们目前分支的上游,如下图所示:

这里写图片描述
这时,如果使用快进式合并(将master分支指向更新E),这样就会丢失更新D了,于是,我们采用另一种合并方式,它的合并结果如下图所示:
这里写图片描述
我们会发现,此时master分支所指向的合并更新F出现了两个祖先。
3. 冲突合并
基本合并的冲突源于两个分支间的所指向的版本更新不能根据箭头方向从一方抵达另一方,即两个分支在更新C单向分岔了,但我们还发现,更新C、A、Q还是master和child分支的共同父更新,如果两个分支都对C或A或Q版本的相同文本相同位置做了不同的修改,git就无法智能地将两者合并一起,因为它不能判断master的修改和child的修改哪个是更佳的,事实上,这个只能由人来解决。比如两个分支共同修改了版本C中的README文件的第1行:

1 master: I’m master!
2 child: I’m child!

当我们尝试从master上合并child时,会出现:

$ git merge child
自动合并 README
冲突(内容):合并冲突于 README
自动合并失败,修正冲突然后提交修正的结果。
或英文版的:
Auto-merging README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
这时调用git status命令,会看到:
$ git status
位于分支 master
您有尚未合并的路径。
(解决冲突并运行 “git commit”)

未合并的路径:
(使用 “git add …” 标记解决方案)

双方修改: README
或英文版的:
$ git status
README: needs merge
On branch master
Changed but not updated:
(use “git add …” to update what will be committed)
(use “git checkout – …” to discard changes in working directory)

unmerged:
README
这时候我们打开README文件,就会看到:
1 <<<<<<< HEAD
2 I’m master
3 =======
4 I’m child!
5 >>>>>>> child
“=======”分开了两个分支的冲突部分,'''<<<<<<<HEAD为主分支的,而>>>>>>>child上面就是要合并部分的了。这时候,我们需要修改冲突部分,比如改成
1 I'master and child!
修改完后,我们还需要通过git add 和git commit来提交对冲突的修改,这样。我们就完成了这次冲突合并了!

远程分支解析

  1. git fetch [远程主机名] [远程分支名][:本地分支名]
    如果不指定分支名,会获取远程主机的全部最新更新。如果指定了分支,则获取该分支的最新更新,如果还指定了本地分支名,则会新建对应的分支来来保存远程分支的所有数据。此时获取的更新会放在“远程主机昵称/远程分支名”这样的分支上,如origin/master,如果像要合并到我们本地分支master,需要使用git merge命令,但此时需考虑之前提到的合并冲突问题。
  2. git pull [远程主机名] [远程分支名][:本地分支名]
    先从远程主机的特定分支获取更新,并合并到本地分支上,如果不指定本地分支,则默认合并到当前分支上,如果当前分支与远程分支(从远程分支检出的本地分支)存在追踪关系,git pull就可以省略远程分支名
  3. git branch –set-upstream [本地分支名] [远程主机名/远程分支名]
    如果我们想要手动建立本地分支和远程分支的跟踪关系,可以使用此指令
  4. git push [远程主机名] [本地分支]:[远程分支]
    1. 如果省略远程主机名,则将其推送到具有跟踪关系的远程分支上,如果远程分支不存在,则会新建。
    2. 如果省略本地分支,则相当推送一个空的分支当远程分支,即会删除远程分支。
    3. 如果当前分支和远程分支存在跟踪关系,则可以忽略本地/远程分支名
    4. 如果当前分支只有一个追踪的远程分支,则可以把远程主机名,本地/远程分支名都省略掉
    5. 不带任何参数的git push,默认只推送当前分支,这叫做simple方式(Git 2.0版本后的默认模式)。此外,还有一种matching方式,会推送所有有对应的远程分支的本地分支。如果需要修改默认配置,git config –global push.default simple/default来设置
    6. 如果不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机,可以使用–all参数,如:
      $ git push –all origin
      上面命令表示,将所有本地分支都推送到origin主机
目录
相关文章
|
29天前
|
开发工具 git
git 常用命令
这些只是 Git 命令的一部分,Git 还有许多其他命令和选项,可根据具体需求进行深入学习和使用。熟练掌握这些命令能够帮助你更高效地管理代码版本和协作开发。
|
21天前
|
机器学习/深度学习 Shell 网络安全
【Git】Git 命令参考手册
Git 命令参考手册的扩展部分,包含了从基础操作到高级功能的全面讲解。
29 3
|
1月前
|
缓存 Java Shell
[Git]入门及其常用命令
本文介绍了 Git 的基本概念和常用命令,包括配置、分支管理、日志查看、版本回退等。特别讲解了如何部分拉取代码、暂存代码、删除日志等特殊需求的操作。通过实例和图解,帮助读者更好地理解和使用 Git。文章强调了 Git 的细节和注意事项,适合初学者和有一定基础的开发者参考。
53 1
[Git]入门及其常用命令
|
2月前
|
开发工具 git
git学习四:常用命令总结,包括创建基本命令,分支操作,合并命令,压缩命令,回溯历史命令,拉取命令
这篇文章是关于Git常用命令的总结,包括初始化配置、基本提交、分支操作、合并、压缩历史、推送和拉取远程仓库等操作的详细说明。
143 1
git学习四:常用命令总结,包括创建基本命令,分支操作,合并命令,压缩命令,回溯历史命令,拉取命令
|
1月前
|
开发工具 git 开发者
|
1月前
|
开发工具 git 开发者
提升Git效率:掌握这5个高级命令
【10月更文挑战第17天】
65 0
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
76 2
|
2月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
80 0
|
2天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
2天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析

相关实验场景

更多