穆瑾轩
穆瑾轩

Git&GitHub就是这么简单

Git&GitHub就是这么简单

1、GitHub的历史

    可能大家都听过Git和GitHub，关于他们也有很多的描述，要说清楚他们之间的关系，故事还得从那一年说起。

时间 描述
1970-80年初

    最初美国贝尔实验室的Ken Thompson，以BCPL语言为基础，设计出很简单接近硬件的B语言，并用B语言写了第一个UNIX操作系统；早期程序员可以用手工的方式进行备份，并以注释或者新建文本文件来记录变动，如使用cp 命令备份，使用tar命令将一些文件归为一个.tar文件。

    后来Walter F. Tichy使用C开发了RCS (Revision Control System)用于版本控制，RCS允许多个用户同时读取文件，但只允许一个用户锁定(locking)并写入文件 (类似于多线程的mutex)。RCS的互斥写入机制避免了多人同时修改同一个文件的可能，但代价是程序员长时间的等待，给团队合作带来不便。（RCS本地版本控制系统）
1986

    直到1986年，Dick Grune写了一系列的shell脚本用于版本管理，并最终以这些脚本为基础，构成了CVS (Concurrent Versions System)版本控制系统，CVS后来用C语言重写，CVS是开源软件，CVS被包含在GNU的软件包中，并因此得到广泛的推广，CVS继承了RCS的集中管理的理念，CVS引进了分支(branch)的概念，分支是主干文件在本地复制的副本，用户对本地副本进行修改，且可以在分支提交(commit)多次修改。用户在分支的工作结束之后，需要将分支合并到主干中，以便让其他人看到自己的改动。CVS也有许多被人诟病的地方，如两个用户同时合并，那么合并结果将是某种错乱的混合体。

    后来Karl Fogel和Jim Blandy（是长期的CVS用户）开发了Subversion，依赖类似于硬连接(hard link)的方式来提高效率，避免过多的复制文件本身。
1991-2001     Linux 之父 Linus Tovalds 在 1991 年创建开源的 Linux 操作系统之后，起初参与Linux开源项目的代码是由Linus Torvalds本人通过“diff”和“patch”命令来手动为别人整合代码的。Linux开源的内核项目管理起来一直很麻烦，因为项目实在是太大了，开发者花费过多的时间在版本管理上，社区的弟兄们也对这种方式表达了强烈不满。
2002     到了2002年，一个叫Tim Kemp 的人发现 Subversion 是一个非常好的版本管理系统，但是缺乏一个好的图形界面客户端程序。做一个与 Windows 外壳整合的 Subversion 客户端程序的想法是受一个叫 TortoiseCVS 的 CVS 客户端程序所启发的。Tim 研究了 TortoiseCVS 的源码并以此为 TortoiseSVN 的基础，这也就是我们现在使用的SVN（是一种集中式的版本控制系统）。    Linus Torvald本人相当厌恶CVS以及Subversion，于是Linus选择了一个商业的版本控制系统BitKeeper（分布式VCS）BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统，但前提是Linux社区的用户不去破解BitKeeper。
2005     一晃眼，到了2005年，Linux社区牛人聚集，由于社区开发Samba的Andrew好奇地破解了BitKeeper公司的分布式VCS产品然后被对方发现，导致Linux项目被BitMover公司回收了免费使用权。Linus向BitMover公司道个歉，于是Linus最终决定写一款开源的分布式VCS软件，花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！（git分布式版本控制系统）（分布式,当我们连接共享版本库时,可以先将服务器上的项目,克隆到本地,相当于每一台电脑上都有整个项目的文件备份,在没有网时也可以开发,完成开发后,可以先提交到本地仓库,当有网的时候,再提交到共享版本库,这样一来,如果我们的服务器或者我们自己的电脑出故障,我们也没有任何担心的）
2008     GitHub（Git中心枢纽），于2007年10月1日开始开发，由GitHub公司，的开发者Chris Wanstrath、PJ Hyett和Tom Preston-Werner使用Ruby on Rails编写而成，他的UI设计确实有点糟糕。网站于2008年2月以beta版本开始上线，4月份正式上线。2008年7月，发布了Gists功能，用于托管代码片段。2008年12月，发布了GitHub Pages功能，这样大家就可以基于这个的repo，创建网站了。
2011     到了2011年，GitHub公司启动GitHub Enterprise项目，探索盈利模式。也是在11月，Github拥有了100万用户。
2014     2014年5月，Atom编辑器免费开源。现在大家常用的VSCode就是基于Atom。
2018     2018年6月，微软宣布收购GitHub，耗资75亿美元。GitHub上已经有了3000万开发者。
2019     1月份，GitHub宣布私有仓库全部免费，无限创建，但是最多只能有三个合作者。因为GitHub上性别严重失衡，男性群体高达95%以上，所以GitHub经常被大家戏称为GayHub，也是全球最大同性交友网站。

    总结：Git 是由 Linux 之父 Linus Tovalds 为了更好地管理linux内核开发而创立的分布式版本控制系统。GitHub 的核心是一个名为 Git 的开源版本控制系统，Git 负责在您的计算机上本地发生的所有与 GitHub 相关的事情，GitHub可以托管各种git库，并提供一个web界面。GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单，首先点击项目站点的“fork”按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。

    不要觉得这个有多难，理清思路，一步一步来，所有问题都可以迎刃而解。

2、Git的安装及简介

2.1、git相关素语

    在了解git的使用是，我们需要先了解一下几个相关的素语，就能更好的理解git了。git的大致流程如下图所示：

Git&GitHub就是这么简单_第1张图片

2.1.1、工作区（Working Directory）

    简单的说，工作区就是一个目录，一个项目存放的地方（本地导出或新建项目的地方）。

2.1.2、暂存区（Stage）

    暂存区（stage），数据（快照）暂时存放的地方,git add就是将工作区的修改缓存在暂存区。git commit 时就是一次性把暂存区所有修改提交到仓库（分支）。

2.1.3、Repository-仓库（存储库）

     我们可以把暂存区的内容提交到我们的（本地）仓库，也叫版本库（Respository）该目录下的所有文件都会被 git 管理起来，每个文件的修改、删除、git 都能跟踪，以便随时追踪历史，和还原。

  .git 隐藏目录就是 git 的版本库，里面存了很多东西，最重要的就是 stage（index） 暂存区，还有第一个分支 master，以及指向 master 的 HEAD 指针。

Git&GitHub就是这么简单_第2张图片

    注：HEAD 是一个指针，总是指向当前分支。 

2.1.4、远程仓库（remote） 

    远程仓库其实就是指托管在因特网或其他网络中（一台服务器）的你的项目的版本库（当然也可以有好几个远程仓库）。每个人都可以从这个远程仓库克隆一份到自己的电脑上，并且各自把各自的内容提交并推送到远程仓库里，也可以从远程仓库中拉取其他人提交的文件到本地。如：GitHub、Gitlab 等都属于远程仓库。

    就好像我们购物一样，我们看到好几个商品，觉得有点意向，然后把他们添加（git add）到购物车（暂存区）里，在没提交订单前，购物车里的东西我们增增减减，最后我们终于选好了我们的商品，点击提交（commit）订单，我们提交了订单，但是还没支付，也就没有推送给商家（远程仓库）。看到花了不少钱，我们得确定下订单，于是我们找到未支付的订单列表（本地仓库），当然也能看到我们以前的一些订单，确认没问题了，我们准备支付推送（Push）给商家（远程仓库），商家就会收到这个订单。其实如果你用过SVN，对checkout和commit并不会陌生。

   在了解GitHub前，我们先来了解一下git的基本使用。

2.2、Git的安装

    我们去官网下载一个版本控制软件，地址https://git-scm.com/downloads。

    Git&GitHub就是这么简单_第3张图片

     后续步骤一直往下点就行，安装完成。后续步骤均在windows中完成。 

2.3、创建/克隆仓库

2.3.1、git init

    创建一个空的 Git 存储库或重新初始化一个现有的存储库。我们均可以使用git init --help 命令来查看帮助文档。

# 语法：
git init [-q | --quiet] [--bare] [--template=]
          [--separate-git-dir ] [--object-format=]
          [-b  | --initial-branch=]
          [--shared[=]] [directory]

#-------------------常用命令--------------------
# 在当前目录新建一个 Git 仓库
$ git init

# 新建一个目录，并将其初始化为 Git 仓库
$ git init [project-name]

# 为新创建的存储库中的初始分支使用指定的名称
$ git -b [branch-name]

2.3.2、git clone

    将存储库克隆到新目录中 

语法：
git clone [--template=]
          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
          [-o ] [-b ] [-u ] [--reference ]
          [--dissociate] [--separate-git-dir ]
          [--depth ] [--[no-]single-branch] [--no-tags]
          [--recurse-submodules[=]] [--[no-]shallow-submodules]
          [--[no-]remote-submodules] [--jobs ] [--sparse] [--[no-]reject-shallow]
          [--filter=<过滤器>] [--] <存储库>
          [<目录>]

# 从远程下载一个仓库
$ git clone [url]

2.3.3、 创建仓库案例

    使用git init，在当前目录新建一个仓库，当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的。

Git&GitHub就是这么简单_第4张图片

2.4、Git目录说明

    执行 git init会在当前目录生成.git，其中就包含如下这些文件/文件夹，为了更好的了解git,我们需要了解一下这些目录的作用。

Git&GitHub就是这么简单_第5张图片

 2.4.1、hooks目录

    Git 默认会在这个目录中放置一些示例脚本。 这些脚本除了本身可以被调用外，可以设置特定的git命令后触发相应的脚本。

钩子种类 描述

提交工作流钩子

pre-commit 钩子在键入提交信息前运行；

prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行；

commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径；

post-commit 钩子在整个提交过程完成后运行。
电子邮件工作流钩子 git am命令会调用：applypatch-msg、pre-applypatch、post-applypatch这些钩子。
其它钩子

pre-rebase；可以禁止对已经推送的提交；

post-rewrite 钩子被那些会替换提交记录的命令调用；

post-checkout：git checkout 成功运行后被调用；

post-merge 钩子；

pre-push 钩子；

pre-receive钩子;

post-receive钩子;

...

2.4.2、info目录

    存储库的其他信息将记录在此目录,我们可以看到目录下有个info/exclude文件，用来 忽略指定模式的文件，和 .gitignore 类似，但是 .gitignore 是针对每个目录的。

2.4.3、logs目录

    保存所有更新的引用记录。其目录结构如下：

├── HEAD
└── refs
    ├── heads

    │   ├── master
...

    HEAD 记录所有更改记录，包括切换分支,logs/refs 下存储本地更改记录,如果有远程，也会记录远程remotes更改记录。

2.4.5、refs目录

    目录存放了各个分支（包括各个远端和本地的HEAD）所指向的commit对象的指针（引用），也就是对应的sha-1值。

2.4.6、其他文件

  • config：git配置信息，包括user.name，email，remote repository的地址，本地branch和remote branch的follow关系；(当前用户当前仓库的配置,在linux版本中，还有/etc/gitconfig，~/.gitconfig)
  • HEAD：存放的是一个具体的路径，也就是refs文件夹下的某个具体分支。意义：指向当前的工作分支。项目中的HEAD 是指向当前 commit 的引用，它具有唯一性，每个仓库中只有一个 HEAD。在每次提交时它都会自动向前移动到最新 的 commit； 
    如：
$ cat .git/HEAD
ref: refs/heads/master
  • index：存放的索引文件，可使用 git ls-files --stage 查看；
  • description：用来显示对仓库的描述信息。

2.4.7、objects目录

    Git对象是一个内容可寻址的文件系统，Git核心是一个简单的键值数据存储。可以将任何类型的内容插入到 Git 数据库中，Git 将为您返回一个唯一的键值，通过该键值可以在任意时刻再次检索该内容。

    注：这里的key 即为 SHA1计算后的值。objects目录下存储有三种对象：数据对象（blob object）、树对象（tree object）、提交对象（commit object）。

    进入.git\objects目录，我们会发现有很多2个字符的目录、info 和 pack目录。

1）info 和 pack 目录

    当存储的文件很大时，git 会进行压缩，会存储到 info 和 pack 下；

2）2个字符的目录

    这两个字母是计算的SHA1值（总共40个字符）的前两个字符，剩余的38个是该目录下的文件名。

扩展：Git 对象数据库中的三种对象

    他们是怎么存储的呢？我们需要了解一下git存储的原理，以便后面更好的理解并使用git的高级命令。

1、数据对象（blob object）

    git使用了blob对象去存储了文件的内容。使用hash-object 命令将对象内容写入数据库，以此生成一个blob object。

# 创建一个新的数据对象并将它手动存入你的新 Git 数据库中

$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4

# 这些都是底层命令 实际上我们后面会用一个高级命令
# 命令参数选项
-w: 设置该参数指示hash-object 命令将对象内容写入数据库，若不指定此选项该命令仅返回对应的键值
–stdin: 表示从标准输入读取对象内容，若不指定此选项，则必须在尾部命令给出存入数据库的路径
–: 标记后续参数类型，即 – 后面的参数会被解析为file


# 如果你对linux命令属性 | 管道的应用就不会陌生，当然我们也可以这样做
#例如：
# 在工作区中新建一个文件
echo "test content" > testdc.txt

# 将文件中的内容，写入数据库（存文件）
git hash-object -w 文件路径

# 如果不加参数，不会写入数据库（返回对应文件的键值）
git hash-obejct 文件路径

    上述命令的输出是一个 40 个字符的校验和哈希。这是 SHA-1 散列，改变内容则哈希值发送变化(和md5算法道理类似)。使用git命令查看数据库：

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

    在.git/objects目录下，我们可以看到多了一个文件，/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4,也就是说，Git存储内容的方式是使用SHA-1 散列的前2位做子目录，后38位作为存储内容的文件名。 我们使用cat-file 命令输出内容和对象类型：

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content

$ git cat-file -t d670460b4b4aece5915caf5c68d12f560a9fe3e4
blob

#参数
 -p 输出对象内容
 -t 输出对象类型

    有没有发现，当我们使用hash-object命令去git数据库中存储文件时，我们在仓库的目录（d/gitRepository）中找不到对应的文件。因为我们没给它一个文件名。只是将文件内容存储在.git/objects目录下。

2、树对象（tree object）

    为了解决存储文件名的问题，于是有了树对象,允许我们将多个文件组织到一起。Git 以类似于 UNIX 文件系统的方式存储内容，所有内容都存储为树和 blob 对象，树对应于 UNIX 目录，而数据对象（blob）对应inode 或文件内容。单个树对象包含一个或多个条目，每个条目都是 blob 或子树的 SHA-1 哈希值及其关联的模式、类型和文件名。一个树对象也可以包含另外一个树对象。

    官方的介绍都是比较精炼的，大致意思可以这么说，在实际项目过程中，我们每次提交都是一个多文件的提交。很少的时候是单文件的，那此时Git就不是单单存储一个 blob对象了，而是 tree对象。tree对象，见名知意，就是一个树对象，类似于操作系统目录，tree的分支，可能还是tree，也可能是blob。

