本文共 5405 字，大约阅读时间需要 18 分钟。

2019/07/23 git分支及分布式协作(03)

26/100 发布文章 qq_42227818

git是一个内容追踪系统，目录历史管理系统

核心内容主要作为对象来存储，对象存储系统

主要有四类对象：文件blob对象，

目录组织结构tree对象(一个树本身)，

保存目录层级结构用提交commit对象

标签对象tag，用于提交对象设置一个别名

每一个目录对象只存储这个目录之下能够直接找到的文件和一级子目录

现在又blob方块文件对象，两个目录tree树对象，对第二个树对象保存的仅仅是两个文件对象

整体的层级结构记录下来，整棵树的状态记录下来，就是一个提交对象

提交对象加一个别名方便引用，提交仅仅是指向了整个项目的根树对象，

这个根树对象，保留了提交的那一刻的数据，子目录和文件所处的状态，每个子目录的状态都会保存下来。类似树对象整体的快照 Git中的文件分类：

3类：

已追踪的（tracked）：已经在版本库中，或者已经使用git add命令添加至索引中的文件；

被忽略的（Igored）：在版本库中通过“忽略文件列表”明确声明为被忽略的文件；

未追踪的（untracked）：上述两类之外的其它文件；新文件 在版本库中追踪一个内容时，在版本库可能不止一个分支，比如用于修复bug的可以称为修复分支，开发功能的可以称为开发分支，分支可以基于某一次的提交快照来创建，创建完，分支还可以合并

每一个分支都应该有一个名称，

head可以理解为git的引用标识

Git提交：

git commit

git log：查看提交日志； 提交的标识：

引用：ID， reference, SHA1, 绝对提交名；

符号引用：symbolic reference, symref；

本地特性分支名称、远程跟踪分支名称、标签名；都在refs目录下

名称：

refs/heads/REF：本地特性分支名称

refs/remotes/REF：远程跟踪分支名称

refs/tags/REF：标签名

我们还没有使用远程分支，对于三个目录来讲，

heads叫本地特性分支 （dev master）

tags 给提交的各种应用对应的名称，标签名

branches是对于的分支存储路径

https://github.com/happyfish100/fastdfs

https://github.com/happyfish100/fastdfs.git 把别人的仓库拿下来，里面有隐藏目录.git，查看克隆过来的路径 有remotes，heads只有一个master

git log 查看此前的每一次提交 branch 可以看到当前只有一个本地分支。，本地分支其实引用了远程，这个仓库上克隆来的 当前的matser分支其实是对应远程仓库的

remotes下 origin（起源），本身就是指你从哪里复制来的，对于远程的origin这个分支，每一个克隆的，都会有origin分支，起始于哪个分支

在远程主机上其实叫master，这里的origin只是表明从哪来 Git会自动维护几个特定目的的特殊符号引用：

HEAD：始终指向当前分支的最近提交；或检出到其它分支时，目标分支的最近提交；

ORIG_HEAD：合并操作时，新生成的提交前面的那一个提交保存于此引用中；

FETCHED_HEAD:

MERGE_HEAD：合并操作时，其它分支的上一次提交；

切换的时候，HEAD就在对应的GIT目录下，也是一个符号引用，始终指向当前分支提交；或检出到其它分支时，目标分支的最近提交

第一次提交到第5次提交，每一个提交都应该指向一个树对象 默认分支名是master，head通常都指向当前分支的最近一次提交 可以创建更多的分支，不合并考虑的话，当前工作的目录只能反应一个分支，如果用checkout切换到dev ，

head就指向dev

head始终指向当前分支的最近一次提交或目标分支的最近一次提交 ORIG_HEAD（上一个起源之意）：合并操作时，新生成的提交前面的那一个提交保存于此引用中；

谁是基础，谁是合并的很关键，master是主分支，dev合并上来，就会生成一个新的提交，叫合并后提交，因为合并后都会发生内容改变的，合并完成了，master就指向H，因为要指向当前分支的最近一次提交

