文章目录

3.1分支机制简述
- 3.1.1创建新分支
- 3.1.2切換分支
3.2基本的分支与合并操作
- 3.2.1基本的分支操作
- 3.2.2基本的合并操作
- 3.2.3基本的合并冲突处理
3.5远程分支
- 3.5.1推送
- 3.5.2跟踪分支
- 3.5.3拉取
- 3.5.4删除远程分支
3.6变基
- 3.6.1基本的变基操作

Git的分支模型
- 为Git的“杀手锏特性”
- 使Git从众多版本控制系统中脱颖
Git的分支功能轻量到极致
- 有关分支的操作几乎是即时完成
- 不同分支间切換也迅速
与其他版本控制系统不同
- Git鼓励工作流中
- 频繁用分支与合并
理解并掌握Git的这一特性,
- 就有一独一无二强大工具
- 可彻底改变你的开发方式

3.1分支机制简述

Git如何存储数据

Git没采用多个变更集或是差异的方式存储数据
- 而是用一系列快照

当你提交时,Git存储的是提交对象(commit object)
- 包含指向暂存区快照的指针
提交对象也包括
- 作者姓名和邮箱地址、
- 已输入的提交信息
- 指向其父提交的指针。
初始提交没有父提交、
- 一般的提交会有一个父提交
对两个或更多分支的合并提交来说,存在多个父提交

一个包含三个文件的目录,你把这些文件都加入到暂存区并提交
暂存操作会为每个文件计算校验和(1章的SHA-1散列值),
- 并把文件的当前版本保存到Git仓库(Git把这些数据叫作blob对象),然后把校验和添加到暂存区:

git commit时
- Git先为每个子目录计算校验和(本例只有项目根目录),
- 然后把这些树对象保存到Git仓库
Git随后创建提交对象
- 包括元数据及指向项目根目录的树对象的指针,
- 以便有需要的时候重新创建这次快照

Git仓库含5对象
- 3个blob对象(保存你的3个文件)
- 1个树对象(记录目录结构以及blob对象和文件名之间的对应关系)
- 1个提交对象(包含着提交的全部元数据和指向根目录树对象的指针)

如果你又做一些更改,
- 并又进行一次提交
第二次提交就保存指向它的上一次提交的指针

左边的最旧！

Git的分支
- 是指向某次提交的轻量级的可移动指针
Git默认的分支名
- master
当你提交时,就有了一个指向最后一次提交的master分支
每次提交时它都会自动向前移动

3.1.1创建新分支

创建新分支时会发生什么?
- Git会创建一个可移动的新指针供你用
创testing新分支

Git如何知道你当前处在哪一分支?
HEAD特殊指针
这里HEAD与你可能了解的其他版本控制系统(例如 Subversion或CVS)中的HEAD有很大不同
Git中,HEAD是一个指向当前所在的本地分支的指针
上例中,你仍处在master分支
git branch只创建新分支
- 不切到新分支

git log
- 査看各分支当前所指向对象
用到-- decorate

3.1.2切換分支

本地已經有master和master2分支
那git checkout master2
- 就直接切换到master2上
- 且他还告诉你master是跟踪的谁呢！

要切换到已有的分支
- git checkout
- 切换到新建testing分支
  - git checkout testing
  - 这条命令改变HEAD使其指向testing

这么做意义何在?
让我们再提交一次:

testing分支已向前移动,master仍指向你之前执行
- git checkout切换分支时所在的提交
再切到master

以上命令做两
把HEAD指针移回到master,
- 还把工作目录的文件恢复到master指向的快照的状态
这时起你做出的修改将基于项目的老版本
上述操作回滚了你在testing上所做的工作
- 使你能向另一个方向开发

和你没完！

3.2基本的分支与合并操作

3.2.1基本的分支操作

这时你要修复#53
-b的git checkout来创建并切到新分支

又进行几次提交
isss53分支指针向前移
- 当前检出的就是iss53分支(HEAD指针当前指向该分支)

网站有个问题需要立即修复
如果没有Git
- 你要么把你的修复补丁和iss53的変更一起部署,
- 花费大量精力去恢复之前针对is535所做的工作,
- 好让你制作的修复补丁单独上线
如今你要做的就是切换回master即可