2.1、构建树对象

    要构建树对象，并塞入到暂存区，需要使用update-index、write-tree、read-tree等命令。

1）先创建一个test.txt的数据对象（blob 对象）

# 清空之前的版本库，初始化之后，我们在工作目录中新建一个文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ echo "test version1" > test.txt

# 使用hash-object 命令将对象内容写入数据库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git hash-object -w ./test.txt
warning: LF will be replaced by CRLF in ./test.txt.
The file will have its original line endings in your working directory
fbb2ff04e2cae17293a83c5e83af505f62cd13d1

# 目前工作目录中只有一个文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ ls -l
total 1
-rw-r--r-- 1 Administrator 197121 14 Jul 21 21:57 test.txt

# 查看暂存区中的文件，现在是没有的
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s

2）使用update-index来创建test.txt文件的首个版本，并加入到暂存区，通过write-tree生成树对象，产生我们管理的项目的第一个版本。

# 将test.txt加入到暂存区中
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git update-index --add --cacheinfo 100164 fbb2ff04e2cae17293a83c5e83af505f62cd13d1 test.txt

--add 因为此文件并不在暂存区，首次需要-add
--cacheinfo 会从已存在的数据库（Object）中取得对应的内容并添加到索引中。

--文件模式：
  --100644 表明这是一个普通文件
  --100755 表示一个可执行文件
  --120000 表示一个符号链接

# git ls-files -s查看暂存区中的文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s
100755 fbb2ff04e2cae17293a83c5e83af505f62cd13d1 0       test.txt

# find .git/objects/ -type f 查看数据库中的对象
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1

# git write-tree生成树对象（给暂存区拍一张快照）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git write-tree
59e4512814d504004c6a86b2f0792adf8b004a1f

# 再次查看数据库中的对象，发现多了一个（树对象）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/59/e4512814d504004c6a86b2f0792adf8b004a1f
.git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1

# 查看对象的类型
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git cat-file -t 59e4512814d504004c6a86b2f0792adf8b004a1f
tree

     详细解析：当我们把文件添加到暂存区后，然后使用write-tree生成树对象（给暂存区拍一张快照），并存储到数据库中，这时数据库中的这个树对象，其实就是我们管理的项目的第一个版本了。   

    快照和我们平时说的备份，有什么区别呢？备份：从一个地方复制到另一个地方，两个地方的数据都是完整独立的，而快照：更像文件系统的一种存储标记，比如，我们有一个文件a(1,2,3)--将其内容修改a(1,4,3)，并生成一个快照A,快照A的存储仅仅是修改过程中数据的变化部分，即记录（数据位置2-变成了-4）而不是像备份复制那样某个路径下完整的数据。

3）新增new.txt 将new.txt和test.txt的第二个版本加入到暂存区，并生成树对象。

# 工作目录中新建一个new.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ echo "new v1" > new.txt

# 将new.txt加入到数据库中（生成blob 对象）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git hash-object -w new.txt
warning: LF will be replaced by CRLF in new.txt.
The file will have its original line endings in your working directory
eae614245cc5faa121ed130b4eba7f9afbcc7cd9

# 查看此时数据库中的对象
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/59/e4512814d504004c6a86b2f0792adf8b004a1f
.git/objects/ea/e614245cc5faa121ed130b4eba7f9afbcc7cd9
.git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1

# 查看修改前的test.txt文件内容
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ cat test.txt
test version1

# 修改test.txt的文件内容
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim test.txt

# 将修改的test.txt文件加入到数据库中（生成blob 对象）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git hash-object -w test.txt
warning: LF will be replaced by CRLF in test.txt.
The file will have its original line endings in your working directory
3a31d973aae0a644183e2e72395e683973f4acc1

# 查看数据库中的对象
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/3a/31d973aae0a644183e2e72395e683973f4acc1
.git/objects/59/e4512814d504004c6a86b2f0792adf8b004a1f
.git/objects/ea/e614245cc5faa121ed130b4eba7f9afbcc7cd9
.git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1

# 将test.txt加入的暂存区，此时暂存区中的test.txt已经更新了（加入到暂存区一定要指定文件，加入文件名写错了，也会覆盖）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git update-index --cacheinfo 100644 3a31d973aae0a644183e2e72395e683973f4acc1 test.txt

# 将new.txt加入到暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git update-index --add --cacheinfo 100644 eae614245cc5faa121ed130b4eba7f9afbcc7cd9 new.txt

# 查看暂存区，当前暂存区和工作目录中的内容一致
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s
100644 eae614245cc5faa121ed130b4eba7f9afbcc7cd9 0       new.txt
100644 3a31d973aae0a644183e2e72395e683973f4acc1 0       test.txt

# 生成树对象（拍第二个快照，也就是我们项目的第二个版本）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git write-tree
434388dae0ea7dd251c040ff1735d5a59454133c

# 查看数据库中的对象
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ find .git/objects/ -type f
.git/objects/3a/31d973aae0a644183e2e72395e683973f4acc1
.git/objects/43/4388dae0ea7dd251c040ff1735d5a59454133c
.git/objects/59/e4512814d504004c6a86b2f0792adf8b004a1f
.git/objects/ea/e614245cc5faa121ed130b4eba7f9afbcc7cd9
.git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1

    详细解析：我们往数据库中新增了一个数据对象，并修改了test.txt,也将其加入到数据库中，次数数据库中的对象有4个，分别是：

    .git/objects/3a/31d973aae0a644183e2e72395e683973f4acc1    test.txt的第二版本
    .git/objects/59/e4512814d504004c6a86b2f0792adf8b004a1f    树对象，即项目的第一个版本
    .git/objects/ea/e614245cc5faa121ed130b4eba7f9afbcc7cd9    new.txt的第一个版本
    .git/objects/fb/b2ff04e2cae17293a83c5e83af505f62cd13d1   test.txt的第一个版本

    当我们把修改后的test.txt和new.txt加入到暂存区后，此时工作目录和暂存区中的内容是一致的，使用git write-tree命令生成树对象，我们的数据库中就多了一个树对象

    .git/objects/43/4388dae0ea7dd251c040ff1735d5a59454133c    树对象，即项目的第二个版本

4)read-tree命令的使用

    若需要对某个存在三级文件夹的二级文件夹进行write-tree操作， 在把三级文件夹下的所有修改文件生成blob后，进行整体tree对象化，之后再与二级文件夹同级的文件夹和文件进行相同操作。此时就需要用到： read-tree 命令。但是实际操作中我们并不会这么去手动操作，将一棵树接到另一颗树上。

# 该操作会把tree对象59e4512814d504004c6a86b2f0792adf8b004a1f 加入暂存区中，并取名bak（实际Git会把此prefix默认为文件夹的名字）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git read-tree --prefix=bak 59e4512814d504004c6a86b2f0792adf8b004a1f

# 查看暂存区中的内容
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s
100755 fbb2ff04e2cae17293a83c5e83af505f62cd13d1 0       bak/test.txt
100644 eae614245cc5faa121ed130b4eba7f9afbcc7cd9 0       new.txt
100644 3a31d973aae0a644183e2e72395e683973f4acc1 0       test.txt

# 生成新的树对象
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git write-tree
9de7f27122d384812680907c0052ab66454c3fb4

    第三棵树：9de7f27122d384812680907c0052ab66454c3fb4（项目的第三个版本）

最终就形成了如图所示效果：

Git&GitHub就是这么简单_第6张图片

    项目的第三个版本并没有修改文件，只是将第一棵树加入到暂存区（索引），并生成了一颗新的树。现在呢，我们已经有了三个树对象，分别代表了我们要跟踪的项目的不同快照，如果想重用这些快照，就必须记住这三个哈希值，并且我们也不知道是谁保存了这些快照，什么时候保存的，以及为什么保存这些快照，于是就有了提交对象（commit object）。

3、提交对象（commit object）

    提交对象能为你保存基本信息，我们可以通过调用commit-tree命令创建额提交对象，为此需要指定一个树对象的哈希值，以及该提交对象的父提交对象（第一次提交，则没有父对象）。

1）为第一棵树创建一个提交对象

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository/.git (GIT_DIR!)
$ echo 'first commit' | git commit-tree 59e4512814d504004c6a86b2f0792adf8b004a1f
384c65d38b4b57e074fd5bb8e1602516a2ac6b62

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository/.git (GIT_DIR!)
$ git cat-file -t 384c65d38b4b57e074fd5bb8e1602516a2ac6b62
commit

# 查看提交对象的信息，包含了第一棵树及作者、提交者（config中指定的user.name、user.email信息）及提交说明，提交对象是对树对象的一次封装
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository/.git (GIT_DIR!)
$ git cat-file -p  384c65d38b4b57e074fd5bb8e1602516a2ac6b62
tree 59e4512814d504004c6a86b2f0792adf8b004a1f
author mjx <[email protected]> 1626965281 +0800
committer mjx <[email protected]> 1626965281 +0800

first commit

2）为第二棵树创建一个提交对象

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository/.git (GIT_DIR!)
$ echo 'second commit' | git commit-tree 434388 -p 384c65
a78a51fff0535891210554d1bdcb8f0f3962fc11

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository/.git (GIT_DIR!)
$ git cat-file -p a78a51fff0535891210554d1bdcb8f0f3962fc11
tree 434388dae0ea7dd251c040ff1735d5a59454133c
parent 384c65d38b4b57e074fd5bb8e1602516a2ac6b62
author mjx <[email protected]> 1626965733 +0800
committer mjx <[email protected]> 1626965733 +0800

second commit

 于是就能形成如官网所说的这种效果：

Git&GitHub就是这么简单_第7张图片

     总结：项目的一个版本是一个提交对象，本质上项目的一个快照是一个树对象。

      1）生成blob对象：git hash-object -w 文件路径    

      2）加入暂存区（更新索引）：

                git update-index --add 文件路径

                git update-index --add --cacheinfo mode sha-1 文件名

                git read-tree --prefix=test sha-1(某个tree的sha-1) 把某个tree读入索引中

     3）创建树对象: git write-tree

     4）创建commit对象： git commit-tree sha-1 -m "提交信息"

                echo "提交信息" | git commit-tree sha-1 -p 父级sha-1

     5）其他底层命令：

               对象的内容查询：git cat-file -p  sha-1

               对象的类型查询：git cat-file -t  sha-1

               查看暂存区：git ls-files -s

   以上就是git的底层原理,一般我们使用高级命令。

2.5、Git文件的四种状态

    引用官方一张文件状态的生命周期图：

Git&GitHub就是这么简单_第8张图片

2.5.1、Untracked-未跟踪

    此文件工作区中, 但并没有加入到git库, 不参与版本控制，通过git add 状态变为Staged。工作目录下的文件要么是未跟踪，要么是已跟踪（已跟踪有三种状态：未修改、已修改、已暂存）

2.5.2、Unmodified-已经入库/未修改

    版本库中的文件快照内容与工作区中完全一致，这种类型的文件可以是已经提交到版本库的文件或从远程仓库克隆到本地库而检出到工作区中的文件。如果它被修改, 而变为Modified,如果使用git rm移出版本库, 则成为Untracked文件。

2.5.3、Modified-已修改

    对工作区中的文件而言，文件已经修改了，但并没有进行其他操作。如果通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodified状态, 这个git checkout即从库中取出文件, 覆盖当前修改。

2.5.4、Staged-暂存状态

    在工作区中的文件被添加到暂存区，在工作区中新增/修改的文件使用git add可进入暂存staged状态,执行git commit则将修改同步到本地库中, 这时库中的文件和工作区的文件又变为一致, 文件为Unmodified状态，执行git reset HEAD filename取消暂存, 文件状态为Untracked/Modified.

3、Git高级命令使用

    前面我们已经使用到了git init初始化了一个仓库，初始化后，在当前目录下会出现一个名为.git的目录，所有Git需要的数据和资源都存放在这个目录。

3.1、初始化配置

    Git 的配置文件是 .gitconfig，可以放在用户的主目录（全局配置）下或项目目录下（项目配置）。

# 显示当前的 Git 配置
$ git config --list

# 编辑 Git 配置
$ git config -e [--global]

# 设置用来提交代码的用户信息
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"

3.2、管理文件（增、删、改、查）

3.2.1、添加文件-git add-(增)

    git add的作用是将文件/修改内容添加到暂存区。新增操作我们一般的执行步骤是：1）先执行git status 查看工作目录的文件状态；2）执行git add 添加文件；3）执行git commit -m 提交暂存区当前内容到仓库。

# 将指定文件添加到暂存区中
$ git add [file1] [file2] ...

# 将指定目录添加到暂存区中，包括子目录
$ git add [dir]

# 将当前目录中的所有文件添加到暂存区中
$ git add .

# 在添加每个更改之前都进行确认
# 对于同一个文件的多个更改，建议分开提交
$ git add -p

使用案例：

    1）首先在git管理的目录下，新建两个文件（test.txt）；

    2）然后使用git add test.txt  将文件添加到暂存区（Stage），此时的文件状态为已暂存(staged)；

    3）使用git Gui工具可以看到，暂存区已经有一个文件了。（当然，我们也可以使用命令查看仓库的状态git status ）

​​Git&GitHub就是这么简单_第9张图片

详细解析：

    我们使用git add test.txt 文件相当于执行了:

    git hash-object -w ./test.txt 生成了blob对象，并保存了相应的sha-1值

    git update-index --cacheinfo sha-1 命令把 test.txt 放入了暂存区,并添加到了索引文件（index）中

    注：git add 是先把内容放到了数据库中，在从数据库中取文件将其放入暂存区，并不是直接从工作目录到暂存区。

3.2.2、查看文件的状态-git status-（查）

    git status查看工作目录中文件的状态（已跟踪（已提交、已暂存、已修改）、未跟踪）

# 以长格式输出输出,这是默认设置（可以不写后面的参数）。
$ git status --long  

# 以短格式输出输出。
$ git status -s

 使用案例：查看我们添加的文件test.txt

# 查看工作目录中文件的状态
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached ..." to unstage)
        new file:   test.txt

详细解析： 

    使用 git status 后，Git会对所有文件进行sha-1值计算，若计算到与.git/index索引中得对应文件的sha-1值不同了，则代表有所改动，则标记为 已修改（Modify），若发现索引中不存在对应文件的sha-1值， 则标记为未跟踪（Untracked ）。

    上图告诉我们一个新文件，test.txt还没被提交，同时也告诉我们可以使用it rm --cached ...命令将文件移出暂存区。

 3.2.3、提交-git commit-（新增/删除/修改的提交）

    git commit提交暂存区当前内容并添加描述信息（对仓库的更改）

# 将暂存区中的文件提交到代码仓库
$ git commit -m "commit message"

# 将指定的文件从暂存区中提交到仓库
$ git commit [file1] [file2] ... -m "commit message"

