导言
之前虽然一直在使用 git 作为代码管理工具，但是一直没有系统性的学习 git 的使用和原理。目前在实习,之前觉得git 一般般就行了 , 现在特别后悔。代码写好了, 提交出现问题 , 花了我半天。哎 , 痛定思痛。所以我写这篇文件,好好学习一下 git.
git基础篇
数据库 是 记录文件或目录状态的地方, 存储着内容修改的历史记录。 在数据库的管理下 , 把文件和目录的修改的历史记录放在对应的目录下。
远程数据集和本地数据库
git 数据库分为远程数据库和本地数据库的两种
修改记录的提交
若要把文件或目录的添加和变更保存到数据库 , 就需要进行提交。 执行提交后 , 数据库中会生成上次提交的状态与当前状态的差异记录 (revision)
提交是以时间顺序排列状态被保存到数据库中的。 凭借该提交和最新的文件状态 , 就可以知道过去的修改记录以及内容。
工作树和索引
在git 管理下 , 大家实际操作的目录被称为工作树 在数据库和工作树之间有索引 , 索引是为了向数据库提交作准备的区域。
git 在执行提交的时候 , 不是直接将工作树的状态保存到数据库 , 而是将设置在中间索引区域的状态保存到数据库 。 因而 , 要提交文件 , 实现需要把文件加入索引区域中。
git高级篇
分支
在入门篇我们简单地讲解了 git 的基本使用方法。 在高级篇 , 我们首先要讲解一下分支的使用方法和操作。
在开发软件时 , 可能有多个同时为一个软件开发功能或修复bug， 可能存在多个 Release 版本 , 并且需要对各个版本进行维护
什么是分支
分支是为了将修改记录的整体流程分叉保存。 分叉后的分支不受到其他分支的影响, 所以在同一个数据库里可以同时进行多个修改。
分叉的分支可以合并
为了不受到其他开发人员的影响 , 您可以在主分支上建立自己专用的分支。 完成工作后吗， 将自己分支上的修改合并到主分支。 因为每一次提交的历史记录都会被保存 , 所以当发生问题时 ,定位和修改造成问题的提交就容易多了。
master 分支
在数据库进行最初的提交后 , git 会创建一个名为 master 的分支 。 因此之后的提交 , 在切换分支之前都会添加到master分支里
分支的运用
在git您可以建立分支.但是, 要先确定运用规则才可以有效地利用分支 这里我们会介绍两种分支 ("Merge分支"和"Topic分支")的运用规则
merge分支
merge分支是为了可以随时发布release 而创建的分支,它还能作为topic分支的源分支使用。保存分支稳定是很重要的。如果要进行更改，通常先创建topic分支,而针对该分支,大家会将master分支当做merge分支来使用
topic分支
topic分支是为了开发新功能或修复bug等任务而建立的分支。若要同时进行多个任务,请创建多个的topic分支
topic分支是从稳定的merge分支创建的。完成作业后,要把topic分支合并回merge分支。
分支的切换
若要切换作业的分支，就要进行checkout操作。进行 checkout时 , git会从工作树还原向目标分支提交的修改内容。checkout 之后的提交记录将被追加到目标分支
HEAD
HEAD指向的是现在使用中的分支的最后一次更新。 通常默认指向master 分支的最后一次更新。通过移动HEAD，就可以变更使用的分支
stash
还未提交的修改内容以及新添加的文件, 留在索引区域或工作树的情况下切换其他的分支时,修改内容会从原来的分支移动到目标分支。
但是如果在checkout的目标分支中相同的文件也有修改, checkout会失败的。这时要么先提交修改内容 , 要么用 stash 暂时保存修改内容后再 checkout.
stash是临时保存文件修改内容的区域。 stash可以暂时保存工作树和索引里还没提交的修改内容, 您可以事后再取出暂存的修改, 应用到原先的分支或其他的分支上
分支的合并
完成作业后的 topic 分支,最后要合并回 merge 分支。合并分支有2种方法: 使用merge或 rebase。 使用者2种方法 , 合并后分支的历史记录会有很大的差别。
merge
使用 merge 可以合并多个历史记录的流程。
如下图所示, bugfix是从 master 分支分叉出来的。
合并 bugfix分支到 master分支时, 如果master分支的状态没有被更改过,那么这个合并是非常简单的。bugfix分支的历史记录包含master分支所有的历史记录,所以通过把master分支的位置移动到 bugfix的最新分支上, git就会合并。 这样叫做 fast-forward 合并。
但是, master 分支的历史记录有可能在 bugfix分支分叉出去后有新的更新。 这种情况下, 要把master 分支的修改内容和 bugfix分支的修改内容汇合起来。
rebase
实例教程
是不是前面的概念看的云里雾里的。没事 , 我们来举个例子就好了。
note： git checkout -b branch 可以创建分支并进行切换
远程数据库
pull
我们在基础中讲解过 , 执行pull 可以取得远程数据库的历史记录。接下来,我们用图来解释数据库提交的细节。
首先确定更新的本地数据库分支没有任何的更改。
这时只执行 fast-forward 合并。图中的 master是本地数据库的master分支, orgin/master 是远程数据库的 origin的 master 分支。
如果本地数据库的master 分支有新的历史记录,就需要合并双方的修改
执行pull就可以进行合并。这时,如果没有冲突的修改,就会自动创建合并提交。 如果发生冲突就话 , 要先解决冲突,再手动提交。
fetch
执行pull,远程数据库的内容就会自动合并。但是 , 有时候只想确认本地数据库的内容而不想合并。这种情况下,请使用fetch
执行 fetch 就可以取得远程数据库的最新历史记录。取得的提交会导入到没有名字的分支, 这个分支可以从名为 FETCH_HEAD的退出。
标签
标签是为了更方便地参考提交而给它标上易懂的名称
Git 可以使用 2 种标签: 轻标签和注解标签。打上的标签是固定的, 不能像分支那样可以移动位置。
-
轻标签
- 添加名称
-
注解标签
- 添加名称
- 添加注解
- 添加签名
一般情况下,发布标签是采用注解标签来添加注解或签名的。 轻标签是为了在本地暂时失业或一次性使用。
实例教程
让我们再来实际操作一下
// 创建标签
git tag <tagname>
// 查看标签
git tag
// 删除标签
git tag -d <>
改写提交
这里的好像有点难了
修改最近的提交
指定 amend 选项执行提交的话,可以修改同一个分支最近的提交内容和注解
主要使用的场合
- 添加最近提交时漏掉的档函
- 修改最近提交的注解
取消过去的提交
在 revert 可以取消指定的提交内容。 使用后面要提到的 rebase -i 或 reset 可以删除提交。 但是 , 不能随便删除已经发布的提交, 这时需要通过 revert 创建要否定的提交。
主要使用的场合
- 安全地取消过去发布的提交