此时工作目录就与你开始处理#53之前的一模一样,你就可集中精力制
作热补丁
切换分支时
- Git会把工作目录恢复到你切换到的分支上最后一次提交时的状态
接下来制作热补丁
- 创建hotfix分支并在这个分支上修复

运行测试来确保热补丁无误,将其合并到master分支
用 git merger

合并时出现“fast- forward”
- 当前所在的master分支所指向的提交是要并入的hotfix分支的直接上游,因而Git会将master分支指针向前移
当你试图去合并两个不同的提交,
- 顺着其中一个提交的历史可以直接到达另一个提交时、
- Git就简化合并操作
直接把分支指针向前移动,
- 这种单线历史不存在有分歧的工作

现在你的变更已进入了master分支指向的提交快照,
- 可部署补丁

部署热修复补丁后
- 要切換回之前被打断的工作上
你要把已经用不着的hotfix删除
该分支和 master分支指向位置相同

切换回之前未完成的#53分支

iss53分支不包含你在hotfix分支上的工作
如果需要把上述修补工作并入iss53
- 就需git merge master使master分支合并到iss53
- 或可等到要把iss53合并回master分支时再把热修补的工作整合进来

3.2.2基本的合并操作

设#53完工,可合并回master分支
这次的合并操作实现起来与之前合并 hotfix/分支的操作差不多。只需要切换到 master分支,并执行git merge

git merge 狗，把狗这个分支和我合并吧！

master指向的提交不是iss53的直接祖先
- Git必须要做一些额外的工作
本例Git执行三方合并
三方合并操作用两个待合并分支上最新提交的快照
- 及这两个分支的共同祖先的提交快照(如图3-16)

这次Git会基于三方合并的结果创建新的快照,然后再创建一个提交指向新建的快照。这个提交叫“合并提交”
合并提交的特殊性在于它拥有不止一个父提交

Git会判断最优的共同祖先并将其作为合并基础。
- 做法与诸如CVS或Subversion(1.5以前的版本)等较老的工具不同
较老的工具中,须自己找出最优的合并基础,来执行合并操作
以上区别使得Gi在合并操作方面比其他工具要简单

现在你的工作成果已经合并进来
- 就不再要iss53
你可以在问题追踪系统里面关闭这个问题并删除分支
s git branch -d iss53

3.2.3基本的合并冲突处理

如果你在要合并的两个分支上都改了同一个文件的同一部分内容
- Git没办法干浄合并这两分支
#53和在hotfix上的工作都修改了同一文件的同一部分
- 合并冲突

Git没自动创建新的合并提交
它会暂停整个合并,等待你来解决冲突。
合并冲突后,要看哪些文件没被合并,可git status

任何存在未解决的合并冲突的文件都会显示成未合并状态。
Git会给这些有冲突的文件添加标准的待解决冲突标记,
以便你手动打开这些文件来解决冲突
可看到冲突文件包含一个类似下面这样

HEAD版本的内容显示在上半部分(====以上),iss53分支的则在下半部分
HEAD指向master分支,因为你在执行 gerge命令之前已经切换到该分支
可选择使用任一版本的内容或是自己整合两者的内容来解决冲突
你可把整段内容替换成

实际上是把两个版本的内容各取一部分整合在一起,
- 并去掉<<<<、,==和>>>>这三行内容。
- 解决每个冲突文件的所有冲突部分后,就可执行git add把每个
  文件标记为冲突已解決状态。
  在Git中,这可以通过把文件添加到暂存区来实现

3.5远程分支

远程分支是指向远程仓库的分支的指针
- 这些指针存在于本地且无法被移动
当你与服务器进行任何网络通信时,它们会自动更新
远程分支像书签,它们会提示你上一次连接服务器时远程仓库中每个分支的位置

远程分支： (remote)/( branch)
如果想查看上次与服务器通信时远程origin仓库中的master分支,
- 就需査看origin/master分支
你与合作伙伴协同开发某需求
- 而他们将数据推送到iss53分支
- 这时你也可能有一个自己本地的iss53分支,但服务器端的分支其实指向的是origin/iss3