# 将工作区的更改直接提交到仓库
$ git commit -a

# 提交前展示所有的变动
$ git commit -v

# 使用新提交代替上次提交
# 如果代码没有任何变动，将会用于重写上次提交的提交信息
$ git commit --amend -m "commit message"

# 重做上次的提交，并将指定的文件包含其中
$ git commit --amend [file1] [file2] ...

使用案例：

# 提交暂存区的文件到仓库，如果注释比较少可以使用-m参数添加，如果注释较多，则不加参数会进入文件编辑模式
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -m "第一次提交test.txt"
[master (root-commit) 2ca6bc4] 第一次提交test.txt
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

# 查看提交信息
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log
commit 2ca6bc4bea79b316fed32ceb1a9bbbe8e0ec6efb (HEAD -> master)
Author: mjx <[email protected]>
Date:   Sat Jul 24 11:00:56 2021 +0800

    第一次提交test.txt

# 此时工作目录和仓库是一致的
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
nothing to commit, working tree clean

详细解析： 

    我们使用git commit -m "第一次提交test.txt" 文件相当于执行了:

    git write-tree 生成了树（tree）对象，并产生了相应的树对象的sha-1值（保存项目的快照）

    git commit-tree sha-1 -m 同时执行了git commit-tree对树对象的封装，包含提交注释、提交者的信息、时间，这是项目一个版本。

3.2.4、查看未暂存/未提交的修改-git diff-（查）

    查看未暂存/未提交的修改。

# 显示暂存区和工作区的文件差别
$ git diff

# 显示暂存区和上一次提交的差别
$ git diff --cached [file]

# 显示工作区和当前分支的最近一次提交的差别
$ git diff HEAD

# 显示指定两次提交的差别
$ git diff [first-branch]...[second-branch]

# 显示今天提交了多少代码
$ git diff --shortstat "@{0 day ago}"

使用案例一：显示暂存区和工作区的文件差别

# 查看暂存区文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s
100644 915c628f360b2d8c3edbe1ac65cf575b69029b61 0       test.txt

# 编辑test.txt文件，新增一行内容test v2
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim test.txt

# 使用git diff 命令查看暂存区和工作目录的区别，
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git diff
warning: LF will be replaced by CRLF in test.txt.
The file will have its original line endings in your working directory
diff --git a/test.txt b/test.txt
index 915c628..95b7ed0 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,2 @@
 test v1
+test v2

 详细解析：我们提交文件到仓库并不会清空暂存区的，所以当我们修改工作目录中的文件后，使用git diff 目录就能看到工作目录和暂存区中的区别。

使用案例一：显示暂存区和上一次提交的差别

# 将文件加入到暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git add test.txt
warning: LF will be replaced by CRLF in test.txt.
The file will have its original line endings in your working directory

# 查看暂存区和上一次提交的差别
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git diff --cached
diff --git a/test.txt b/test.txt
index 915c628..95b7ed0 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,2 @@
 test v1
+test v2

3.2.5、删除文件-git rm file-（删） 

# 将指定文件从工作区删除，并将本次删除添加到暂存区
$ git rm [file1] [file2] ...

# 停止追踪指定的文件，不会删除文件
$ git rm --cached [file]

删除文件使用案例：

    1）使用git rm test.txt 删除文件（工作区中的文件被删除），在暂存区有待提交的删除文件；

    2）使用git commit删除（版本库）文件；

    3）而使用 git rm --cached test_rmcached.txt 停止跟踪文件，在暂存区的文件被删除了，本地文件恢复Untracked状态。

# 删除文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git rm test.txt
rm 'test.txt'

# 工作目录被删除的文件待提交
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        deleted:    test.txt

# 删除文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -m "删除test.txt"
[master 74338f9] 删除test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

# 新建一个文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim test_rmcached.txt

# 将文件加入都暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git add test_rmcached.txt

# 查看工作目录文件的状态
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        new file:   test_rmcached.txt

# 停止跟踪文件，但不删除文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git rm --cached test_rmcached.txt
rm 'test_rmcached.txt'

# 文件为未跟踪状态
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)
        test_rmcached.txt

详细解析：git rm 除了删除本地文件外也会将删除动作加入到暂存区； 

3.2.6、重命名/移动文件-git mv （删）

# 移动/重命名文件
$ git mv  

# 强制移动/重命名文件
$ git mv -f

使用案例：使用mv 命令将readme.txt 重命名为test.txt

# 新建readme.txt文件后提交到仓库，然后查看暂存区中的文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git ls-files -s
100644 504a7438c95afbd7f5280d756fb405bd85fbf19e 0       readme.txt

# 移动/重命名文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ mv readme.txt test.txt

# 查看工作目录中文件的状态
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        deleted:    readme.txt

Untracked files:
  (use "git add ..." to include in what will be committed)
        test.txt

no changes added to commit (use "git add" and/or "git commit -a")

3.3、查看提交历史-git log

    使用该命令后，去 .git/logs 下寻找当前分支对应的文件名，文件中的内容即为每一次提交的信息。

# 显示提交历史（它会列出所有历史记录，显示提交对象的哈希值，作者、提交日期、和提交说明）
$ git log

# 显示前n条提交历史
$ git log -n

# 只显示提交的 SHA1 值和提交信息
$ git log --oneline

# 显示两天前的提交历史
$ git log --since=2.days

# 指定作者
$ git log --author=mjx

# 指定关键字为“test”的所有提交
$ git log --grep=test

# 格式化输出模板
$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

# 以列表方式查看指定文件的提交历史
$ git blame

使用案例：

# 只显示提交的 SHA1 值和提交信息
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
c9b83dc (HEAD -> master) 移动删除文件
158f2d9 tjsc
f4b81ca tj readme
2ca6bc4 第一次提交test.txt

# 显示提交注释中包含tj的历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --grep="tj" --oneline
2261741 (HEAD -> master) tj
158f2d9 tjsc
f4b81ca tj readme

# 格式输出提交历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
* 2261741 - (HEAD -> master) tj (8 minutes ago) 
* 4196d41 - 提交修改 (9 minutes ago) 
* cc5b6e6 - 提交修改后的文件 (11 minutes ago) 
* c9b83dc - 移动删除文件 (8 hours ago) 
* 158f2d9 - tjsc (8 hours ago) 
* f4b81ca - tj readme (8 hours ago) 
* 2ca6bc4 - 第一次提交test.txt (11 hours ago) 


# 以列表的形式显示提交记录
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git blame test.txt
cc5b6e6a (mjx 2021-07-24 21:45:52 +0800 1) readme v1
4196d419 (mjx 2021-07-24 21:47:38 +0800 2) test v2
22617412 (mjx 2021-07-24 21:49:28 +0800 3) blame 1
22617412 (mjx 2021-07-24 21:49:28 +0800 4) blame 1-1

3.4、分支

    几乎所有的版本控制系统都以某种形式支持分支，使用分支意味着你可以把你的工作从开发主线上分离出来，以免影响开发主线，在很多的版本控制系统中需要创建一个源代码的副本。对于大项目来说，这样的过程耗费很多时间。而Git的分支模型及其的高效轻量。

    在git上创建一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

3.4.1、查看分支列表-git branch

# 查看分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch
* master

详细解析：

    每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支，使用git branch，输出的是master，它是一个主分支（默认）。当我们在提交的时候，指针也会随着提交往前走。

    前面我们在介绍目录的时候，有一个叫HEAD的文件和一个refs的目录。

    HEAD：存放的是一个具体的路径，也就是refs文件夹下的某个具体分支，意义：指向当前的工作分支。项目中的HEAD 是指向当前 commit 的引用，它具有唯一性，每个仓库中只有一个 HEAD。在每次提交时它都会自动向前移动到最新的commit；

    refs的目录：目录存放了各个分支，所指向的commit对象的指针（引用），也就是对应的sha-1值。

    当我们打开HEAD文件，里面的内容是ref: refs/heads/master，说明当前的分支是master主分支。

    我们在进入refs/heads目录下，看到有个文件master，打开它，里面的有个哈希值（8707bd8b38058abbe339f03be91f4f0804a61369），查看后它是一个提交对象，也是最后一次的提交对象。

Git&GitHub就是这么简单_第10张图片

    由此看来：分支就是一条提交对象串成的时间线，并且有一个活动的指针，指向当前最新的提交对象。

3.4.2、创建分支-git branch

使用案例：git branch demo 命令创建一个demo分支

# 使用命令查看提交历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
8707bd8 (HEAD -> master) 第四次提交 mv readme文件
68c6120 第三次提交 readme.txt
ea4add4 修改test内容提交
3a003f5 第一次提交test

# 创建一个demo分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch demo

# 再次查看提交历史，我们发现(HEAD -> master, demo)里多了一个demo
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
8707bd8 (HEAD -> master, demo) 第四次提交 mv readme文件
68c6120 第三次提交 readme.txt
ea4add4 修改test内容提交
3a003f5 第一次提交test

    创建好了一个demo分支，我们看到refs目录下也多出了一个文件，同时它里面也存在着和master同样的哈希值（8707bd8b38058abbe339f03be91f4f0804a61369），但是我们的HEAD文件中的内容依然是：ref: refs/heads/master，说明当前指针还在master主分支上。所以实际上分支，也是一个 commit 对象的引用。只是在GIT中专门有文件记录了分支名和指向。

Git&GitHub就是这么简单_第11张图片

    当然还有git checkout -b /git switch -c 可以创建分支，这个更常用，我们甚至可以通过创建文件的方式，直接创建branch。 

cd .git/refs/head/
echo '最新提交对象的哈希值' > 分支名

# 创建并切换到新分支
git switch -c dev

3.4.3、切换分支-git checkout 

# 切换分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git checkout demo
Switched to branch 'demo'
D       readme.txt

# (demo)切换成功
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$

# 在demo分支上新建文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$ echo "demo v1" > demo.txt

# 将demo.txt加入暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$ git add ./
warning: LF will be replaced by CRLF in demo.txt.
The file will have its original line endings in your working directory

# 将demo.txt提交的仓库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$ git commit -m "我是demo分支的 demo.txt"
[demo 4acce70] 我是demo分支的 demo.txt
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 demo.txt
 delete mode 100644 readme.txt

# 查看我的提交记录
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$ git log --oneline
4acce70 (HEAD -> demo) 我是demo分支的 demo.txt
8707bd8 (master) 第四次提交 mv readme文件
68c6120 第三次提交 readme.txt
ea4add4 修改test内容提交
3a003f5 第一次提交test

详细解析：

    当使用 git checkout 的时候， Git内部实际上就是把当前的HEAD指针给指向了另一个分支，而实际上也就是把 .git/HEAD 文件内容修改为切换的分支，而 .git/HEAD 内容指向的就是 .git/refs/heads中的分支，此文件内容又是一个 commit 对象的 sha-1值，所以也就间接指向了某个具体的commit对象了， 从这个commit对象可得到它的父级对象，依次类推，即可得到完整的代码。

当前分支示意图：

Git&GitHub就是这么简单_第12张图片

3.4.4、强制删除分支-git branch -D

    当我们的测试代码使用完成后，已经完成了他的使命，我们不需要它了。需要删除分支。可以使用：

    git branch -D 强制删除分支。

    git branch -d ,只能删除空分支/已经被合并的分支。

# 切回主分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (demo)
$ git checkout master
Switched to branch 'master'

# 查看当前分支的提交历史，这里没有demo分支的提交记录，因为还没合并，不会影响主分支，但是demo.txt在仓库中还是存在的
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
8707bd8 (HEAD -> master) 第四次提交 mv readme文件
68c6120 第三次提交 readme.txt
ea4add4 修改test内容提交
3a003f5 第一次提交test

# 删除分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch -D demo
Deleted branch demo (was 4acce70).

# 查看分支列表，只剩主分支了
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch
* master

3.4.5、在指定的提交对象上创建新的分支

    前面我们是默认在当前最新的提交对象上创建新的分支，如果我想要在更早的版本上创建分支呢？我们可以使用：git branch name commithash，在指定的提交对象上新建分支。

使用案例：

# 查看提交的历史记录
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline --decorate --graph --all
* 8707bd8 (HEAD -> master) 第四次提交 mv readme文件
* 68c6120 第三次提交 readme.txt
* ea4add4 修改test内容提交
* 3a003f5 第一次提交test

# 指定提交对象创建分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch firstTime 3a003f5

# 切换到新的分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git checkout firstTime
Switched to branch 'firstTime'

# 查看当前分支下的内容
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (firstTime)
$ ls -l
total 1
-rw-r--r-- 1 Administrator 197121 9 Jul 25 00:15 test.txt

# 查看项目的分支历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (firstTime)
$ git log --oneline --decorate --graph --all
* 8707bd8 (master) 第四次提交 mv readme文件
* 68c6120 第三次提交 readme.txt
* ea4add4 修改test内容提交
* 3a003f5 (HEAD -> firstTime) 第一次提交test

3.4.6、切换分支时的注意事项

    切换分支时，会更改：HEAD、暂存区和工作目录。应尽量保持当前分支的工作目录是干净的。（没有未跟踪的文件，所有的文件应处于已提交状态）

# 初始化一个仓库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (test)
$ git init
Initialized empty Git repository in D:/gitRepository/.git/

# 新建a.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ echo "a" > a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ echo "b" > b.txt

# 将文件添加至暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git add ./
warning: LF will be replaced by CRLF in a.txt.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in b.txt.
The file will have its original line endings in your working directory

# 提交文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -m "提交a b"
[master (root-commit) 3d641b3] 提交a b
 2 files changed, 2 insertions(+)
 create mode 100644 a.txt
 create mode 100644 b.txt

# 创建分支（这个命令更常用，创建成功后并且切换到分支上）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git checkout -b test
Switched to a new branch 'test'

# 创建c.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (test)
$ echo "c" > c.txt

# 工作区中存在未跟踪的文件，直接切换到主分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (test)
$ git checkout master
Switched to branch 'master'

# 在主分支上还保存着test分支未跟踪的文件，这对git来说是很好的功能，保证用户的文件不应切换而丢失，但是这样可能会影响到主分支，所以建议切换分支时保存当前分支没有未跟踪的文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)
        c.txt

nothing added to commit but untracked files present (use "git add" to track)

详细解析：当我们在test分支上新增了一个文件，但是没有被git管理起来，就切换到主分支。在主分支上还保存着test分支未跟踪的文件，这对git来说是很好的功能，保证用户的文件不应切换而丢失，但是这样可能会影响到主分支，所以建议切换分支时保存当前分支没有未跟踪的文件。

3.4.7、创建及切换分支新命令-git switch 

    因为git checkout 命令职责较多、不够明确，git 2.23 版本新增了switch命令则专门用来切换分支、创建并切换分支。

# 创建一个新的分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository ((3d641b3...))
$ git switch -c swtest
Switched to a new branch 'swtest'

# 查看提交历史，当前分支在swtest分支上
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (swtest)
$ git log --oneline
3d641b3 (HEAD -> swtest, test, master) 提交a b

