深入理解Git（1）

最新推荐文章于 2022-04-07 10:44:04 发布
最新推荐文章于 2022-04-07 10:44:04 发布
阅读量409 收藏
点赞数
分类专栏： Git系列文章 文章标签： git
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/LENOVOJXN/article/details/113823877
版权

1 .git文件夹目录结构

在.git文件夹中执行tree命令，查看文件列表。

$ tree
├── branches   
├── COMMIT_EDITMSG  # 存储最新的提交信息
├── config      # 存储本地仓库的Git配置信息
├── description # 仓库的描述信息，主要是Git托管系统使用
├── HEAD        # 一个指针，指向正在工作中的本地分支的指针，内容为映射到refs的引用
├── hooks       # Git执行特定操作的后出发的一些shell脚本
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-merge-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
├── index      # 代表暂存区
├── info       # 存放全局性的排除文件，和.gitignore文件互补，只有一个exclude文件
│   └── exclude
├── logs       # 存储所有的更新的引用记录
│   ├── HEAD
│   └── refs
│       ├── heads
│       │   └── master
│       └── remotes
│           └── origin
│               └── HEAD
├── objects    # 对象目录，存储内容，对象有：commit、blob、tree、tag
│   ├── info
│   └── pack
│       ├── pack-459a02c6ba0c6dd954a874752a7d1641d3f6899c.idx
│       └── pack-459a02c6ba0c6dd954a874752a7d1641d3f6899c.pack
└── refs       # 对象的引用
    ├── heads
    │   └── master
    ├── remotes
    │   └── origin
    │       └── HEAD
    └── tags

2 深入理解Git的暂存区

在Git基础章节中，我们介绍了暂存区的概念，它工作区和本地仓库中间的一种状态，修改的文件或者新增的文件需要先添加到暂存区，作为待提交的任务，然后，使用git commit命令将暂存区的待提交的任务提交到本地仓库。

在一些介绍Git的书籍或者博客中，把暂存区的设计看作是Git最成功的设计之一，那么该怎么理解这个暂存区呢？

Git中的暂存区是一个名为index（存放在.git文件夹）的索引文件，这个索引文件是一个二进制文件，它包含了文件索引的目录树，就像一个虚拟的工作区。在这个工作区中，记录了文件名和文件的状态信息（例如：时间戳和文件长度等），但并没有存储文件的具体内容，而是建立了文件和对象库中对象实体的关联关系。文件的具体内容存放在.git文件夹中的objects子文件夹中。

2.1 查看工作区、暂存区和本地仓库的目录树

index文件是一个二进制文件，使用cat命令或者在文件编辑器中不能查看该文件的内容，但是，Git提供了查看该文件的相关命令。为了更好的对比工作区、暂存区和本地仓库的目录树的内容，在这里做个一个统一的介绍。

  1. 查看工作区的目录树

在Window系统中可通过文件夹的方式查看，在Linux系统也可以使用shell命令查看：

$ find . -path ./.git -prune -o -type f -printf "%-20p\t%s\n"
./weclome.txt       	45
./a/b/c/hello.txt   	16

其中，45和16表示对应文件的字节大小。

  1. 查看暂存区中的目录树

使用git ls-files -s命令查看暂存区的目录树：

$ git ls-files -s
100644 18832d35117ef2f013c4009f5b2128dfaeff354f 0	a/b/c/hello.txt
100644 9a94974a88cbb47f0744da627a052c0a166d21b6 0	weclome.txt

其中，输出信息中第一列表示文件的读写属性（rw-r--r--），第二列表示该文件在对象库中的ID，第三项表示暂存区的编号（从0开始），第四项表示文件的路径。

也可使用git ls-tree命令查看暂存区的目录树，但是需要先执行git write-tree命令，将暂存区中的目录树写入Git对象库中：

$ git write-tree
f267b7db7ed8833a18a0c79a998ffbb97dcb373f
$ git ls-tree -l f267
040000 tree 53583ee687fbb2e913d18d508aefd512465b2092       -	a
100644 blob 9a94974a88cbb47f0744da627a052c0a166d21b6      45	weclome.txt

git write-tree的输出就是写入Git对象库中的目录树ID，然后ls-tree命令使用该ID查看对应目录树的内容。

git ls-tree输出信息中的第一列表示文件的读写属性，第二列表示对象类型（tree、blob、commit、tag），第三列表示文件在对象库中的ID，第四项表示文件的大小，第五项表示文件或者文件夹的路径。和git ls-files的输出对比来看，git ls-tree不能直接显示子文件夹中的文件，需要使用递归来查看。