网络上的Git服务器,地址git.ourcompany. com。
你将内容从这台服务器上克隆到本地,Clone自动把这台服务器命名为origin,并拉取全部数据
- 在本地创建指向服务器上master分支的指针
- 命名为origin/ master
Git接着帮你创建你的本地master分支
这个分支一开始与 origin上的 master分支指向一样位置
- 这样你就可以在它上面开始工作

你在本地的 master分支上进一些工作,同时、別人向git.ourcompany.com推送数据,更新服务器上的 master分支
这时你的提交历史就与服务器上的历史产生了偏离
只要你不与服务器通信,你的origin/ master指针就不移动

要与服务器同步,需git fetch origin
查询“ongin”对应的服务器地址
- 从服务器取得所有本地尚未包含的数据,
- 更新本地数据库
- 把origin/master指针移动到最新的位置上

另一个供小组使用的内部Git服务器
- git.team1.ourcompany.com。
git remote add把它作为新的远程服务器添加到正在开发的项目
命名teamone

git fetch teamone获取teamone服务器上所有本地不存在的数据
teamone服务器上的数据在origin服务器上全部都有
Git不会真正拉取到数据,只创建teamone/master的远程分支,
- 指向 teamonel服务器上的master/分支的最新提交

3.5.1推送

同别人共享某个分支上的工作成果时
- 就要把它推送到一个具有写权限的远程仓库

serverfix的分支需要与其他人协作开发
只需git push( remote)( branch)

Git自动把分支名称serverfix扩展成refs/heads/
serverfix:refs/ heads/ serverfix
- 把本地的serverfix分支推送到远程的serverfix分支上
”第10章讲解refs/heads/含义,一般情况都可省略这部分
可git push origin serverfix: serverfix

如果你不想把远程分支命名为serverfix,
- 可执行git push origin serverfix: awesomebranch
- 本地serverfix推送到远程的 awesomebranch

git push origin 本地分支名字: 远程分治名字，而且如果远程分治名字不存在，那么就在远程仓库新建这个分

你的同事从服务器上拉取数据时,
- 就获取到一个指向服务器上 serverfix分支的指针
- 叫origin/serverfix

如果获取到了本地还没有的新的远程跟踪分支
Git不自动提供给你该分支的本地可编辑副本。
上述例子中,在本地就不会自动创建新的 serverfix分支,只拥有指向 origin/ serverfixl的指针,不能直接作出修改。

把该分支上的工作合并到你的当前工作分支,可git merge origin/ serverfix
你想要创建自己的本地 serverfix分支,以便在其上工作,可执行

这会基于 origin/ serverfix创建本地分支,使你可以在上工作

3.5.2跟踪分支

基于远程分支创建的本地分支会自动成为跟踪分支( tracking branch),或者有时候也叫作上游分支( upstream branch)

跟踪分支是与远程分支直接关联的本地分支
如果你正处在一个跟踪分支上并键入 git push
Git会知道要将数据推送到哪个远程服务器上的哪个分支。
git pull时Git也能够知道从哪个服务器上拉取数据,并与本地分支进行合并

克隆远程仓库时,默认自动创建跟踪着远程 origin/master分支的本地master。
也可选择自己设置其他的跟踪分支,比如跟踪其他远程服务器上的
分支,或是设置成不跟踪 master.分支
执行 git checkout -b[ branch][ remotename]/[ branch]。这种操作很常见,所以Git提供了-- track!的简略表达方式:

当你试图执行分支切换操作
如果该分支尚未被创建,并且该分支名称和某个远程分支名称一致,那么Gi会帮你创建跟踪分支。

让创建的本地分支的名称与对应的远程分支名称不一样
可用我们一开始提供的命令形式,来指定不同的本地分支名称

3.5.3拉取

git fetch拉取本地没有的远程所有最新更改数据,但完全不会更改你的工
作目录
只从服务器上读数据,让你自己合并。
git pull
- 大多数情況基本等同
- git fetch之后紧跟
- 执行git merge。
如果你有3.5.2节中演示过的跟踪分支(可手动设置,或是通过 Clone:或 checkout得到),、
- git pull时
- Git就读取上游服务器和分支上的数据,
- 并尝试着将远程分支上的修改合并到本地

显式直接用fetch和 merge比用git pul要更好,
git pull的机制会常常使人迷