3.5、合并

    在git中合并分支有三种方法，分别是merge，rebase，cherry-pick。

3.5.1、git merge简介

    git-merge命令是用于将两个或两个以上的开发历史合并在一起的操作。可以使用git merge -h 命令查看相关参数。语法：

语法：git merge [] [...]

    选项：

    --stat              会在合并结果的末端显示文件差异的状态。文件差异的状态也可以在git配置文件中的merge.stat配置
    --log[=]     在合并提交时，除了含有分支名以外，还将含有最多n个被合并commit节点的日志信息。
    --squash        压缩合并。将待合并的分支的内容压缩成一个新的提交合并进来。
    --commit        参数使得合并后产生一个合并结果的commit节点。该参数可以覆盖--no-commit
    --no-commit   参数使得合并后，为了防止合并失败并不自动提交，能够给使用者一个机会在提交前审视和修改合并结果。
    -e, --edit         用于在成功合并、提交前调用编辑器来进一步编辑自动生成的合并信息。
    --ff                  是默认参数（指fast-forward命令），快速合并。如果合并过程中出现冲突，git会显示出冲突。如：git merge --ff branchName
    --ff-only          只有能快速合并的情况下才合并。如果合并过程中出现冲突，git会自动about此次merge
    --no-ff            不使用快速合并，会生成一次新的提交记录，这个记录只是标识这里进行了一次merge操作。
    -s, --strategy  用于指定合并的策略。默认情况如果没有指定该参数，git将按照下列情况采用默认的合并策略,合并节点只含有单个父节点时（如采用fast-forward模式时），采用recursive策略。合并节点含有多个父节点时(如采用no-fast-forward模式时)，采用octopus策略

语法：git merge --abort

    放弃本次merge操作。该命令仅仅在合并后导致冲突时才使用。git merge --abort将会抛弃合并过程并且尝试重建合并前的状态。但是，当合并开始时如果存在未commit的文件，git merge --abort在某些情况下将无法重现合并前的状态。（建议使用git-stash命令将这些未commit文件暂存起来）

 语法：git merge --continue  继续本次merge操作

    在了解git-merge命令前，我们先了解一下Git 合并的策略，其中常见的是 Fast-forward、Recursive 、Ours、Theirs、Octopus。 Git 默认会帮你自动挑选合适的合并策略，如果你需要强制指定，使用git merge -s <策略名字>。

扩展：合并策略

    下面的策略作为了解，这里只简单介绍一下。

策略一：Fast-forward

Git&GitHub就是这么简单_第13张图片

     Fast-forward是最简单的一种合并策略，适用于只有一个分叉时，采用这种方式。

    如：（上图）合并 bugfix分支到master分支时，如果master分支的状态没有被更改过，这种合并不会产生冲突，只需要将master的指针往前移（如下图效果），这样的合并被称为fast-forward合并，即快进合并。

Git&GitHub就是这么简单_第14张图片

策略二：Recursive

    Recursive 是 Git 分支合并策略中最重要也是最常用的策略，是 Git 在合并两个有分叉的分支时的默认行为。

    其算法可以简单描述为：递归寻找路径最短的唯一共同祖先节点，然后以其为 base 节点进行递归三向合并，有冲突需要手动解决，然后生成新的提交并合并。

Git&GitHub就是这么简单_第15张图片

策略三：Ours

     该参数将强迫冲突发生时，自动使用当前分支的版本。这种合并方式不会产生任何困扰情况，甚至git都不会去检查其他分支版本所包含的冲突内容这种方式会抛弃对方分支任何冲突内容。如：git merge -s ours bugfix，则会放弃bugfix（X、Y）的内容，然后产生一个新提交并合并，此时的E和D的内容是一致的。

策略四：theirs

    和ours相反。完全抛弃掉当前分支的文件内容，直接采用对方分支的文件内容。git merge -s theirs bugfix,则会放弃C、D的提交内容，使用bugfix的内容，则E节点的内容与bugfix的内容完全一致。

策略五：Octopus

    一般来说我们的合并节点都只有两个 parent，而这种合并策略可以做两个以上分支的合并，这也是 git merge 两个以上分支时的默认行为。比如在 dev1 分支上执行git merge dev2 dev3。

3.5.2、git merge-Fast-forward合并

    Fast-Forward Merge是git的各种合并策略中最容易理解、最简单的一种情况。

    语法：git merge branchName

    案例描述：当我们在做项目时，生产上有个紧急的bug需要修复。在master分支上新建两个文件a.txt,b.txt，然后创建bugfix分支,新建x.txt,y.txt,然后在将代码提交。

使用案例：

# 省略创建a.txt b.txt的过程，查看当前提交历史

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
f24ebdb (HEAD -> master) 第二次提交 b.txt
7b5880d 第一次提交 a.txt

# 创建并切换到bugfix分支

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git switch -c bugfix
Switched to a new branch 'bugfix'

# 省略创建x.txt y.txt的过程，查看当前提交历史

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (bugfix)
$ git log --oneline
ac4baf2 (HEAD -> bugfix) 第四次提交 y.txt
5b217e7 第三次提交 x.txt
f24ebdb (master) 第二次提交 b.txt
7b5880d 第一次提交 a.txt

# 切换到主分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (bugfix)
$ git switch master
Switched to branch 'master'

# 使用 git merge bugfix将bugfix合并到主分支上
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git merge bugfix
Updating f24ebdb..ac4baf2
Fast-forward
 x.txt | 1 +
 y.txt | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 x.txt
 create mode 100644 y.txt

# 查看提交历史记录（依然是四个,如果想要生成新的提交节点，可以使用--no-ff选项）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
ac4baf2 (HEAD -> master, bugfix) 第四次提交 y.txt
5b217e7 第三次提交 x.txt
f24ebdb 第二次提交 b.txt
7b5880d 第一次提交 a.txt

# 删除bugfix分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch -d bugfix
Deleted branch bugfix (was ac4baf2).

# 查看提交历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline
ac4baf2 (HEAD -> master) 第四次提交 y.txt
5b217e7 第三次提交 x.txt
f24ebdb 第二次提交 b.txt
7b5880d 第一次提交 a.txt

详细解析：

    执行完git merge bugfix命令后，我们发现，在.git目录下多了一个文件，ORIG_HEAD文件，我们看下这个文件的内容：

    这里正是记录的master分支合并前的最后一次的提交对象，记录这个是为了做回滚操作。我们从合并后的提示信息中也能看出：Updating f24ebdb..ac4baf2，master分支的指针从f24ebdb提交对象更新成ac4baf2,Git只是简单地把master的head指针向前移动，合并就完成了，这就是所谓的Fast-Forward Merge。因为不涉及内容变更的比较，所以这种合并方式效率很高。不过它有个缺点，作为被合并的bugfix分支，它的提交历史会和master分支重合。

    如果我们想在合并后保留来自被合并分支的提交历史，并显式标注出合并发生的位置，那就需要在执行合并时加上参数--no-ff。当然，这样也表示我们在合并时将不使用Fast-Forward Merge策略。 

    首先我们执行：git reset --hard f24ebdb 回退到合并前的状态；

    再执行：git merge --no-ff -m "第五次提交 合并" bugfix

Git&GitHub就是这么简单_第16张图片

    两个分支的合并，git采用recursive（递归） 策略合并，也叫three-Way Merge（三方合并）。

什么是三方合并？git为什么采用三方合并？

Git&GitHub就是这么简单_第17张图片

     假定，我们在master分支上，有个A提交节点，我们在A的基础上创建了一个dev开发分支，并且产生了一个B提交节点，但是，这个时候其他人往master主分支上又提交了一次，产生了一个A1提交节点。

    Two-Way Merge：做法是用diff工具生成A1与A的差异，然后在B上面应用这个patch，期望得到B1，用数学的公式表示就是：B1= B + (A1 - A) ，虽然这种做法也可以，工具在帮我们做合并时，只知道两个文件在同一行上有差异，却没办法知道在合并后的版本里，到底该保留谁的版本，所以只能交给用户自己手工来决定。

    Recusive Three-Way Merge：使用三方合并的方式，Git最大的不同在于它记录了文件的提交历史，因此可以向前回溯文件修改前的“原件”。用数学的公式表示就是：B'1= merge(A, A1, B)。它在合并时不仅会看两人各自的文件内容，还会看之前的原件。通过和原来版本的对比，就可以清楚地知道应该保留谁。

例如：A中（a.txt）文件的第一行内容：（my name is a）

          A1中（a.txt）文件的第一行内容：（my name is a）

          B中（a.txt）文件的第一行内容：（my name is b）

    使用Two-Way Merge方式的合并，工具就需要我们自己确定保留谁。使用Recusive Three-Way Merge,会找到A1和B的最近的根节点A，因为A和A1中并没有修改第一行的内容，但是B修改了第一行的内容，这时工具就能确定我们需要保留B中的第一行，合并后的节点第一行的内容就是：（my name is b），对于这种情况，就无须我们手工确认。 

3.5.3、git merge-冲突处理

    前面我们的合并，都是没有冲突的合并，在项目中，不同的需求可能改到同一个文件，甚至是同一个文件的同一行代码，这时合并时就会产生冲突。

案例描述：新建一个a.txt原始版本提交，修改后a.txt作为主分支的A版本提交，然后创建B分支，再对a.txt文件进行修改提交，然后切回主分支，在主分支中也对a.txt进行修改提交，最后再合并版本。

使用案例：

# 初始化仓库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git init
Initialized empty Git repository in D:/gitRepository/.git/

# 新建a.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ cat a.txt
1111
2222
3333
4444

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git add ./
warning: LF will be replaced by CRLF in a.txt.
The file will have its original line endings in your working directory

# 提交到数据仓库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit a.txt -m "第一次提交原始版本文件"
warning: LF will be replaced by CRLF in a.txt.
The file will have its original line endings in your working directory
[master (root-commit) b4219d7] 第一次提交原始版本文件
 1 file changed, 4 insertions(+)
 create mode 100644 a.txt

# 修改a.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ cat a.txt
1111
2222
3333
4444
5555

# 提交A的第一个版本（公共父节点）
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -a -m "提交A的第一个版本1111-5555"
warning: LF will be replaced by CRLF in a.txt.
The file will have its original line endings in your working directory
[master 2292ec6] 提交A的第一个版本1111-5555
 1 file changed, 1 insertion(+)

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git switch -c b
Switched to a new branch 'b'

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ vim a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ git commit -a -m "提交分支b 对a.txt的修改"
warning: LF will be replaced by CRLF in a.txt.
The file will have its original line endings in your working directory
[b a3fa244] 提交分支b 对a.txt的修改
 1 file changed, 2 insertions(+), 1 deletion(-)

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ cat a.txt
1111
22222222
3333
4444
5555
bbbb

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ git switch master
Switched to branch 'master'

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ cat a.txt
aaaa
1111
2222aaaa
3333
aaaa
4444
5555

# 提交对a.txt的修改
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -a -m "提交主分支对a.txt的修改"
[master fdffea4] 提交主分支对a.txt的修改
 1 file changed, 3 insertions(+), 1 deletion(-)

# 合并时出现冲突，自动合并失败
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git merge -m "合并分支" b
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

# 此时暂存区有三个版本的文件(三方合并)
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ git ls-files -s
100644 acaaa8e6154f09812fb3d5d7b0281a9bdc6f5be4 1       a.txt
100644 d205cd2a67851342ee7fb5e88c385f81f1d8218f 2       a.txt
100644 a407972f81076265f6ec65f3fa90e5c851be8564 3       a.txt

上述过程已经到合并阶段，但是合并出现冲突。需要我们手动编辑文件解决冲突。

# 此时a.txt的文件因为产生冲突，出现如下样子
aaaa
1111
<<<<<<< HEAD
2222aaaa
=======
22222222
>>>>>>> b
3333
aaaa
4444
5555
bbbb

<<<<<<< 表示当前分支冲突开头

>>>>>>> 表示被合并的分支冲突结尾

======= 分隔冲突的不同

我们修改冲突文件，保留我们需要的：

# 编辑冲突文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ vim a.txt

# 最后保留的
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ cat a.txt
aaaa
1111
22222222
3333
aaaa
4444
5555
bbbb

# 将修改加到暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ git add a.txt

# 此时暂存区就一个最终版的文件了
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ git ls-files -s
100644 2348831345a1810c9ce26bdd9996e6b9d6997a72 0       a.txt

# 将合并的文件提交，生成新的节点
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master|MERGING)
$ git commit -m "提交解决冲突的版本"
[master b8ab617] 提交解决冲突的版本

最终效果：

 Git&GitHub就是这么简单_第18张图片

    这就是三方合并。合并后的对象b8ab617对应着两个父提交对象：2292ec6和a3fa244。

--squash参数的使用案例：

    --squash参数会把被合并分支上的所有变更“压缩（squash）”成一个提交，追加到当前分支的后面，作为“合并提交”（merge commit）。从参与合并的文件变更上来说，Squash Merge和普通Merge唯一的区别就是：对于普通的Merge而言，在当前分支上的合并提交通常会有两个parent；而Squash Merge却只有一个。

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git reset --hard fdffea4
HEAD is now at fdffea4 提交主分支对a.txt的修改

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git  merge --squash b
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ vim a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git add a.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git commit -m "修改冲突后提交"
[master 53bebc3] 修改冲突后提交
 1 file changed, 2 insertions(+), 1 deletion(-)

 最终效果：

Git&GitHub就是这么简单_第19张图片

3.5.4、git rebase-合并分支

    git rebase(变基)，就是改变一次提交记录的base。可以用来合并分支，也可以用来合并多次提交。rebase 实际上就是取出一系列的提交记录，复制它们，在另外一个地方逐个的接进去。rebase的优势就是可以创造更线性的提交历史。

    git rebase和git merge的区别：

    git merge 保留真实的用户提交记录，且在merge时会生成一个新的提交。（它是一种非破坏性的操作，现有分支不会以任何方式被更改，但是会产生新的节点）

    而git rebase 会改写历史提交记录(提交对象都会发生变化),但是他也可以合并一些提交节点。

注：不要对任何已经提交到公共/远程仓库中的commit进行(git rebase)。

案例描述：

    我们在b分支上快乐的开发着，结果项目经理说已经更新了主分支，并且在我们之后提交了两个已经上线的版本了，这意味着我们的代码a.txt已经不是最新的啦。

    1）如果前面合并了的话，可以使用git reset --hard fdffea4 重置我们的分支，到如下状态：

Git&GitHub就是这么简单_第20张图片

    2）在主分支上再新增一个文件c.txt（cccc三行）

    3）再切换到b分支，新建一个b.txt（bbb三行）

    4）最终形成如下效果（master分支：a.txt、c.txt；b分支：a.txt和b.txt）