$ git write-tree | xargs git ls-tree -l -r -t
040000 tree 53583ee687fbb2e913d18d508aefd512465b2092       -	a
040000 tree 514d729095b7bc203cf336723af710d41b84867b       -	a/b
040000 tree deaec688e84302d4a0b98a1b78a434be1b22ca02       -	a/b/c
100644 blob 18832d35117ef2f013c4009f5b2128dfaeff354f       7	a/b/c/hello.txt
100644 blob 9a94974a88cbb47f0744da627a052c0a166d21b6      45	weclome.txt

其中，-r选项可以递归显示目录的内容，-t选项可以把递归过程中遇到的每颗树都显示出来。

  1. 查看本地版本库中的目录树

查看本地版本库中的目录树时，需要指定一个提交ID，通常使用HEAD来代表当前分支的最新提交：

$ git ls-tree -l HEAD
100644 blob 0c80c621b977bc24b75981f2cd16f6746455b4d5      36	weclome.txt

可以看到，工作区、暂存区和本地仓库的目录树的内容是不一样的：

文件名工作区暂存区本地仓库
weclome.txt454536
hello.txt167-

2.2 git diff对比文件差异

有了上面目录树内容的对比分析，现在再回忆之前提到了对比工作区、暂存区和本地仓库的命令，是不是更好理解了呢。

  • 对比工作区与暂存区的文件差异：git diff
$ git diff
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt
index 18832d3..e8577ea 100644
--- a/a/b/c/hello.txt
+++ b/a/b/c/hello.txt
@@ -1 +1,2 @@
 Hello.
+Bye-Bye.
  • 对比工作区与本地仓库的文件差异：git diff HEAD或者git diff master，其中master为默认的分支名称
$ git diff HEAD
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt
new file mode 100644
index 0000000..e8577ea
--- /dev/null
+++ b/a/b/c/hello.txt
@@ -0,0 +1,2 @@
+Hello.
+Bye-Bye.
diff --git a/weclome.txt b/weclome.txt
index 0c80c62..9a94974 100644
--- a/weclome.txt
+++ b/weclome.txt
@@ -1,3 +1,4 @@
 Hello.
 allow-empty 测试
 -s 测试
+Bye-Bye.
  • 对比暂存区和本地仓库的文件差异：git diff --cached或者git diff --cached HEAD
$ git diff --cached
diff --git a/a/b/c/hello.txt b/a/b/c/hello.txt
new file mode 100644
index 0000000..18832d3
--- /dev/null
+++ b/a/b/c/hello.txt
@@ -0,0 +1 @@
+Hello.
diff --git a/weclome.txt b/weclome.txt
index 0c80c62..9a94974 100644
--- a/weclome.txt
+++ b/weclome.txt
@@ -1,3 +1,4 @@
 Hello.
 allow-empty 测试
 -s 测试
+Bye-Bye.

3 深入理解Git对象库

在之前的系列文章中，简单的提到过Git对象库的相关内容，比如：如何查看对象的类型、查看对象的内容以及HEAD和master的关系。这篇文章中上述内容做一个简单的回顾，然后在介绍下SHA1的值是如何生成的。

3.1 查看Git对象的类型和内容

在第1章介绍了Git对象有4种：tree、commit、blob和tag。其中，tree对象表示文件夹；blob对象表示文件，存储着文件的内容；commit表示一个提交对象，存储着提交者的名称和邮箱、父提交对象的ID、tree对象的ID和提交描述信息等；tag对象表示标签。那么看到一个SHA1字符串，如何通过它查看对象的类型和其中的内容呢？

  • git cat-file -t <object_id>：查看对象的类型，例如：git cat-file -t 0c80c
  • git cat-file -p <object_id>：查看对象的内容，例如：git cat-file -p 0c80c

3.2 理解HEAD和分支的关系

为了方便介绍，以下的内容以默认的master分支为例来介绍。在Git项目中，依次使用git log -1 HEAD、git log -1 master和git log -1 refs/head/master三个命令查看对应的输出：

$ git log -1 HEAD
commit 442c5d0fe2c9242db5483a02f350b1af89fc36ff (HEAD -> master)
Author: jiaoxiangning <2438822080@qq.com>
Date:   Mon Feb 15 16:44:15 2021 +0800

    -s测试
    
    Signed-off-by: jiaoxiangning <2438822080@qq.com>
