git详解--原理及常用操作

链接

https://www.jiyik.com/w/git/git-branch

https://developers.weixin.qq.com/community/develop/article/doc/000c8e6e6c01800076481a8f251413

git基本原理：

　　以为git是一个分布式版本控制系统，因此git的操作大部分都是在本地，除非明确说明下面的原理或者命令都是在本地操作。

每个git项目的根目录下都有一个.git目录，它是git默默进行版本控制时读写的“数据库”。有几个概念需要提一下：

--工作区：代码所在的目录，就是自己电脑中能够看到的目录

--暂存区：英文叫stage或者index。一般存放在.git/index文件中，所以我们把暂存区也叫作索引index

--版本库：工作区有一个隐藏的.git，这个不算工作区，而是GIt的版本库。

 

下图展示了工作区、版本库、和 版本库中的暂存区之间的关系。

 

 

--图中左侧绿色区域为工作区，右侧为版本库。在版本库中标记为“index”的区域为暂存区（stage/index），标记为“master”的是master分支所代表的的目录树

--图中我们可以看出此时“HEAD” 实际指向master分支的一个“游标”。所以图示的命令中 出现HEAD的地方可以用master来替换

--图中的objects标识的区域为git的对象库，实际位于“./git/objects”目录下，里面包含了创建的各种对象及内容

--当对工作区修改（或新增）的文件执行git add命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

--当执行git commit 时，暂存区的目录树 写到版本库(对象库)中，master分支会做相应的更新。即master指向的目录树就是提交时暂存区的目录树。

--当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被master分支指向的目录树所替换，但是工作区不受影响。

--当执行 git rm --cached<file>命令时，会直接从暂存区删除文件，工作区则不作出改变。

--当执行 git checkout . 或者 git checkout -- <file>命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清楚工作区中未添加到暂存区中的改动。

--当执行git checkout HEAD .或者 git checkout HEAD <file>命令时，会用HEAD指向的master分支中的全部或者部分文件替换暂存区以及工作区中的文件。这个命令也具有危险性，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

 Git管理的项目工作目录下的每一个文件都不外乎两种状态： 已跟踪，未跟踪

　　--已跟踪的文件是指：那些被纳入了版本控制的文件，在上一次快照中有他们的记录，在工作一段时间后，他们的状态可能处于未修改，已修改或者放入暂存区

　　--工作目录中除已跟踪文件外的所有其他文件都属于未跟踪文件，他们既不存在上次快照的记录中，也没有放入暂存区。

　　--初次克隆某个仓库的时候，工作目录中所有的文件都属于 已跟踪文件，并处于未修改状态。

Git保存的不是文件的变化 或者差异，而是一系列不同时刻的文件快照。在进行提交操作时，git会保存一个提交对象commit object 。 该提交对象会包含一个指向暂存内容快照的指针。但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。

Git将项目存储为4个部分：如下图：

　　

 

 --workspace: 工作区（当前用户操作修改的区域）

--index/stage:暂存区（add后的区域）

--Repository: 本地仓库区 commit之后的区域

--remote：远程仓库（push后的区域）

整体过程可以简述为：

　　-工作区--》git add --》暂存区--》git commit --》本地仓库区---》git push---》远程仓库区

　　-远程仓库区--》fetch --》使用refs\remotes下对应分支文件记录远程分支末端commit_id 和本地仓库区--》merge -->工作区

　　-远程仓库区 --》 git  pull --》使用refs\remotes下对应分支文件记录远程分支末端commit_id and 本地仓库区 and 工作区

git工作原理：

本节介绍git的工作流程，一般的工作流程如下：

--克隆Git资源作为工作目录

--在克隆的资源上添加或修改文件

--如果他人修改了，你可以更新资源

--在提交前查看修改

-提交修改

-在修改完成后，如果发现错误，可以撤回提交并再次修改并提交

下图展示了Git的工作流程：

　　

git命令详解：

一、创建仓库

　　什么是仓库：

　　一个GIT仓库是一个项目的一个虚拟存储。它允许你保存代码的版本，可以在需要时访问这些版本。

　　-git init --初始化一个新的仓库