Git&GitHub就是这么简单_第21张图片 Git&GitHub就是这么简单_第22张图片

     项目经理说，有两个紧急需求已经上线了，叫改到a/c文件的同事需要注意一下。于是我们要合并一下代码再测试一下，已经上线的功能加进来是否功能依然正常。于是我们的基版代码则最好是以(8d20dde)新的基点，操作如下：

# 当前b分支 只有a.txt b.txt
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ ls
a.txt  b.txt

# 在b分支上执行git rebase master合并（调基，把master当前基点之后的内容全补丁进来），但是发生冲突
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ git rebase master
error: could not apply a3fa244... 提交分支b 对a.txt的修改
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply a3fa244... 提交分支b 对a.txt的修改
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt

# 解决一下冲突
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b|REBASE 1/2)
$ vim a.txt

# 再将合并好的没有冲突的代码加入暂存区
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b|REBASE 1/2)
$ git add a.txt

# git rebase --continue   git会继续应用余下的补丁，并且完成了
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b|REBASE 1/2)
$ git rebase --continue
[detached HEAD b01c4ff] 提交分支b 对a.txt的修改
 1 file changed, 2 insertions(+), 1 deletion(-)
Successfully rebased and updated refs/heads/b.

 就形成了如下效果： Git&GitHub就是这么简单_第23张图片

 图示效果：Git&GitHub就是这么简单_第24张图片

详细解析： git rebase master，会将会将本地当前分支里的每个提交(commit)取消掉，然后把将本地当前分支更新为master最新的提交（8d20dde）作为基点，然后逐个的复制b分支中的节点到8d20dde（相当于为各个原提交做了个副本，它们拥有相同的修改集、同一个作者、日期以及注释信息），但是b分支中的原提交对象都发生了变化（如：原b.txt的提交对象16a888b,变基后A920a12）。变基后的形式就会到了，最初的git merge-Fast-forward的形式。于是：

# 切换到master分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (b)
$ git switch master
Switched to branch 'master'

# git merge合并分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git merge b
Updating 8d20dde..a920a12
Fast-forward
 a.txt | 3 ++-
 b.txt | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 b.txt

 最终效果：Git&GitHub就是这么简单_第25张图片

    另外有几个参数可以了解一下：

    git rebase --abort ：取消当前变基操作

    git rebase --onto ：可以将一个分支移植到另外一个分支；

    git rebase --interactive （缩写-i）：变基操作会进入交互状态

Git&GitHub就是这么简单_第26张图片

  • pick 默认命令，就是使用该commit，将其复制过去，正常变基
  • reword 使用该提交，但是可以修改该提交的提交信息
  • edit 使用该提交，并且变基中断，如果你想修改变基中的提交的话
  • squash 合并提交，并且编辑合并之后的提交信息
  • fixup 也是合并提交，但是会丢弃提交信息
  • drop 丢弃该提交，也就是该提交不会复制过去
  • exec 执行shell命令

例如：

    我对第一个提交使用reword，当我执行变基时，弹出交互式，让我修改提交信息。

Git&GitHub就是这么简单_第27张图片

3.5.5、git rebase-合并提交

    git rebase 另一个作用就是合并提交，常常一个功能的开发，修修补补 commit 了 n 多次，如果像我这样的强迫症，干不掉它，看着也会很烦。这里的合并，其实可以把它理解成是 "重新设置基线" ，为你的当前分支重新设置开始点。

    git rebase -i HEAD~n，git rebase –i ，这里的 "-i" 是指交互模式，HEAD~2当前分支最近n次提交。就是说你可以干预rebase这个事务的过程。

# 删除之前合并的b分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git branch -d b
Deleted branch b (was 134bda7).

# 查看当前的提交历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git log --oneline --graph --all
* 134bda7 (HEAD -> master) 提交b.txt文件
* 1c03b47 提交分支b 对a.txt的修改
* 8d20dde 提交c.txt文件
* fdffea4 提交主分支对a.txt的修改
* 2292ec6 提交A的第一个版本1111-5555
* b4219d7 第一次提交原始版本文件

使用案例：准备好了上述操作之后，我们以fdffea4提交对象为基点，合并掉8d20dde、134bda7和1c03b47提交对象。

执行命令：git rebase -i HEAD~3

弹窗：我们不能修改最近的一次pick，因为我们要合并成一个提交
  

保存后，我们把我们最终合并的第一条注释修改掉，因为在下文中我们也可以看到此次的操作就是，新增b.txt和c.txt，并且修改a.txt,保存后，即执行成功。

Git&GitHub就是这么简单_第28张图片

 查看合并后的情况：

3.5.6、git rebase-合并提交

    使用 cherry-pick，可以从其他分支复制指定的提交，然后导入到现在的分支。

案例描述：在如下情况下，新建一个分支dev,然后新建d.txt文件，提交的数据仓库。发现我们忘记切换分支了，为此我们需要把在dev分支上新建的内容，复制到master分支上，这时我们可以使用git cherry-pick命令。

 使用案例：

# 新建分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git switch -c dev
Switched to a new branch 'dev'

# 新建文件
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (dev)
$ echo "b.txt v1" > d.txt

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (dev)
$ git add d.txt
warning: LF will be replaced by CRLF in d.txt.
The file will have its original line endings in your working directory

# 提交到仓库
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (dev)
$ git commit -m "提交d.txt"
[dev 53e5c0f] 提交d.txt
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

# 此时git仓库的提交历史
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (dev)
$ git log --oneline --graph --all
* 53e5c0f (HEAD -> dev) 提交d.txt
* 1aef9c6 (master) 提交b.txt c.txt文件 并且修改a.txt
* fdffea4 提交主分支对a.txt的修改
* 2292ec6 提交A的第一个版本1111-5555
* b4219d7 第一次提交原始版本文件

Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (dev)
$ git switch master
Switched to branch 'master'

# 在master分支上，将制定的提交对象复制到当前分支
Administrator@EA424S6AH1D5MQG MINGW64 /d/gitRepository (master)
$ git cherry-pick 53e5c0f
[master c18cba9] 提交d.txt
 Date: Fri Jul 30 22:41:47 2021 +0800
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

最终效果： Git&GitHub就是这么简单_第29张图片

3.6、撤销和重置

    前面我们了解到在git本地仓库中有三大区：工作区、暂存区、本地仓库。当我们有操作失误时，想要撤销相应区域的操作，我们可以这么做呢？

3.6.1、git revert-撤销提交（不会改变过去的历史）

Git&GitHub就是这么简单_第30张图片

使用案例：我们创建revert.txt(revert v1)版本进行第一次提交，修改revert.txt，新增一行revert v2在提交形成如下效果后，再还原到第一个版本。

 Git&GitHub就是这么简单_第31张图片

3.6.2、git reset-重置提交

    git reset用于重置我们的提交，安装不同的命令选项，会对工作区、暂存区有不同的影响。git revert还原版本，会在当前版本上重新生成一个提交节点，而git reset会丢弃之前的提交历史，重置我们的HEAD。

Git&GitHub就是这么简单_第32张图片

使用案例：接着上面的案例，我们在开发中，结果不小心提交了一个测试文件a.txt，我们只使用，并不希望将它提交到仓库，使用重置命令，将主节点重置到之前的节点。

 案例分析：提交a.txt 后，我们将其还原，并保留暂存区和工作区中的a.txt使用--soft 选项。如果不想保留的话暂存区的话：默认会是--mixed,如果都不想保留的话，则使用--hard 选项。

Git&GitHub就是这么简单_第33张图片

3.6.3、git-restore-撤销仓库的提交

Git&GitHub就是这么简单_第34张图片

使用案例：1）将之前的案例还原一下，修改a.txt，再还原工作区的修改

 Git&GitHub就是这么简单_第35张图片

 2）新建一个b.txt，使用 git restore --staged，将未在仓库，但是在暂存区的文件撤出暂存区

Git&GitHub就是这么简单_第36张图片

3.6.4、其他撤销命令

Git&GitHub就是这么简单_第37张图片

 1）git rm --cached file的使用

Git&GitHub就是这么简单_第38张图片

 2）git checkout -- 的使用

    将文件从暂存区（有的话，没有的话找版本库）中检出。案例还原工作区revert.txt。

Git&GitHub就是这么简单_第39张图片

3）git commit --amend 替换上一次提交（一般用于修改提交备注）

使用案例：我们提交b.txt删除a.txt，但是发现提交备注少写了，使用git commit --amend覆盖最近一次的提交。

Git&GitHub就是这么简单_第40张图片

3.7、tag-标签

3.7.1、标签简介

    在Git 中，标签与分支类似，都是指向某一个commit 提交的引用或指针。不同的是，分支可以移动，而标签不能移动。git有commit 为什么还要引入tag标签？

    其实这跟我们记百度网址一样，我们记住的是百度的域名（www.baidu.com）,而不是他的IP，DNS会帮我们转换成对应的IP地址。同样commit对象是一串哈希值，太长杂也不好记，于是tag就来了。如果你希望记住某个版本的话，你可以给这个版本取个tag名（你可以认为是commit的别名）。

Git&GitHub就是这么简单_第41张图片

3.7.2、创建标签

1）git tag tagName -m "message" 或者 git tag -a tagName -m "message"

Git&GitHub就是这么简单_第42张图片

Git&GitHub就是这么简单_第43张图片

 详细解析：-a 参数的意思是强制需要加注释附注信息，所以其实git tag tagName -m和git tag -a tagName -m是等效的。

2）git tag tagName

    为当前提交对象创建标签，可以不写附注信息

Git&GitHub就是这么简单_第44张图片

3.7.3、查找标签

1）git tag 默认按字母排序显示标签列表

2）git tag -l 模糊匹配查找标签

Git&GitHub就是这么简单_第45张图片

3.7.4、删除标签

1)git tag -d tagName

Git&GitHub就是这么简单_第46张图片

4、git 其他命令

    在git中还有一些细节，我们需要了解一下。

4.1、git fsck

    验证数据库中对象的连通性和有效性。

    案例描述：1）初始化仓库；2）新建一个test.txt(内容：test v1)，并且add到暂存区；2)修改test.txt，并且add到暂存区；3）再次修改test.txt，并ad到暂存区，并且查看暂存区的test.txt的blob对象为：4827c00c91ead263ef2b7cab9d5c6405828e7444

Git&GitHub就是这么简单_第47张图片

4）将test.txt提交到仓库；

5）查看仓库中的文件，一次提交有一个blob对象、一个tree对象和一个commit对象；剩下两个就是我们前两次add多出来的垃圾对象。

Git&GitHub就是这么简单_第48张图片

6）使用git fsck 查看

4.2、git prune

    从对象数据库中删除所有不可达的对象。

   git prune 有两个选项，-n (不要删除任何东西; 只是报告它会删除什么);-v(报告所有移除的对象)

Git&GitHub就是这么简单_第49张图片

4.3、git repack

    在仓库中打包/解包的对象。

使用案例：

1）先添加一些内容，并把他们提交到仓库。并添加一个标签。

Git&GitHub就是这么简单_第50张图片

2）执行 git repack -d -l

    将所有未被包含在一个pack的松散对象连结成一个pack，如果有某些现有包冗余，则移除冗余包。

Git&GitHub就是这么简单_第51张图片

3）我们发现打包之后，.git/objects目录下的文件只剩下info目录和pack目录了，那些blob对象、tree对象和commit对象都没有了。

 4）使用git verify-pack -v命令查看压缩后的文件内容，发现之前的之前的一些对象都保存在这个文件里面了。并且大小从之前的12M变成了7.7M

Git&GitHub就是这么简单_第52张图片

5）解压缩 git unpack-objects < ***.pack

    使用一个标准输入去解压一个压缩文件，第一次为什么没有成功呢？因为pack文件存储的压缩对象本身就存在objects目录下，为此要解压一个文件，我们需要把他移出当前目录，在进行解压。

Git&GitHub就是这么简单_第53张图片

4.4、git reflog 

    管理reflog信息。当想恢复到之前的新版本，有没有设置标签，也不记得之前的commit对象怎么办？那么你可以使用git reflog，它记录了你的每一次命令。

    注：git log可以查看提交历史

           git reflog查看命令历史

Git&GitHub就是这么简单_第54张图片

4.5、git gc

    清理不必要的文件并优化本地存储库。

    git的底层并没有采用如CVS、SVN 底层所采用的那套增量式文件系统，当文件发生变化时，提交上去的是不是差异信息，而是文件的快照，即整个文件的内容，并保存指向快照的索引。这种做法，提高 Git 分支的使用效率；但也容易导致仓库中内容重复程度过高，从而仓库体积过大。遇到这种情况时，就需要Git中的gc（garbage collect）功能。

    Git会收集所有松散对象并将它们存入 packfile，合并这些 packfile 进一个大的 packfile，然后将不被任何 commit 引用并且已存在一段时间 (数月) 的对象删除。 此外，Git还会将所有引用 (references) 并入一个单独文件。

    其指向过程如下：

  • pack_refs 过程（当于执行"git pack-refs --all --prune"，打包分支和标签以便高效的存储库访问）
  • reflog expire 过程（相当于执行"git reflog expire --all"，删除所有超过期限而且没有被refs涉及的reflog条目）
  • repack 过程（相当于执行"git repack -d -l"，将所有未被包含在一个pack的松散对象连结成一个pack，也会将现有的pack重新组织为一个新的更有效率的pack，并删除冗余的pack）
  • prune 过程（相当于执行"git prune --expire"，删除所有过期的、不可达的且未被打包的松散对象。）
  • rerere 过程（相当于执"git rerere gc"如果启用的话，会修剪很久以前发生的冲突合并的记录。）

使用案例：查看.git/objects/目录下的文件，在使用git gc 命令，它不仅会帮我们把objets命令下文件打包，refs目录下的文件也会一起打包。

Git&GitHub就是这么简单_第55张图片

5、本地仓库与远程仓库

    前面我们学习的都是在本地操作一个git的版本库。接下来我们了解一下远程仓库GitHub的使用。

Git&GitHub就是这么简单_第56张图片

    前面我们也介绍过了Git和GitHub的历史渊源，Git 是一款免费、开源的分布式版本控制系统，而 GitHub主要提供基于 git 的版本托管服务。如今，GitHub已经成为了全球最大的开源社区了，很多全球的顶级科技公司纷纷加入 GitHub，许多顶级开源项目都优先选择在 GitHub 上开源，如：Linux、Nodejs、Ruby等，Vue也曾在GitHub上被大家发现。在GitHub上不仅学习优秀的开源项目，也可以多人协作开发项目，搭建博客和个人网站等。

    但当我想学习如何使用GitHub时，发现很多的文章，居然无从下手。使用远程仓库的作用：备份和实现代码共享集中化管理。

5.1、注册及简介

5.1.1、注册GitHub账号

    首先去GitHub官网注册一个属于你的账号，这里就不详细的描述注册的过程了，准备一个可以使用的邮箱账号就行。

    注册好账号后：我们的Github主页就是这个样子的。下面会对主页一些内容进行简单的介绍。

Git&GitHub就是这么简单_第57张图片

5.1.2、页面内容简介