作为当前分支的前一次提交是E，E就是ORIG_HEAD MERGE_HEAD：合并操作时，其它分支的上一次提交；

一旦合并，DEV分支也指向H了

当前前任叫ORIG_HEAD

合并 的另外一个前任MERGE_HEADFETCHED_HEAD:从远程主机取过来内容时，对应的远程分支获取到的，对应的最近一次提交FETCHED_HEAD

可以理解为下面的HEAD，因为这是从远程主机上取下来的 如果现在在H提交上，想回到D，就有另外的引用方式 相对提交名： 其他提交相对当前提交可以往前追溯

^：C6, C6^2

_：C6, C6~2

合并完后悔了，怎么办，对于git来讲可以回到此前的提交上去git reset：撤git reset：撤消此前的操作；

–soft：将HEAD引用指向给定的提交，但不影响索引和工作目录；

–mixed：将HEAD引用指向给定的提交，并将索引内容改变为指定提交的快照；但不改变工作目录；

–hard：将HEAD引用指向给定的提交、将索引内容改变为指定提交的快照，并改变工作目录中的内容反映指定提交的内容； **c5回到c4有三种回法 –soft 把head的指向从c5改成c4，head是指向最近一次提交，（等于把当前最近一次提交改成了c4，不识别c5，把c5等于删除了）这种删除不改变当前索引状态，不改变工作目录状态，可以有些忘记提交了，把这次提交删除了，下次重新提交 –mixed 修改head从c5指向c4，同时又改了暂存区，这两个文件完全变车了新文件 –hard 有可能丢失数据，因为文件也删除了，索引，工作目录，提交对象都发生改变，自从c4改的内容，都没了 ** 当前都是干净的没有什么我呢提，最近一次提交分支是master gitlog 可以看到大体有4次提交 可以再创建一个新的提交 git status告诉你，readme文件发生修改 **现在只是加入暂存区，索引 现在进行提交 -m 叫version 0.3.1还可以叫一个tag ** **tag打个标签 ** 假如提交之后想要回退，就显示这两个文件追踪了还没有提交 再次修改readme 显示修改好了。可以提交了，再次叫verson.0.3.1没有问题，status又属于干净状态

又后悔再去回退，–mixed，指定的对于的提交树覆盖了索引，索引之前返回了上次提交的

再次提交，不想要就–hard，都干净了，因为之前的内容都移除了 比较不同之处，c2到c4有什么不太可以用git来比较，最近一次提交和索引有什么不同可以比较，最近一次提交和工作目录有什么不同也可以比较

索引和工作目录有什么不同也可以比较

git diff：比较提交、索引及工作目录；

–color： 现在应该是一致的 现在工作区和索引不一样，索引和对象库还是一样的，现在是该文件，而不是加文件，比较的是文件内容有什么不同 索引种的readme需要减去thirdline才能和工作区一致 默认比较的是索引和工作目录有什么不同，是如何知道过去的文件找什么样子。

git add的时候原来的对象文件已经存放到对象库里了，拿到的是对象库里的版本和工作目录版本进行比较的

可以把工作目录和最近提交的来比较，git diff head（始终指向最近一次提交），一样是少了第三行

再修改一次readme文件 索引和最近提交做比较 也可以过去的两次任何提交之间作比较 如果做合并时，发生了冲突 做分支合并时发生冲突如何解决 捡出到dev分支，readme内容不一样 dev的还可以再次修改下文件 切换为master，把dev合并

conflict 冲突，合并就失败了 两个文件的内容，不清楚该怎么办 自己就需要编辑readme文件

对HEAD而言有newline，对DEV而言有下面两行 合并完成 如果中间冲突了就需要自己手动去解决，git log 远程分支，我们克隆的是别人服务器上一个对应的仓库，为了使得当前仓库知道你的仓库来自于哪里，要保存一个符号标识对远程仓库的引用，叫远程分支，origin head 对于这种分支，别人也可以克隆一份，来修改，最终生成如下分支 **CR2是另外其他人推上来的分支origin/idea ** 还可以给自己对应的分支取名字，tryidea 合并到本地，把远程的master分支取过来，把idea分支也取过来，本地分支三合一 tryidea就指向cl3 远程分支到底如何和你的工作目录工作起来的，工作流是如何的 git为何被称为分布式版本库，