$ git log -1 master
commit 442c5d0fe2c9242db5483a02f350b1af89fc36ff (HEAD -> master)
Author: jiaoxiangning <2438822080@qq.com>
Date:   Mon Feb 15 16:44:15 2021 +0800

    -s测试
    
    Signed-off-by: jiaoxiangning <2438822080@qq.com>
$ git log -l refs/heads/master
commit 442c5d0fe2c9242db5483a02f350b1af89fc36ff (HEAD -> master)
Author: jiaoxiangning <2438822080@qq.com>
Date:   Mon Feb 15 16:44:15 2021 +0800

    -s测试
    
    Signed-off-by: jiaoxiangning <2438822080@qq.com>

从上面的输出内容来看，HEAD、master和refs/heads/master具有同样的内容指向。使用命令分别查看.git/HEAD和.git/refs/heads/master文件的内容：

$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
442c5d0fe2c9242db5483a02f350b1af89fc36ff

可以发现，HEAD是对于当前分支（master为例）的引用，而refs/heads/master文件内容则指向了某个提交内容的ID。

$ git cat-file -t 442c
commit
$ git cat-file -p 442c
tree 43f4d4c26dadf4b1fe68d559915d0f2ea8c1b1db
parent 1900cf08263383b09616613b9fbb0e71b2162f46
author jiaoxiangning <2438822080@qq.com> 1613378655 +0800
committer jiaoxiangning <2438822080@qq.com> 1613378655 +0800

-s测试

Signed-off-by: jiaoxiangning <2438822080@qq.com>

refs/heads文件夹中保存引用的命名空间，其中heads子目录下的引用又称为分支，分支的表示方式有：正规的长格式表达方法，例如：refs/heads/master；或者去掉前面2级目录，使用master表示。例如：包含example分支和master分支的Git项目：

$ ls .git/refs/heads
example  master
$ cat .git/refs/heads/example
70d588a5d5efca0b2297f9be45afb923b9db643f
$ cat .git/refs/heads/master
310cb8cfab7596edd7185f0957e43dd0e797cee5

3.3 SHA1生成方法

SHA1是一种数据摘要算法，它能够处理从0到两百多万TB的输入数据，然后输出为固定160比特的数字摘要，即使两个输入数据量很大但差别很小，SHA1输出的结果也会有限显著的不同。

Git中的4中对象的ID是怎么计算的呢？先以提交对象为例：

  1. 查看HEAD对应的提交内容
$ git cat-file commit HEAD
tree 43f4d4c26dadf4b1fe68d559915d0f2ea8c1b1db
parent 1900cf08263383b09616613b9fbb0e71b2162f46
author jiaoxiangning <2438822080@qq.com> 1613378655 +0800
committer jiaoxiangning <2438822080@qq.com> 1613378655 +0800

-s测试

Signed-off-by: jiaoxiangning <2438822080@qq.com>
  1. 查看提交信息的数据量
$ git cat-file commit HEAD | wc -c
273
  1. 在提交信息前添加内容commit 273<null>（<null>为空字符），然后执行SHA1哈希算法
$ ( printf "commit 273\000"; git cat-file commit HEAD ) | sha1sum
442c5d0fe2c9242db5483a02f350b1af89fc36ff
  1. 使用git rev-parse命令查看HEAD对应的ID
$ git rev-parse HEAD
442c5d0fe2c9242db5483a02f350b1af89fc36ff

可以看到第3步和第4步得到的结果是一样的。如果想查看blob、tree和tag对象ID的生成方法，可以将上面步骤中的commit替换成对应的对象类型即可。经过上面的步骤，我们可以了解到Git中生成对象ID的方法。

4 深入理解Git重置

4.1 理解git reset命令

在前面的文章中，我们提到过master分支（对应着refs/heads/master文件）就像是指向某个提交对象的一个游标，当此分支上有了新的提交时，该游标就会指向新的提交。同时，Git中提供了git reset命令支持游标向后移动，可以指向任意一个存在的提交ID，例如：设置游标指向最新提交的父提交：git reset --hard HEAD^。

重置命令git reset命令是Git中常用命令之一，也是最危险的几个命令之一，常用的用法有：

  1. git reset [-q] [<commit_id>] [--] <file_path>...
  2. git reset [--soft | --hard | --mixed | --hard | --merge | --keep] [-q] [<commit_id>]

上面中[]表示都是可选项，其中，如果不提供commit_id，那么默认使用HEAD指向的提交的ID。