1）相关概念：

     拉取请求（Pull Request）：给项目提出请求（包括自己的提交情况，或者别人提交给你的请求）。例如你发现一个项目很有意思，于是你把项目fork过来，然后你发现项目中有些bug，你修改了之后请求去合并你的修改，就是你给别人提交你的请求，如果被审核通过并正式合并，这样你就为该项目做贡献了。

     问题（Issue）：评论/话题，对项目提出各种讨论，可以增加开发者和使用者的交流。（你给别人提的问题或者别人给你提的问题,比如 Bug、Build、help、wanted等，有各种问题都可以提）。比如，你开源了一个仓库，别人看见了，或者你的团队朋友看见了，发现一个bug！就点击Issues，新建一个Issues，告诉你问题，然后设置一个标签，标明是bug还是warning还是文档写错啦。

Git&GitHub就是这么简单_第58张图片  

     市场（Marketplace）：里面有一些工具，比如持续集成，代码检视等，商用的话大部分需要花钱。

     探索（Explore）：Explore下面有很多东西。Explore下面的explore一栏里面github会给我推荐一些项目，topics是比较热门的项目，github也给我们进行了归类，treading中是一些热度上升较快的项目，collections对项目进行了归类，类似topics，但是不热门的项目你在这边也可以找到，events是一些GitHub的新闻，GitHub Sponsors是一些赞助商和代码爱好者介绍。

2）更多功能（加号里的内容）：

Git&GitHub就是这么简单_第59张图片

     新建仓库（New repository）：一个github账号可以创建多个仓库（repository），可以保存多个代码工程和项目的代码，资源，文本、图片......等。（官方定义：仓库就像项目的文件夹。 项目的仓库包含项目的所有文件，并存储每个文件的修订记录。 您也可以在仓库中讨论并管理项目的工作。您可以个人拥有仓库，也可以与组织中的其他人共享仓库的所有权。）

     导入仓库（Import repository）：导入一个已经存在的仓库。

     新建要点（New gist）：用于共享代码段，注释，任务列表等（单个文件）。

     新建组织（New organization）：一个github账号可以创建多个组织（organization），一个组织可以创建多个仓库（repository），一个仓库（repository）也可以对应多个组织（organization）；组织（organization）还可以创建团队（Team）创建团队的当前账号，在Team内的role是Maintainer，还可以邀请别的人进入这个team，默认将Role设置为Member。

     新建项目板（New project）：Github Projects 就是一个个看板，可以把 Issues 加入看板中，方便管理它们的进程。项目板也可用于创建满足您需求的自定义工作流程，例如对特定功能工作、全面路线图甚至发布检查清单进行跟踪和排列优先级。

3） 个人设置

Git&GitHub就是这么简单_第60张图片

    注：这里的个人资料，也就是我们的个人主页 

5.2、Github创建仓库

    我们可以在GitHub 仓库中存储各种项目，下面我们就来介绍一下如何在GitHub中创建一个仓库。

5.2.1、创建仓库前序

    首先我们点击页面的右上角更多功能（+下拉菜单中）选择New repository（新建仓库）。就会进入到如下界面：

Git&GitHub就是这么简单_第61张图片

5.2.2、创建仓库

Git&GitHub就是这么简单_第62张图片

    第一步：右上角，使用  下拉菜单选择 New repository（新建仓库）

    第二步：为仓库取个简短的名字。"hello-world"

    第三步：（可选）添加仓库的说明。

    第四步：选择仓库可见性。

    第五步：选择初始化仓库需要一并创建的内容（使用自述文件初始化此仓库）。此时会出现：This will set  main as the default branch. Change the default name in your settings.意思是默认的主分支叫main，当然我们可以重设主分支名字。

    第六步：点击创建（Create repository）。

5.2.3、创建仓库后序

    创建仓库后，会进入到我们的仓库主页，界面如下：

Git&GitHub就是这么简单_第63张图片

    在仓库主页，我们看到很多的内容，下面就对其中一些内容做简单的介绍：

1）Watch、Star、Fork

    关注（Watch）：代表有多少人关注了该项目，当项目更新时，关注的人会收到邮件通知。

    收藏（Star）：代表有多少人收藏了该项目，方便他们参考代码。

    分叉/克隆（Fork）：Fork字面意思“叉”，就是把整个项目源代码，复制到自己的代码仓中。复分叉的越多，也说明代码的价值被认可度越高。

注：关注数、收藏数、分叉数，代表了大家对该项目的热度和项目认可度。

2）仓库文件列表（Code）

    main、branch、tags：项目的分支和标签信息

    go to file:跳转到文件搜索页面

    add File:添加或上传文件

    code:下载或克隆项目

    about:可以修改项目描述信息

    Releases：可以创建一个发行版来打包软件，以及发行说明和二进制文件链接，供其他人使用。类似于一些项目提供多个版本下载及长期更新升级服务。

    Packages：GitHub Packages 是一种包托管服务，与 GitHub 完全集成。 GitHub Packages 将您的源代码和软件包组合在一起，以提供集成的权限管理和计费，使您能够在 GitHub 上专注于软件开发。（例如 npm、RubyGems、Apache Maven、Gradle、Docker 和 Nuget）

3）持续集成服务（Actions）

    GItHub 推出的一个 CI\CD 服务，即持续集成服务，有 GItHub Action 以后，能做的事情就更多，比如在 master 分支上提交了一段代码， GitHub Action 可以自动部署到指定的服务器上去，还可以把代码做成镜像，将镜像自动提交到镜像仓库里。

4）维基（Wiki）

    可以将仓库文档托管在 wiki 中，以便其他人使用和参与您的项目。一般为：

  • 整体介绍
  • 如何在 linux/mac/win 环境中安装/使用/调试 的手册
  • FAQ
  • 许可证说明
  • 如何加入社区贡献渠道等等

5）安全（Security）

    GitHub 允许客户在 Advanced Security 许可下使用额外的安全功能。

6）洞察统计（Insights）

    包括项目的总体浏览相关统计信息，例如：看用户在相应日期发送提交、添加代码、删除代码的大致数量，服务端的代码仓库克隆情况等信息。

7）设置（Settings）

    对仓库进行任何设置。如：

  • 修改仓库名称、删除仓库。
  • Features：更改 Wiki 和 Issuse 的相关设置。如果想关闭某些功能，只要勾选相应的复选框即可。
  • Merge Button：设置合并代码方式。
  • GitHub Pages：每个 Github 账户都可以开一个自己的静态网站等等。

5.3、管理仓库

5.3.1、添加文件

    我们使用网页版，去操作Github的仓库，添加文件有两种方式，一是：Create new File,二是：Upload files。

    添加文件方式一：Create new File-新建文件

Git&GitHub就是这么简单_第64张图片

    添加文件方式二：Upload files-上传文件

Git&GitHub就是这么简单_第65张图片

    当然我们也可以添加目录及文件：

Git&GitHub就是这么简单_第66张图片

5.3.2、修改文件

    在code文件列表中点击文件名，即可进入文件详情页面，修改文件内容。

Git&GitHub就是这么简单_第67张图片

查看提交信息：

Git&GitHub就是这么简单_第68张图片 点击提交简述可以进入提交详情页面，查看提交信息。 

5.3.3、删除文件

Git&GitHub就是这么简单_第69张图片

5.3.4、查找文件

    点击Go to file，即可进入搜索页面

Git&GitHub就是这么简单_第70张图片

5.4、其他常用操作

5.4.1、收藏加关注

Git&GitHub就是这么简单_第71张图片

然后可以在Your stars查看你的所有收藏：

Git&GitHub就是这么简单_第72张图片5.4.2、Fork及Pull requests的使用

    使用案例：我们用另外一个账号，创建了一个hello-world-hls仓库，信息如下：

Git&GitHub就是这么简单_第73张图片

第一步：搜索hello-world-hls这个仓库，并Fork这个仓库，当前仓库Fork了hello-world-hls仓库后会自己生成一个一模一样的仓库，然后我们对项目中的文件进行修改，并提交。

Git&GitHub就是这么简单_第74张图片

 提交后：

Git&GitHub就是这么简单_第75张图片

 第二步：我修改hello-world-hls这个仓库的文件，希望能更新到这个仓库，这时候就需要使用Pull requests了。

Git&GitHub就是这么简单_第76张图片

第三步：我们在hlsol/hello-world-hls仓库中看到：

Git&GitHub就是这么简单_第77张图片

第四步：查看修改并接收合并

Git&GitHub就是这么简单_第78张图片

第五步：查看项目，已经和mjxol/hello-world-hls项目同步了

Git&GitHub就是这么简单_第79张图片

5.4.3、下载源码

    即使我们没有注册github账号，我们也可以下载源码，然后查看源码。点击Download ZIP。

5.5、使用GitHub Desktop管理远程仓库 

5.5.1、GitHub Desktop登录

    GitHub为我们提供了一个管理远程仓库的应用程序，可以在https://desktop.github.com/下载。下载完成后登录：

Git&GitHub就是这么简单_第80张图片

 登录之后，主页如下：

Git&GitHub就是这么简单_第81张图片

5.5.2、创建及使用本地仓库

第一步：点击Create a New Repository,创建一个本地仓库。

Git&GitHub就是这么简单_第82张图片

 第二步：在本地仓库中新增两个文件abc.txt和gitDemo.txtGit&GitHub就是这么简单_第83张图片

 第三步：将新增的两个文件提交到本地仓库。

Git&GitHub就是这么简单_第84张图片

第四步：修改abc.txt，并提交到本地仓库。 

Git&GitHub就是这么简单_第85张图片