　　要创建新的仓库，我们需要使用git init 命令。执行此命令将在你当前的工作目录中创建一个新的子目录.git。同时也将创建一个新的主分支。

二、git clone--克隆现有的仓库

　　如果该项目已在中央仓库中存在，则clone命令是用户将项目获取到本地开发的最常见方式。clone通常是一次性操作，开发人员获得工作副本后，所有的版本控制操作都通过其本地仓库进行管理。

　　命令格式：git clone url   如：$ git clone https://githu.com/onmpw/repo.git

 

三、Git仓库操作

　　-git add 命令

　　　　git add 将修改添加到暂存区，git有一个额外的保存机制，成为‘stash’。stash是一个临时存储区域，用于存储尚未准备好提交的更改。

　　　　git add 命令将工作目录中的更改添加到暂存区。它告诉git 我们希望在下一次提交中包含对特定文件的更新。但是 git add 并不会以任何的方式真正影响仓库。直到运行git commit命令才会真正对仓库进行了修改。

　　工作原理：

　　git add 和git commit 命令组成了基本的git 工作流程。这是没每个git 用户都需要了解的两个命令，不管其团队的协作模式是怎样的。他们是将项目版本记录到仓库历史记录中的方法。

　　开发项目围绕基本的  编辑、暂存、提交模式。首先在工作目录中编辑文件。当准备好保存项目当前的副本时，就可以使用git add 命令。 在对暂存快照感到满意后，可以使用git commit 命令

将其提交到项目历史记录中。git reset 命令用于撤销提交或暂存的快照。

　　除了git add 和之外git commit，第三个命令git push 对完整的git写作工作流是不可少的。git push 用于将提交的更改发送到远程仓库。这使得团队的其他成员能够访问一组已保存的更改。

　　

 

　　--git add . 将所有更改的文件 提交到暂存区，此举对仓库无任何影响

　　--git commit -m "message" 将提交到暂存区的代码，提交到仓库

　　--git status 命令用于查看在上次提交之后，是否有文件进行再次修改，即查看文件修改的状态,

　　　　git status / git status -s:

　　

 

 　　-- git commit 命令：

　　　　git commit 命令是将暂存区内容添加到本地仓库中。（git add 是将工作区的更改内容添加到暂存区）

　　　　命令格式： git commit -m "message"

　　　　　　　　　-a 参数设置修改文件后，不需要执行git add命令，直接来提交

　　　　　　　　　git commit -am "message"  直接add并commit 提交

　　--git diff 命令，比较文件的不同，即比较文件在暂存区和工作区的差异，命令显示已写入暂存区和已经被修改单尚未写入暂存区文件对对的区别。

　　　　git diff 有两个主要应用场景：

　　　　　　--尚未缓存的改动：git diff

　　　　　　--查看已缓存的改动：git diff --cached

　　　　　　--查看已缓存的与未缓存的所有改动：git diff HEAD

　　　　　　-- 显示摘要而非整个diff : git diff --stat

　　-- git stash 命令

　　　　含义：暂时搁置(或隐藏)我们队工作副本所做的更改，以便我们可以处理其他事情，处理完其他事情之后再回来并重新应用他们。

　　　　-- git stash   --- 将更改暂存

　　　　--git stash pop ---将更改恢复

　　　　可以有多个更改暂存

　　　　--git stash list 查看暂存列表

　　　　--git stash drop 将暂存的更改文件丢弃掉

　　　　-- git stash pop stash@{0} 进行恢复第一个暂存

　　--git log   -- 查看提交日志

　　git log 命令显示已提交的快照的所有的历史信息。它会列出所有项目的历史记录、对其进行过滤并搜索特定的更改。git status 是用来检查工作区和暂存区的，而git log 只是对提交的历史进行操作。　　

　　　　

 

　　-- git log --oneline 查看历史记录的简洁版本　　

　　　　

  　--git tag 标签

　　　标签是指git 历史记录中特定的引用。标签通常用于标记版本发布（即V1.0.1）的历史记录点，标签就像一个不会改变的分支。但是与分支不同，标签在创建后没有进一步的提交历史。