每一个人都库拥有一个版本库，再本地的所有操作，如果想让别人能看到能拿走使用，需要找到一台服务器，把你的仓库扔上去，让别人通过文件访问服务FTP.等，别人就能clone走一份，拿一个副本，本地仓库和别人的仓库是一模一样的

自己本地在修改，别人本地也在修改，

修改完要共享彼此的修改，需要推送到远程服务器的仓库来，服务器的老版本和你的新版本合并起来，别人也会把修改的版本推上去，会冲突，所以他需要先把你推送的取到本地，手动完成合并，没有问题再推送，

对方推上去了，我们要使用，也需要下载下来，本地完成合并再推送

远程仓库，版本库 本地的人推了abc文件到远程的公共仓库，别人要使用就需要git fetch取到本地，需要把本地的分支和远程的分支做合并，合并只有，他又提交了三次DEF，现在又六次提交，就推送到公共仓库中了，推送之后，我们本地只有ABC，所以我们也要获取到FETCH，本地才有DEF，同样用PUSH推送到另外仓库中去 一般来说，只有同一个团队的才有可能写同一仓库，不是的就都是有其他的仓库

这就是远程协作的问题 **可以有多个远程分支，有两个开发人员，nick和jessica 本地做了提交，5EC作为最新一次提交的ID，推送到了公共仓库中去（schacon project）， 5ec是提交对象，4a7是树对象，ce0，e4a是blob对象 本地的master 的5ec和远程的public/master， 两个引用分别指向不同的分支 ** nick想要基于我们此前结果做二次开发，git lone 相当于 git fetch，做了新的修改和提交c12，现在想把自己的内容提交，共享给别人

Jessica 也下载到本地，再次提交 2fb，指向的新树把文件a09改了

现在每个人持有的内容都不一样了 也就他们各自往自己的项目上推了，这三个分支现在是各不相同，现在合并的话冲突是必然的

本地合并远程分支 remote add 有三个远程分支 nick /jessica

把nick，Jessica仓库拿过来，就再本地仓库中把三个提交合并起来了，中间冲突需要自己手动解决

这三个提交其实生成了三个分支

一个是自己的master

一个是自己的本地对应的远程public分支

nick

jess

合并之后生成新的提交b3b，现在master反应的就是三个提交合并之后生成的提交了、gitt remote add 表示添加远程仓库引用

nick远程仓库别名

git://url

fetch nick 把nick仓库取到本地 pull =fetch+ merge(会自动合并) 把三个仓库合并再push到远程public仓库 变基操作 第一个分支local，生成两个提交，c3,c4， jessica提交两次，c5，c6，

c3/c4不同于c5，c6 变基操作 现在取过来就有两个分支

本地的master

jessica的master的分支 c3不再以c2为基，而是以c6为基

c4相比于c3的不同，c4相比较c3的不同，变成c4‘（合并了c3，4，5，6）

提交路径就变成了这样，两个分支和二为一 分支的合并办法有两种 变基操作：

git rebase

$ git checkout dev

$ git rebase master

$ git checkout master

$ git merge -m “MSG”

master是主干，应该给master做变基*Git分支:

分支命名法则：

可以使用/，但不能以/结尾；

不能以-开头；

以位于/后面的组件，不能以.开头；

不能使用连续的…；

不能使用空白字符；

不能使用^, ~, ?, ，[等；

必须惟一；分支名字的名字始终指向目标分支的最近一次提交；

git branch：列出、创建及删除分支；

git branch BRANCH_NAME [START_COMMIT]

git branch -d BRANCH_NAME

git show-branch：查看分支及其相关的提交；

git checkout：

git checkout ：检出分支

必有有一个人，当项目研发到一定阶段的时候，需要一个人把所有的仓库合并起来，推到一个公共仓库里，PM需要做的事

转载地址：http://yckgn.baihongyu.com/