第五步：取消默认勾选的私有选项,点击Publish repository上传到远程仓库。(等待发布成功，过程可能会有点慢）

Git&GitHub就是这么简单_第86张图片

5.5.3、提交改变到远程仓库-push origin

第一步：本地新增一个文件def.txt，并提交到本地仓库。现在显示本地没有改变，但是上面push origin显示了1，代表的是我们与远程的github不同步，本地有一个更新。

 第二步：将更新推送到远程仓库push origin。

Git&GitHub就是这么简单_第87张图片

5.5.4、更新本地仓库-Pull origin

 第一步：我在github网页上直接添加一个other.txt并提交，这时我们的本地仓库和远程仓库就不同步了。Git&GitHub就是这么简单_第88张图片

第二步：我们点击Fetch origin,出现Pull origin有个下载1，说明我们和远程仓库不同步了。点击Pull origin，就可以把远程的difficult更新到本地了。

Git&GitHub就是这么简单_第89张图片

5.5.5、版本回退

    假如我不小心把本地的def.txt文件误删了，并且还同步到远程仓库了。我们可以右击提交记录选择Revert到提交前的版本。

Git&GitHub就是这么简单_第90张图片

 然后再点击Push origin将被误删的def.txt再次提交到远程仓库

5.5.6、合并分支

第一步：创建一个dev分支，并添加cc.txt文件

Git&GitHub就是这么简单_第91张图片

切换到主分支（main），记住永远都是把其他分支merge到当前。

Git&GitHub就是这么简单_第92张图片

 这时主分支上就多了一个commit，就是我们从dev分支合并过来的 

Git&GitHub就是这么简单_第93张图片

5.5.7、将github上的项目克隆到本地仓库

第一步：在github远程仓库中，点击Open with Github Desktop

Git&GitHub就是这么简单_第94张图片

 第二步：在Github Desktop上显示如下，我们直接点击Clone

Git&GitHub就是这么简单_第95张图片

最后我们可以看到克隆成功：

Git&GitHub就是这么简单_第96张图片

5.6、使用Git管理远程仓库

5.6.1、下载源码

1）使用https方式下载    

    在非登陆的情况下我们同样也可以使用命令下载源码到本地。

第一步：复制链接https://github.com/vuejs/vue.git（源码网址后多了个.git）

Git&GitHub就是这么简单_第97张图片

 第二步：在git命令行工具中输入： git clone https://github.com/vuejs/vue.git

Git&GitHub就是这么简单_第98张图片

 第四步：如果出现这种情况，别慌，一般是这是因为服务器的SSL证书没有经过第三方机构的签署，所以才报错。

 第五步：输入： git config --global http.sslVerify "false"，即可。

Git&GitHub就是这么简单_第99张图片

 1）使用SSH方式下载

    SSH方式下载传输效率更高。不过这种方式下载需要注册。使用SSH的原理就是密钥登陆（也就是所谓的免密登陆）

    如果希望了解SSH密钥登陆，可以看我的这篇文章：   https://blog.csdn.net/xiaoxianer321/article/details/109625658

第一步：首先我们在客户端，也就是git命令行工具上，执行如下命令，会生成一个私钥和一个公钥：

    ssh-keygen -t rsa -C "github email"

Git&GitHub就是这么简单_第100张图片

第二步：复制公钥，点击Add SSH Key，填写密码验证。

Git&GitHub就是这么简单_第101张图片

第三步：验证是否配置成功 ssh -T -v [email protected]，已经认证成功。

 第四步：复制链接[email protected]:vuejs/vue.gitGit&GitHub就是这么简单_第102张图片 第五步：克隆仓库 git clone [email protected]:vuejs/vue.git

 Git&GitHub就是这么简单_第103张图片

5.6.2、添加远程仓库

    使用命令：git remote add

    注：shortname 为url的别名，如使用：origin，添加新的可以使用其他名字

Git&GitHub就是这么简单_第104张图片

5.6.3、查看远程仓库信息

    使用命令：git remote -v  查看远程仓库信息(显示的是需要读写远程仓库使用的 Git 保存的简写与其对应的 URL)

    git remote show  查看指定远程查看信息

 Git&GitHub就是这么简单_第105张图片

 详细解析：

    命令展示的内容：远程仓库

    Fetch 对应的URL：[email protected]:mjxol/hello-world.git

    Push 对应的URL：[email protected]:mjxol/hello-world.git

    HEAD 指向分支：main

    远程分支：main 分支追踪状态

    为“git pull”配置的本地分支：main与远程main合并

    为“git推送”配置的本地引用：本地main推送远程main（最新）

5.6.4、远程仓库的重命名与移除

    使用命令：git remote remove 移除远程仓库绑定信息

    git remote rename  修改远程仓库的简称

 Git&GitHub就是这么简单_第106张图片

    前面呢我们已经会使用git命令去克隆/关联一个远程仓库。接下来我们将会接触到几个新的命令，git fetch 从远程仓库抓取、git push 推送至远程仓库、git pull 拉取（自动抓取后合并该远程分支到当前分支），可以说：git pull = git fetch + git merge FETCH_HEAD（可能会产生冲突，需要手动解决） ，用一张图来表示就是：

5.6.5、从远程仓库抓取-git fetch

       git fetch 抓取远程仓库中的内容到本地仓库。会抓取克隆（或上一次抓取）后新推送的所有工作。

    注：git fetch 命令只会将数据下载到你的本地仓库——它并不会自动合并或修改你当前的工作。如果需要指定分支，使用：git fetch  

    那他是怎么工作的呢？删除之前的仓库，我们重新开始操作一个案例：

第一步：克隆仓库到本地，此时本地和远程仓库是一致的。

Git&GitHub就是这么简单_第107张图片

    前面我们也讲过，克隆项目其实下载下来的是一个压缩包。 查看本地仓库main主分支的最新对象（cat .git/refs/heads/main），并查看下载下来的项目的最新的提交对象（cat .git/packed-refs）

Git&GitHub就是这么简单_第108张图片

 第二步：在远程仓库上新增一个文件，并且远程仓库最新的提交对象已经是9b76bef了 

Git&GitHub就是这么简单_第109张图片

第三步：使用git fetch命令会抓取全部更新到本地仓库（全部更新：本地克隆（或上一次抓取）后新推送的所有工作）

Git&GitHub就是这么简单_第110张图片

我们可以看到：最后一行显示，最新的对象已从 4f208f4到9b76bef了。

第四步：使用git log -p FETCH_HEAD命令查看刚取回的更新信息

Git&GitHub就是这么简单_第111张图片

 同样我们可以在本地仓库的文件中找到依据：

Git&GitHub就是这么简单_第112张图片

    详细解析：

    本地仓库中的main分支最新的commit对象还是没有变，而本地仓库中记录的远程仓库中的commit对象已经更新。即origin/main分支中的内容已经更新，我们需要把远程下载下来的代码合并到本地仓库。

第五步：合并远程下载到本地仓库，git merge origin [branchName]命令，本地工作目录

Git&GitHub就是这么简单_第113张图片

 Git&GitHub就是这么简单_第114张图片

5.6.6、拉取-git pull

案例：我们在下面这样一个远程仓库中，包含一个dev分支、一个main分支。

Git&GitHub就是这么简单_第115张图片

且当前工作目录与远程仓库一致：

Git&GitHub就是这么简单_第116张图片  

 第一步：在远程仓库dev，分支中新增一个文件。

Git&GitHub就是这么简单_第117张图片

第二步： 在main分支上执行git pull

 Git&GitHub就是这么简单_第118张图片

Git&GitHub就是这么简单_第119张图片

    详细解析：在main分支上执行git pull,查看日志，虽然发现dev分支的第二次提交已经更新到本次数据库了。却没有帮我们合并，不是说git pull=git fetch + git merge？，这是什么情况？

第三步：我们查看本地仓库的.git/FETCH_HEAD文件

     详细解析：

    FETCH_HEAD指的是: 某个branch在服务器上的最新状态。每一个执行过fetch操作的项目都会存在一个FETCH_HEAD列表，其中每一行对应于远程服务器的一个分支。当前分支指向的FETCH_HEAD, 就是这个文件第一行对应的那个分支。其状态，若都是 not-for-merge 则不会有接下来的merge动作，这也是为什么没有在main分支下，执行git pull下来的dev分支不会被自动合并。在当前分支执行git fetch之后，FETCH_HEAD则会更新对应分支的状态。

第四步：切换到dev分支，再执行一次git pull -v (-v参数是打印出详细信息)

Git&GitHub就是这么简单_第120张图片

    我们看到执行了一次merge(Fast-Forward)

5.6.7、推送至远程仓库-git push

 第一步：新增一个文件，并提交到本地仓库

Git&GitHub就是这么简单_第121张图片

 第二步：执行git push

这样，就推送到了我们的远程仓库。

Git&GitHub就是这么简单_第122张图片

5.7、思维导图

    最后附上一张总结的思维导图：

Git&GitHub就是这么简单_第123张图片

     希望在后续学习中对Git及GitHub有更深一步的了解。下一篇文章，将会继续讲解如何在GitHub上搭建一个个人博客。

你可能感兴趣的:(版本管理,原创未经允许不得转载,git,github)

  • 如何在 Fork 的 GitHub 项目中保留自己的修改并同步上游更新？github_fork_update iBaoxing github
    如何在Fork的GitHub项目中保留自己的修改并同步上游更新？在GitHub上Fork了一个项目后，你可能会对项目进行一些修改，同时原作者也在不断更新。如果想要在保留自己修改的基础上，同步原作者的最新更新，很多人会不知所措。本文将详细讲解如何在不丢失自己改动的情况下，将上游仓库的更新合并到自己的仓库中。问题描述假设你在GitHub上Fork了一个项目，并基于该项目做了一些修改，随后你发现原作者对
  • 绘本讲师训练营【24期】8/21阅读原创《独生小孩》 1784e22615e0
    24016-孟娟《独生小孩》图片发自App今天我想分享一个蛮特别的绘本，讲的是一个特殊的群体，我也是属于这个群体，80后的独生小孩。这是一本中国绘本，作者郭婧，也是一个80厚。全书一百多页，均为铅笔绘制，虽然为黑白色调，但并不显得沉闷。全书没有文字，犹如“默片”，但并不影响读者对该作品的理解，反而显得神秘，梦幻，給读者留下想象的空间。作者在前蝴蝶页这样写到：“我更希望父母和孩子一起分享这本书，使他
  • git常用命令笔记 咩酱-小羊 git笔记
    ###用习惯了idea总是不记得git的一些常见命令，需要用到的时候总是担心旁边站了人~~~记个笔记@_@，告诉自己看笔记不丢人初始化初始化一个新的Git仓库gitinit配置配置用户信息gitconfig--globaluser.name"YourName"gitconfig--globaluser.email"[email protected]"基本操作克隆远程仓库gitclone查看
  • Goolge earth studio 进阶4——路径修改与平滑 陟彼高冈yu Googleearthstudio进阶教程旅游
    如果我们希望在大约中途时获得更多的城市鸟瞰视角。可以将相机拖动到这里并创建一个新的关键帧。camera_target_clip_7EarthStudio会自动平滑我们的路径，所以当我们通过这个关键帧时，不是一个生硬的角度，而是一个平滑的曲线。camera_target_clip_8路径上有贝塞尔控制手柄，允许我们调整路径的形状。右键单击，我们可以选择“平滑路径”，这是默认的自动平滑算法，或者我们可
  • 下载github patch到本地 小米人er 我的博客gitpatch
    以下是几种从GitHub上下载以.patch结尾的补丁文件的方法：通过浏览器直接下载打开包含该.patch文件的GitHub仓库。在仓库的文件列表中找到对应的.patch文件。点击该文件，浏览器会显示文件的内容，在页面的右上角通常会有一个“Raw”按钮，点击它可以获取原始文件内容。然后在浏览器中使用快捷键（如Ctrl+S或者Command+S）将原始文件保存到本地，选择保存的文件名并确保后缀为.p
  • 509. 斐波那契数(每日一题) lzyprime
    lzyprime博客(github)创建时间：2021.01.04qq及邮箱：2383518170leetcode笔记题目描述斐波那契数，通常用F(n)表示，形成的序列称为斐波那契数列。该数列由0和1开始，后面的每一项数字都是前面两项数字的和。也就是：F(0)=0，F(1)=1F(n)=F(n-1)+F(n-2)，其中n>1给你n，请计算F(n)。示例1：输入：2输出：1解释：F(2)=F(1)+
  • Git常用命令－修改远程仓库地址 猿大师 LinuxJavagitjava
    查看远程仓库地址gitremote-v返回结果originhttps://git.coding.net/＊＊＊＊＊.git(fetch)originhttps://git.coding.net/＊＊＊＊＊.git(push)修改远程仓库地址gitremoteset-urloriginhttps://git.coding.net/＊＊＊＊＊.git先删除后增加远程仓库地址gitremotermori
  • GitHub上克隆项目 bigbig猩猩 github
    从GitHub上克隆项目是一个简单且直接的过程，它允许你将远程仓库中的项目复制到你的本地计算机上，以便进行进一步的开发、测试或学习。以下是一个详细的步骤指南，帮助你从GitHub上克隆项目。一、准备工作1.安装Git在克隆GitHub项目之前，你需要在你的计算机上安装Git工具。Git是一个开源的分布式版本控制系统，用于跟踪和管理代码变更。你可以从Git的官方网站（https://git-scm.
  • 把握“三度”打造“三有”干部队伍 辛德瑞拉卡卡卡
    “胜败兴亡之分，不得不归咎于人事也”。干部队伍建设工作的好坏，关系到党和国家的发展全局。近日，新疆维吾尔自治区党委书记马兴瑞在部分党群单位走访调研时强调，要努力培养造就忠诚干净担当的高素质专业化干部队伍。各级组织部门应当在培养选拔干部、吸收优秀青年到党内来、培养造就优秀人才上下功夫，切实增强干部投身实践、解决问题、推进工作的能力，着力打造高素质专业化干部队伍。“天生我材必有用”，增强选育有“准度”
  • git - Webhook让部署自动化 大猪大猪
    我们现在有一个需求，将项目打包上传到gitlab或者github后，程序能自动部署，不用手动地去服务器中进行项目更新并运行，如何做到？这里我们可以使用gitlab与github的挂钩，挂钩的原理就是，每当我们有请求到gitlab与github服务器时，这时他俩会根据我们配置的挂钩地扯进行访问，webhook挂钩程序会一直监听着某个端口请求，一但收到他们发过来的请求，这时就知道用户有请求提交了，这时
  • 121. 买卖股票的最佳时机 薄荷糖的味道_fb40
    给定一个数组，它的第i个元素是一支给定股票第i天的价格。如果你最多只允许完成一笔交易（即买入和卖出一支股票），设计一个算法来计算你所能获取的最大利润。注意你不能在买入股票前卖出股票。示例1:输入:[7,1,5,3,6,4]输出:5解释:在第2天（股票价格=1）的时候买入，在第5天（股票价格=6）的时候卖出，最大利润=6-1=5。注意利润不能是7-1=6,因为卖出价格需要大于买入价格。示例2:输入:
  • MongoDB Oplog 窗口 喝醉酒的小白 MongoDB运维
    在MongoDB中，oplog（操作日志）是一个特殊的日志系统，用于记录对数据库的所有写操作。oplog允许副本集成员（通常是从节点）应用主节点上已经执行的操作，从而保持数据的一致性。它是MongoDB副本集实现数据复制的基础。MongoDBOplog窗口oplog窗口是指在MongoDB副本集中，从节点可以用来同步数据的时间范围。这个窗口通常由以下因素决定：Oplog大小：oplog的大小是有限
  • libyuv之linux编译 jaronho Linuxlinux运维服务器
    文章目录一、下载源码二、编译源码三、注意事项1、银河麒麟系统（aarch64）（1）解决armv8-a+dotprod+i8mm指令集支持问题（2）解决armv9-a+sve2指令集支持问题一、下载源码到GitHub网站下载https://github.com/lemenkov/libyuv源码，或者用直接用git克隆到本地，如：gitclonehttps://github.com/lemenko
  • Faiss Tips：高效向量搜索与聚类的利器 焦习娜Samantha
    FaissTips：高效向量搜索与聚类的利器faiss_tipsSomeusefultipsforfaiss项目地址:https://gitcode.com/gh_mirrors/fa/faiss_tips项目介绍Faiss是由FacebookAIResearch开发的一个用于高效相似性搜索和密集向量聚类的库。它支持多种硬件平台，包括CPU和GPU，能够在海量数据集上实现快速的近似最近邻搜索（AN
  • pyecharts——绘制柱形图折线图 2224070247 信息可视化pythonjava数据可视化
    一、pyecharts概述自2013年6月百度EFE(ExcellentFrontEnd）数据可视化团队研发的ECharts1.0发布到GitHub网站以来，ECharts一直备受业界权威的关注并获得广泛好评，成为目前成熟且流行的数据可视化图表工具，被应用到诸多数据可视化的开发领域。Python作为数据分析领域最受欢迎的语言，也加入ECharts的使用行列，并研发出方便Python开发者使用的数据
  • node.js学习 小猿L node.jsnode.js学习vim
    node.js学习实操及笔记温故node.js，node.js学习实操过程及笔记~node.js学习视频node.js官网node.js中文网实操笔记githubcsdn笔记为什么学node.js可以让别人访问我们编写的网页为后续的框架学习打下基础，三大框架vuereactangular离不开node.jsnode.js是什么官网：node.js是一个开源的、跨平台的运行JavaScript的运行
  • 2020-12-16 长寿富贵
    9：56不知今天哪位亲来说说话呀？成萌：尽尽皆是道。道道皆相同。不解呀？成萌：郁郁不得志，混混过日子。哦……说谁的呀？成萌：说自己呀……还能说谁呢？那如何办呢？成萌：回头……如何回头？成萌：回见心源。如何回见心源？成萌：不追不随诸相迁，如如不动在心田。啊？成萌：慢慢守心吧。
  • 高级 ECharts 技巧：自定义图表主题与样式 SnowMan1993 echarts信息可视化数据分析
    ECharts是一个强大的数据可视化库，提供了多种内置主题和样式，但你也可以根据项目的设计需求，自定义图表的主题与样式。本文将介绍如何使用ECharts自定义图表主题，以提升数据可视化的吸引力和一致性。1.什么是ECharts主题？ECharts的主题是指定义图表样式的配置项，包括颜色、字体、线条样式等。通过预设主题，你可以快速更改图表的整体风格，而自定义主题则允许你在此基础上进行个性化设置。2.
  • 01-Git初识 Meereen Gitgit
    01-Git初识概念：一个免费开源，分布式的代码版本控制系统，帮助开发团队维护代码作用：记录代码内容。切换代码版本，多人开发时高效合并代码内容如何学：个人本机使用：Git基础命令和概念多人共享使用：团队开发同一个项目的代码版本管理Git配置用户信息配置：用户名和邮箱，应用在每次提交代码版本时表明自己的身份命令：查看git版本号git-v配置用户名gitconfig--globaluser.name
  • 锁之缘 尘缘诗词原创作品
    是谁追寻梦的足迹，是谁在偷偷的哭泣，日月隔离在黑白天地情感在心中蔓延的痕迹天与地的距离有多远流失的星晨落入哪片空间不要让泪水模糊双眼心牢中一样充满温暖谁说爱情没有永远白娘子又为何爱许仙蝴蝶墓地展翅翩翩轻歌慢舞袖卷人间传奇千古留爱万年…………月落星飞徘徊是选择不去问自已为合舍不得寂寞本就是痛苦的不在追寻梦中的痕迹才不会失去真实的自已
  • 【无标题】达瓦达瓦 JhonKI 考研
    博客主页：https://blog.csdn.net/2301_779549673欢迎点赞收藏⭐留言如有错误敬请指正！本文由JohnKi原创，首发于CSDN未来很长，值得我们全力奔赴更美好的生活✨文章目录前言111️‍111❤️111111111111111总结111前言111骗骗流量券，嘿嘿111111111111111111111111111️‍111❤️111111111111111总结11
  • 上图为是否色发 JhonKI 考研
    博客主页：https://blog.csdn.net/2301_779549673欢迎点赞收藏⭐留言如有错误敬请指正！本文由JohnKi原创，首发于CSDN未来很长，值得我们全力奔赴更美好的生活✨文章目录前言111️‍111❤️111111111111111总结111前言111骗骗流量券，嘿嘿111111111111111111111111111️‍111❤️111111111111111总结11
  • 一个历史事件和查理一世走上断头台有很大关系，这个事件是什么？ 王老师聊围棋
    今天我要讲的历史事件，查理一世被处死的始末。其实查理一世给被处死的时候，与一个事件有很大的联系。这个事件是“普莱德清洗”。提到这个事件，我们不得不提到一个人，这个人就是克伦威尔。可以说，查理一世能够走上断头台，克伦威尔有很大的功劳。为什么这么说呢。那我们就成英国内战的终结说起吧。我们都知道英国的内战是有保王党挑起来。在保王党军队一路凯歌进攻的同时。就在1645年6月14日，在纳西比荒原上进行最后的
  • 【Git】常见命令(仅笔记) 好想有猫猫 GitLinux学习笔记git笔记elasticsearchlinuxc++
    文章目录创建/初始化本地仓库添加本地仓库配置项提交文件查看仓库状态回退仓库查看日志分支删除文件暂存工作区代码远程仓库使用`.gitigore`文件让git不追踪一些文件标签创建/初始化本地仓库gitinit添加本地仓库配置项gitconfig-l#以列表形式显示配置项gitconfiguser.name"ljh"#配置user.namegitconfiguser.email"[email protected]
  • 143234234123432 JhonKI 考研
    博客主页：https://blog.csdn.net/2301_779549673欢迎点赞收藏⭐留言如有错误敬请指正！本文由JohnKi原创，首发于CSDN未来很长，值得我们全力奔赴更美好的生活✨文章目录前言111️‍111❤️111111111111111总结111前言111骗骗流量券，嘿嘿111111111111111111111111111️‍111❤️111111111111111总结11
  • 道阻且长，行则将至 sweet橘子
    本文参与书香澜梦主题征文“行”文章原创首发，文责自负。我们每一个人都应该有属于自己的愿望或者是理想，人一但有了理想也就算是有了方向，它就会像灯塔一样指引我们前进的方向，哪怕是再远大的理想，如果坚持，那么我相信它就一定有收获。屈原是我最喜欢的一个浪漫主义的诗人，他曾今说过：“路漫漫其修远兮，吾将上下而求索。”人生的道路很长，但是为了实现自己的理想抱负我愿意付出我毕生的精力，只专注这一件事，因为“道阻
  • 【勾心原创】《去年夏天》 不勾心的豆角
    （原创作者：不勾心的豆角）本期【勾心原创】，继续本人不勾心的豆角的现代诗创作之旅。《去年夏天》原创作者：不勾心的豆角那里芳草茵茵绿柳成行澄净蓝天下屋顶们相亲相爱闪着橙色紫色的馨香溪流温柔偎依着村庄牛儿羊儿信步徜徉还有成群的白鸽在尖顶的教堂盘旋歌唱孩子们是自由的蒲公英奔跑在希望的田野上任由天真的笑声肆无忌惮烂漫这人间天堂夜幕小心翼翼呵护着甜美的梦乡只剩尽职的晚风陪伴顽皮的星子们游荡快告诉我心爱的姑娘
  • ES聚合分析原理与代码实例讲解 光剑书架上的书 大厂Offer收割机面试题简历程序员读书硅基计算碳基计算认知计算生物计算深度学习神经网络大数据AIGCAGILLMJavaPython架构设计Agent程序员实现财富自由
    ES聚合分析原理与代码实例讲解1.背景介绍1.1问题的由来在大规模数据分析场景中，特别是在使用Elasticsearch（ES）进行数据存储和检索时，聚合分析成为了一个至关重要的功能。聚合分析允许用户对数据集进行细分和分组，以便深入探索数据的结构和模式。这在诸如实时监控、日志分析、业务洞察等领域具有广泛的应用。1.2研究现状目前，ES聚合分析已经成为现代大数据平台的核心组件之一。它支持多种类型的聚
  • Java 重写(Override)与重载(Overload) 叨唧唧的
    Java重写(Override)与重载(Overload)重写(Override)重写是子类对父类的允许访问的方法的实现过程进行重新编写,返回值和形参都不能改变。即外壳不变，核心重写！重写的好处在于子类可以根据需要，定义特定于自己的行为。也就是说子类能够根据需要实现父类的方法。重写方法不能抛出新的检查异常或者比被重写方法申明更加宽泛的异常。例如：父类的一个方法申明了一个检查异常IOExceptio
  • 苦，是因为爱上了某样东西 阿梅心理咨询师
    佛法里面一直强调，“我执”，苦，是因为陷入了“我执”，我喜欢某样东西，陷入了求不得之苦，我不喜欢我的长相，外貌，身材，因为我想要更美，陷入了“我不美”的执念。我想要考个好成绩，因为我想要进入某所大学，所以开始焦虑。我想要找个男朋友，想要拥有一段美丽的爱情，所以陷入了“情执”。这些想，都是因为求不得。求不得，所以苦。因为爱之切，所以陷入僵局。其实这些念，佛家讲都是虚妄的。可是好多人不自知。依旧寻寻觅
  • java杨辉三角 3213213333332132 java基础
    package com.algorithm; /** * @Description 杨辉三角 * @author FuJianyong * 2015-1-22上午10:10:59 */ public class YangHui { public static void main(String[] args) { //初始化二维数组长度 int[][] y
  • 《大话重构》之大布局的辛酸历史 白糖_ 重构
    《大话重构》中提到“大布局你伤不起”，如果企图重构一个陈旧的大型系统是有非常大的风险，重构不是想象中那么简单。我目前所在公司正好对产品做了一次“大布局重构”，下面我就分享这个“大布局”项目经验给大家。   背景         公司专注于企业级管理产品软件，企业有大中小之分，在2000年初公司用JSP/Servlet开发了一套针对中
  • 电驴链接在线视频播放源码 dubinwei 源码电驴播放器视频ed2k
    本项目是个搜索电驴（ed2k）链接的应用,借助于磁力视频播放器（官网： http://loveandroid.duapp.com/ 开放平台），可以实现在线播放视频，也可以用迅雷或者其他下载工具下载。 项目源码： http://git.oschina.net/svo/Emule,动态更新。也可从附件中下载。 项目源码依赖于两个库项目，库项目一链接： http://git.oschina.
  • Javascript中函数的toString()方法 周凡杨 JavaScriptjstoStringfunctionobject
    简述     The toString() method returns a string representing the source code of the function.     简译之，Javascript的toString()方法返回一个代表函数源代码的字符串。 句法     function.
  • struts处理自定义异常 g21121 struts
    很多时候我们会用到自定义异常来表示特定的错误情况，自定义异常比较简单，只要分清是运行时异常还是非运行时异常即可，运行时异常不需要捕获，继承自RuntimeException，是由容器自己抛出，例如空指针异常。 非运行时异常继承自Exception，在抛出后需要捕获，例如文件未找到异常。 此处我们用的是非运行时异常，首先定义一个异常LoginException: /** * 类描述：登录相
  • Linux中find常见用法示例 510888780 linux
    Linux中find常见用法示例 ·find   path   -option   [   -print ]   [ -exec   -ok   command ]   {} \; find命令的参数；
  • SpringMVC的各种参数绑定方式 Harry642 springMVC绑定表单
    1. 基本数据类型(以int为例，其他类似)： Controller代码： @RequestMapping("saysth.do") public void test(int count) { } 表单代码： <form action="saysth.do" method="post&q
  • Java 获取Oracle ROWID aijuans javaoracle
    A ROWID is an identification tag unique for each row of an Oracle Database table. The ROWID can be thought of as a virtual column, containing the ID for each row. The oracle.sql.ROWID class i
  • java获取方法的参数名 antlove javajdkparametermethodreflect
    reflect.ClassInformationUtil.java package reflect; import javassist.ClassPool; import javassist.CtClass; import javassist.CtMethod; import javassist.Modifier; import javassist.bytecode.CodeAtt
  • JAVA正则表达式匹配 查找 替换 提取操作 百合不是茶 java正则表达式替换提取查找
    正则表达式的查找;主要是用到String类中的split();       String str;      str.split();方法中传入按照什么规则截取,返回一个String数组   常见的截取规则: str.split("\\.")按照.来截取 str.
  • Java中equals()与hashCode()方法详解 bijian1013 javasetequals()hashCode()
    一.equals()方法详解     equals()方法在object类中定义如下：  public boolean equals(Object obj) { return (this == obj); }    很明显是对两个对象的地址值进行的比较（即比较引用是否相同）。但是我们知道，String 、Math、I
  • 精通Oracle10编程SQL(4)使用SQL语句 bijian1013 oracle数据库plsql
    --工资级别表 create table SALGRADE ( GRADE NUMBER(10), LOSAL NUMBER(10,2), HISAL NUMBER(10,2) ) insert into SALGRADE values(1,0,100); insert into SALGRADE values(2,100,200); inser
  • 【Nginx二】Nginx作为静态文件HTTP服务器 bit1129 HTTP服务器
     Nginx作为静态文件HTTP服务器 在本地系统中创建/data/www目录，存放html文件(包括index.html) 创建/data/images目录，存放imags图片 在主配置文件中添加http指令   http { server { listen 80; server_name
  • kafka获得最新partition offset blackproof kafkapartitionoffset最新
    kafka获得partition下标，需要用到kafka的simpleconsumer   import java.util.ArrayList; import java.util.Collections; import java.util.Date; import java.util.HashMap; import java.util.List; import java.
  • centos 7安装docker两种方式 ronin47
          第一种是采用yum 方式              yum install -y docker           
  • java-60-在O(1)时间删除链表结点 bylijinnan java
    public class DeleteNode_O1_Time { /** * Q 60 在O(1)时间删除链表结点 * 给定链表的头指针和一个结点指针(!!)，在O(1)时间删除该结点 * * Assume the list is: * head->...->nodeToDelete->mNode->nNode->..
  • nginx利用proxy_cache来缓存文件 cfyme cache
    user  zhangy users; worker_processes 10; error_log  /var/vlogs/nginx_error.log  crit; pid        /var/vlogs/nginx.pid; #Specifies the value for ma
  • [JWFD开源工作流]JWFD嵌入式语法分析器负号的使用问题 comsci 嵌入式
        假如我们需要用JWFD的语法分析模块定义一个带负号的方程式，直接在方程式之前添加负号是不正确的，而必须这样做：     string str01 = "a=3.14;b=2.71;c=0;c-((a*a)+(b*b))"     定义一个0整数c,然后用这个整数c去
  • 如何集成支付宝官方文档 dai_lm android
    官方文档下载地址 https://b.alipay.com/order/productDetail.htm?productId=2012120700377310&tabId=4#ps-tabinfo-hash 集成的必要条件 1. 需要有自己的Server接收支付宝的消息 2. 需要先制作app，然后提交支付宝审核，通过后才能集成 调试的时候估计会真的扣款，请注意
  • 应该在什么时候使用Hadoop datamachine hadoop
    原帖地址：http://blog.chinaunix.net/uid-301743-id-3925358.html 存档，某些观点与我不谋而合，过度技术化不可取，且hadoop并非万能。 --------------------------------------------万能的分割线-------------------------------- 有人问我，“你在大数据和Hado
  • 在GridView中对于有外键的字段使用关联模型进行搜索和排序 dcj3sjt126com yii
    在GridView中使用关联模型进行搜索和排序 首先我们有两个模型它们直接有关联: class Author extends CActiveRecord { ... } class Post extends CActiveRecord { ... function relations() { return array( '
  • 使用NSString 的格式化大全 dcj3sjt126com Objective-C
    格式定义The format specifiers supported by the NSString formatting methods and CFString formatting functions follow the IEEE printf specification; the specifiers are summarized in Table 1. Note that you c
  • 使用activeX插件对象object滚动有重影 蕃薯耀 activeX插件滚动有重影
      使用activeX插件对象object滚动有重影   <object style="width:0;" id="abc" classid="CLSID:D3E3970F-2927-9680-BBB4-5D0889909DF6" codebase="activex/OAX339.CAB#
  • SpringMVC4零配置 hanqunfeng springmvc4
    基于Servlet3.0规范和SpringMVC4注解式配置方式，实现零xml配置，弄了个小demo，供交流讨论。     项目说明如下： 1.db.sql是项目中用到的表，数据库使用的是oracle11g 2.该项目使用mvn进行管理，私服为自搭建nexus,项目只用到一个第三方 jar，就是oracle的驱动； 3.默认项目为零配置启动，如果需要更改启动方式，请
  • 《开源框架那点事儿16》：缓存相关代码的演变 j2eetop 开源框架
    问题引入 上次我参与某个大型项目的优化工作，由于系统要求有比较高的TPS，因此就免不了要使用缓冲。 该项目中用的缓冲比较多，有MemCache，有Redis，有的还需要提供二级缓冲，也就是说应用服务器这层也可以设置一些缓冲。 当然去看相关实现代代码的时候，大致是下面的样子。 [java] view plain copy print ? public vo
  • AngularJS浅析 kvhur JavaScript
    概念 AngularJS is a structural framework for dynamic web apps. 了解更多详情请见原文链接：http://www.gbtags.com/gb/share/5726.htm Directive 扩展html，给html添加声明语句，以便实现自己的需求。对于页面中html元素以ng为前缀的属性名称，ng是angular的命名空间
  • 架构师之jdk的bug排查(一)---------------split的点号陷阱 nannan408 split
    1.前言.    jdk1.6的lang包的split方法是有bug的,它不能有效识别A.b.c这种类型,导致截取长度始终是0.而对于其他字符,则无此问题.不知道官方有没有修复这个bug. 2.代码 String[] paths = "object.object2.prop11".split("'"); System.ou
  • 如何对10亿数据量级的mongoDB作高效的全表扫描 quentinXXZ mongodb
      本文链接:  http://quentinXXZ.iteye.com/blog/2149440 一、正常情况下，不应该有这种需求 首先，大家应该有个概念，标题中的这个问题，在大多情况下是一个伪命题，不应该被提出来。要知道，对于一般较大数据量的数据库，全表查询，这种操作一般情况下是不应该出现的，在做正常查询的时候，如果是范围查询，你至少应该要加上limit。 说一下，
  • C语言算法之水仙花数 qiufeihu c算法
    /** * 水仙花数 */ #include <stdio.h> #define N 10 int main() { int x,y,z; for(x=1;x<=N;x++) for(y=0;y<=N;y++) for(z=0;z<=N;z++) if(x*100+y*10+z == x*x*x
  • JSP指令 wyzuomumu jsp
    jsp指令的一般语法格式： <%@ 指令名 属性 =”值 ” %> 常用的三种指令： page,include,taglib page指令语法形式： <%@ page 属性 1=”值 1” 属性 2=”值 2”%> include指令语法形式： <%@include file=”relative url”%> (jsp可以通过 include
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他