第1种方法需要提供一个文件路径，它不会重置引用，也不会更改工作区，而是用指定提交中的对应的文件<file_path>替换暂存区中的相应的内容，相当于在没有执行commit的情况下取消git add <file_path这条命令对于暂存区中的修改。

第2种方法则会重置引用，同时，根据不同的设置选项，选择性对暂存区和工作区进行重置：

  • --hard选项，即：git reset --hard <commit_id>命令，将会重置引用（修改master的指向），并使用新的引用的目录树替换暂存区和工作区中的目录树
  • --soft选项，即：git reset --soft <commit_id>命令，将会重置引用（修改master的指向），但不改变暂存区和工作区的目录树
  • --mixed选项，即：git reset --mixed <commit_id>命令，将会重置引用（修改master的指向），并使用新的引用的目录树替换暂存区的目录树，但不会修改工作区的目录树。git reset <commit_id>模式使用--mixed选项

这里列出几个常用的重置命令并对其作出解释：

  • git reset：使用HEAD指向的目录树重置暂存区，工作区的目录树不会收到影响，并且引用也不会被重置，因为重置引用到HEAD相当于没有重置，这条命令的效果相当于把git add命令提交的内容从暂存区移除
  • git reset --mixed：同上
  • git reset HEAD：同上
  • git reset -- <file_path>：不重置引用，使用HEAD指向的目录树中的对应文件替换暂存区的文件，相当于是对git add <file_path>命令的反向操作
  • git reset HEAD <file_path>：同上
  • git reset --soft HEAD^：重置引用为HEAD的父提交对象，工作区和暂存区保持不变，如果对于刚刚提交的说明或者内容不满意，可以使用该命令将引用回退；还记之前介绍的git commit --amend命令吗，它也能覆盖上一次的提交，其实该命令相当于使用git reset --soft HEAD^和git commit -e -F .git/COMMIT_EDITMSG两条命令，其中最后一条命令是修改上一次提交的描述信息。
  • git reset HEAD^：重置引用为HEAD的父提交对象，并且暂存区也会替换为上一次提交之前，但工作区不会改变
  • git reset --hard HEAD^：彻底撤销最新的更改，工作区、暂存区和引用都会回退到上一次的状态

4.2 使用reflog挽救错误的重置

Git提供了对于错误的重置的挽救机制，那就是通过日志文件（.git/logs）记录分支的变更，可凭借日志文件修复错误的重置。先来看看master分支的日志文件中的内容是什么。

$ git reflog show master
442c5d0 (HEAD -> master) master@{0}: commit: -s测试
1900cf0 master@{1}: commit (amend): amend test
fe76cc5 master@{2}: commit: allow-empty example
4d6636a master@{3}: commit: allow-empty测试
36574f3 master@{4}: commit (initial): initialized

日志文件中记录了master分支指向内容的变迁，最新的指向内容在输出结果的最上方。输出结果中包含了提交ID的简写，相对于最新提交的一个顺序表示式：<refname>@{n}以及提交的描述内容。其中，<refname>@{n}的含义是引用refname之前的第n改变是的SHA1值。

那么如何恢复到错误重置之前的状态呢？

  1. 使用上述命令查看错误重置之前的提交ID
  2. 使用git reset --hard master@{n}或者git reset --hard <commit_id恢复到指定提交对应的状态

5 深入理解Git检出

Git中检出本质上是HEAD的重置。在之前的Git分支的文章中，介绍过了HEAD是描述当前工作分支的最新状态，在切换分支时，HEAD游标（或指针）指向的内容会自动变为目标分支。除了之前介绍过的不同分支间的检出，也支持检出特定的提交，即：git checkout <commit_id。

$ git checkout 442c5
Note: switching to '442c5'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 442c5d0 -s测试

上面的输出内容中，提到了一个状态：detached HEAD，中文名是“分离头指针”。“分离头指针”是指HEAD引用的不是一个分支，而是某个具体的提交对象。

$ cat .git/HEAD
442c5d0fe2c9242db5483a02f350b1af89fc36ff

在“分离头指针”状态中，可以完成git status、git add、git push命令，但会提示警告。

$ touch bb.txt
$ git status
HEAD detached from 442c5d0
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	bb.txt

nothing added to commit but untracked files present (use "git add" to track)
$ git add bb.txt
$ git status
HEAD detached from 442c5d0
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   bb.txt
$ git commit -m "bb.txt"
[detached HEAD b63b504] bb.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bb.tx

上面的输出结果中，均有detached HEAD警告信息。