3.5.4删除远程分支

git push的–delete删除远程分支。
如果需要删除远程服务器上的 serverfix分支

以上命令只删除远程服务器上的分支指针
Git会保留数据一段时间直到下一次触发垃圾回收。
即使误删分支,一般也很容易恢复

3.6变基

要把更改从一个分支整合到另一分支
- 两种主要方式:merge和rebase

什么是变基、如何使用变基、变基的强大之处
变基操作不适用的场景

3.6.1基本的变基操作

3.2.2节中的例
提交历史产生偏离,
- 两个不同的分支上分别都进行提交

merge对两个分支上的最新提交快照(3和4)及这两个提交快照最近的共同祖先(2).进行三方合并
并创建一个新的合并提交

你可把C4提交的更改以补丁形式应用到C3提交
Git中,这就叫变基
把某个分支上所有提交的更改在另一个分支上重现一遍

找到两个要整合的分支(当前所在的分支和要整合到的分支)的祖先
- C2把！
- 当前分支是experiment分支
- 要整合到的分支是master分支
取得当前所在分支的每次提交引人的更改(diff)
- 并把这些更改保存为临时文件
- 取得experiment分支所做的更改啊!
- 之后将当前分支重置为要整合到的分支
- 将当前分支搞成master分支，然后继续搞成了experiment啦！
- 最后在该分支上依次引入之前保存的每个更改

简而言之：就是把experiment这个分支上上的更改应用到master分支吧！！！

变基变基，就是重新冒出来一个experiment这个分支，他的祖宗是C3而不是C2了哈哈哈！，rebase master，就是以master这个分支为祖宗了！！！

3 ：git分支机制相关推荐

精通Git（三）——Git分支机制
文章目录前言分支机制简述创建分支切换分支基本的分支与合并操作基本的分支操作基本的合并操作基本的合并冲突处理分支管理与分支有关的工作流长期分支主题分支远程分支推送跟踪分支 ...
Git 分支操作、Git 团队协作机制、GitHub 操作
文章目录第 4 章 Git 分支操作 4.1 什么是分支 4.2 分支的好处 4.3 分支的操作 4.3.1 查看分支 4.3.2 创建分支 4.3.3 修改分支 4.3.4 切换分支 4.3.5 ...
【分布式版本控制系统Git】| Git 分支操作、Git 团队协作机制、GitHub 操作
目录一:Git 分支操作 1. 什么是分支 2. 分支的好处 3. 分支的操作二:Git 团队协作机制 1. 团队内协作 2. 跨团队协作三:GitHub 操作 1. 创建远程仓库 2. 远程仓 ...
git学习（六）git数据管理机制，分支管理
学习笔记来自B站尚硅谷视频:https://b23.tv/BV1pW411A7a5 若侵权则删哈希算法简介(SHA-1) 各个哈希算法的共同点: 是一种加密算法不管文件多大,加密之后得到的结果长 ...
关于git pull机制和游戏开发热更新思考
前言今天由于网速很慢,在git pull更新时我观看了git pull的日志,让我联想到和我现在从事的游戏开发中的热更热有一定的相似性,把思绪记录下来. git pull 日志使用tortoi ...
【收藏资源】Git分支模型(master/hotfix/develop/feature/release)
1.分支管理 1.1 总览(一张流程图给大家先镇镇惊) 它主要体现了Git对我们源代码版本的管理. (转载者加)一般情况: ● master和develop并行. ● master上始终是最稳定的代码 ...
成功的 Git 分支模型
介绍一个成功的 Git 分支模型(master - hotfix - develop - feature - release) 2015-12-23 12:17 本站整理浏览(311) 英文原文:A ...
介绍一个成功的 Git 分支模型——终于知道如何管理git分支了（好文章！！强烈建议看本文的英文原文）
本文翻译转载自:https://www.oschina.net/translate/a-successful-git-branching-model 英文原文在2020年3月5日有更新(强烈建议看英文 ...
介绍一个成功的 Git 分支模型
为什么80%的码农都做不了架构师?>>> 在这篇文章中,我提出一个开发模型.我已经将这个开发模型引入到我所有的项目里(无论在工作还是私人)已经一年有余,并且它被证明是非常成功的 ...

3 ：git分支机制