　　　　本节将介绍：不同类型的标签、如何创建标签、列出所有的标签、删除标签、共享标签等。

　　　　--git tag <tagname> 创建标签 这个是不带注释的tag创建命令

　　　　-- git tag -a V2.9.0 -m "my version V2.9.0"   加注释的标签

　　　　-- 如果标签已经存在，则需要对标签进行更新 使用 -f选项 git tag -a -f V2.9.0 -m "my version V2.9.0" 

　　　　--给之前的提交创建tag

　　　　　　git tag 可以对特定的提交创建tag，首先使用 git log 查看提交列表

　　　　　　git tag -a V 2.8.9 ID -m "message"

　　　　--将标签推送到远程

　　　　　　共享标签类似于分支，默认情况下，git push不会推送标签。标签必须显示的传递给git push

　　　　　　--git push origin V1.4 这样就将tag信息推送到了远端仓库

四、git 撤销更改命令--比较重要，当程序出现错误时便于回退

　　git没有文字处理应用程序那样的撤销系统，git 有自己的撤销操作，如：git checkout 、 git revert、 git clean 、 git reset等

将git视为时间机器，对时间线进行管理。一次commit 提交 是一个项目历史时间线中某个时间点的快照。此外，可以通过使用分支来管理多个时间线。在git中进行“撤销”操作时，我们通常会回到过去，或移到另一个没有发生错误的时间线。

　　对比差异：检索旧的提交

　　git log是查看git仓库历史提交记录的最佳选择，也是后续其他操作的基础。

　　--git log 或者 git log --oneline 来获取历史提交信息。每一次提交都有唯一的SHA-1哈希标识符。这些ID用于遍历已提交的时间线并访问特定的提交信息。默认情况下，git log只显示当前所在分支的提交信息。然而 有时可能我们要查看的是其他分支的历史提交信息，这种情况就需要我们在git log命令后面加上 --branches = * 选项了。

　　-- git log --branchs=*

　　--git branch 查看当前位于哪一个分支下。

　　--git revert撤销历史提交

　　　　git revert命令可以被认为是“撤销”命令。但是它不是传统的撤销操作。不是从项目历史中删除提交，而是计算如何要撤销的提交所引入的更改，并附加一个新的提交及生成的反向内容。

这种方式可以防止git丢失历史记录，这对于我们修订历史记录的完整性和可靠的协作非常重要。

　　当想要应用项目历史中提交的逆向时，应该使用revert。如果我们正在个弄脏错误并发现他是由单个提交引入的，此时我们无需手动进入、修复并提交新的快照，而是可以使用git revert 自动为我们完成所有这些工作。

　　git revert的原理：

　　　　git revert 命令用于撤销对仓库提交历史的更改。其他“撤销”命令，例如：git checkout  \git reset，将HEAD和分支引用指针移动到指定的提交。

　　　　git revert 也需要一个指定的提交，但是，它并不会将ref指针移动到这个提交。revert操作将采用反转指定的提交的更改，并创建一个新的“还原提交”。让后更新ref指针以指向新的还原提交，使其成为分支的HEAD。

　　　　--git revert HEAD   

　　　　　git revert期望后面跟一个提交的引用，如果后面没有的话，则该命令不会被执行。 这里我们传入HEAD引用，这里讲恢复最新的提交。与合并类似，revert将创建一个新的提交，并且会打开配置的系统编辑器，提示输入新的提交消息。一旦输入并保存提交消息，git将开始进行恢复操作。

　　　　--git log --oneline   调用git log命令查看提交的日志

　　　　　　发现： 还原后三次的提交记录仍然在项目的历史记录中。git revert 只是添加了一个新的提交来撤销其更改。并不是删除它。

　　

　　-- git reset     是撤销更改的方法，用于回退版本，可以指定回退某一次提交的版本。它主要有三种主要的调用形式。这些形式对应于命令行参数--soft,--mixed 和 --hard.这三个参数分别对应于git的三个内部状态机制，即提交树（HEAD），暂存索引 和工作目录。

　　要正确理解git reset用法，首先要了解Git内部的状态管理系统。有时这些机制被称为Git的“三棵树”，树可能用词不当，