如果要将“分离头指针”的内容整合到master指针中，可是使用merge命令，例如：在master分支中使用git merge 442c5命令将内容合并到master分支。

检出命令的常用格式有：

  1. git checkout [-q] [<commit>] -- <file_paht>...
  2. git checkout [<branch>]
  3. git checkout [-m] [[-b|--orphan] <new_branch>] [<start_point>]

第1种格式，使用指定版本中的文件覆盖工作区的文件。如果提供commit，会修改HEAD指针的引用，进入“分离头指针”状态；如果提供file_path，不会修改HEAD指针，并使用指定提交中或者只能暂存区中的文件覆盖工作区的文件，不提供commit将会使用暂存区中文件。

第2种格式，在之前的Git分支的文章中经常使用，它会修改HEAD指针的引用，切换到特定的分支进行追踪，如果省略``branch`将会进行工作区状态检查。

第3种格式，主要是创建和切换到新的分支。之前的文章中也经常使用到git checkout -b <new_branch>命令。这里提一下start_point的使用，在创建新分支时，如果提供了start_point，将会以此为基础创建新分支，如果没有提供，则会在HEAD指向的基础上创建新的分支。

下面列出一些常用的git checkout命令：

  • git checkout master：切换到master分支，HEAD指针指向master分支，并使用master分支对应的目录树更新暂存区和工作区
  • git checkout：汇总显示工作区、暂存区和HEAD的差异，如果没有输出结果，表示三者无差异
  • git checkout HEAD：同上
  • git checkout -- <file_name>：用暂存区中对应的文件覆盖工作区中文件
  • git checkout branch -- <file_name>：保证HEAD的指向不变，使用branch对应的提交中的file_name内容替换暂存区和工作中的对应的文件。
  • git checkout -- .或者git checkout .：会使用暂存区中的所有文件覆盖工作区中的文件，并且不会给使用者任何提示，因此，这条命令极其危险，需要谨慎使用

6 总结

通过上面的3章内容，能够对下图所描述的流程做出描述呢？欢迎在评论区中讨论~~~

20210215-01

码农阿焦
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
git 深入理解
mulinsen77的博客
05-26 607
之前一直是对git的基础命令有了解，最近正好有这个时间和需求，将git命令重新理解了下。 git仓库中保留的是你的目录下所有文件的快照。还有提交记录，这个记录很轻量，git会将此次版本与上一次的版本进行对比，将所有的差异打包到一起作为一个提交记录。 先说一些简单的之前模糊的概念。 1. origin origin：origin可以说是远程仓库的一个指针。 其实就是远程仓库服务器的一个copy。 git remote可以列出当前所在分支对应的每一个远程服务器的简写。 git remote show orig
深入理解学习Git工作流
bobo_93的博客
05-22 668
一、译序 工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是Git或SVN等VCS或SCM工具的使用。 这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的Pull Request功能，体系地讲解了各种工作流的应用。 行文中实践原则和操作示例并重，对于Git的资深玩家可以
深入理解Git的实现原理
weixin_34245749的博客
09-27 581
0、导读 本文适合对git有过接触，但知其然不知其所以然的小伙伴，也适合想要学习git的初学者，通过这篇文章，能让大家对git有豁然开朗的感觉。在写作过程中，我力求通俗易懂，深入浅出，不堆砌概念。你能够从本文中了解以下知识： Git是什么 Git能够解决哪些问题 Git的实现原理 请注意,本文的阐述逻辑是：Git是什么——>Git要解决的根本问题是什么——&gt...
深入理解Git：（1） Git基础
plusnil的专栏
03-31 160
目录说明数据存储Blob使用git hash-object使用openssl sha1在.git文件夹中的存储位置Tree 说明 本文是Frontend Masters课程《深入理解Git》（Git In-depth）笔记。 本文是第一部分，Git基础（Git Foundations）。 本文在Windows下使用git bash输入命令进行测试。 数据存储 Git的核心为键值存储系统（key-value store）。 值（value）为数据（data）。 键（key）为数据的哈希值（hash）。 键的
git 深入了解
weixin_41774732的博客
07-13 216
安装与配置 sudo apt-get install git git config --global user.name "your Name" git config --global user.email "email@example.com" ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210713135047539.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,tex
使用git微命令深入理解git工作机制
03-03
然后很久过去后，自己也有了很多的git项目实践，觉得有必要从自己的理解角度（微命令和常用命令对应分析）来整理下自己的理解，于是有了这篇博文。git是一种管理数据的工具，一种支持快速索引查找数据并管理数据变化...
深入理解学习Git工作流（git-workflow-tutorial）
02-25
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同...关于Git工作流主题，网上体系的中文资料不多，主要是零散的操作说明，希望这篇文章能让你更深入理解并在工作中灵活有效地使用
深入浅出Git
10-05
"深入浅出Git"是一本旨在帮助读者深入理解Git工作原理和实践操作的书籍。以下将详细介绍Git的对象模型，这是Git的核心概念之一。 Git的核心设计理念是通过内容寻址存储来确保数据的完整性和可追溯性。它的对象模型...
圣SI园《深入掌握Git与实战开发》
11-10
这导致很多学习者在学习一段时间后无法深入，而且由于没有真正、彻底地理解Git的原理与模型，使得即便掌握了不少Git命令，在真正遇到问题时也是束手无策，最终导致放弃学习，而且对Git形成了心理阴影。 纵然如此，...
深入理解git
bdss58的专栏
04-13 1553
之前用过git，感觉很神奇。很好用之际，膜拜linux，他能迅速写出这么给力的版本控制系统而我不能理解其原理，惭愧之极。 今儿偶然看到一篇国外网友写的文章介绍git原理，看完茅塞顿开。遂翻译之，以记之！ 原文地址：http://maryrosecook.com/blog/post/git-from-the-inside-out ================================
深入理解 Git
weixin_33763244的博客
02-19 92
深入理解 Git Git 使我们日常使用的开发工具，用于代码的版本管理，但是我们常用的各种命令 git add, git commit, git push, git pull 等等究竟是啥样子，带着好奇心，趁着空重新读了下 Git 的官方文档。发现了一些除了刚刚提到的高级命令以外的低级命令，以及 Git 究竟是如何运转的。（当然不是源码解读） 基本概念 git 对于文件的存储位置进行了3层分割...
2021-04-01
金大大的博客
04-01 257
git 提交 全部文件 1、git add . git add xx 命令可以将xx文件添加到暂存区，如果有很多改动可以通过get add -A .来一次添加所有改变的文件。注意 -A 选项后面还有一个句点。git add -A 表示添加所有内容，git add . 表示添加新文件和编辑过的文件不包括删除的文件；git add -u 表示添加编辑或者删除的文件，不包括新添加的文件。 2.、git commit -m “提交注释” 3、git push origin 分支名称，一般使用： git push
深入理解Git基本原理
chenglinhust的专栏
11-07 1192
深入理解Git基本原理 资料： 1.  http://my.oschina.net/sunchp/blog/346076 2.  http://www.nowamagic.net/academy/detail/48160207 3.  pdf文档 明天完成~~~~~
深入理解Git (一) － 元数据
hongchangfirst
08-10 4154
上节我们了解了Git的对象存储方式，那么这节我们看看Git是在哪里存储这些信息，另外，Git仓库是根据什么知道仓库的元信息呢？ 我们首先git init，git会在目录下创建一个.git的隐藏目录，这个目录里存储了关于这个仓库的所有元数据。Git对象就存在其下的objects文件夹内。所以有必要看一下这里边都还存储了什么东西： 首先.git目录下有五个文件夹和三个文件： 1 branches
深入理解git内部原理
hunter的博客
01-17 252
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency 上面这句话摘自git官网，意思是说git是一个分布式版本控制系统，快速高效的处理大小型项目...
个人对GIT的理解
weixin_43733139的博客
04-07 1263
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录GIT一、GIT是什么？二、GIT 结构1.工作区2.暂存区3.本地库4.远程库使用步骤 GIT 提示：这里可以添加本文要记录的大概内容： 自己对git的理解 提示：以下是本篇文章正文内容，下面案例可供参考 一、GIT是什么？ GIT就是一个共享代码库，代码放在网上统一管理，大家谁修改了代码都可以在网上改，这样可以实现多人并发开发一个大项目。 但是在代码统一管理的时候有一个问题就出现了，就是两个人同时修改了一个文件，怎么协调这.
git查用命令
weixin_45901902的博客
12-20 1134
一、 Git 常用命令速查 git branch 查看本地所有分支 git status 查看当前状态 git commit 提交 git branch -a 查看所有的分支 git branch -r 查看远程所有分支 git commit -am “init” 提交并且加注释 git remote add origin git@192.168.1.119:ndshow git push origin master 将文件给推到服务器上 git remote show origin 显示远程库origin

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值