① 文件夹A，里面有一个子文件夹B，B中已经添加过git了，现在我想给A加上git，并且包含B，我应该怎么做
是否是说通过git init初始化过B目录？
如果是这个意思，那么你可以删除B目录下的.git目录，然后在A目录下再次执行git init，则可以把A/B目录皆纳入git仓库。
② Git常用命令
1.1 配置环境
当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息。该用户信息和GitHub上注册的远程仓库的相关信息没有任何关系。
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --list
配置信息保存在用户目录下的.giitconfig文件中
1.2 获取Git仓库
要使用Git对我们的代码进行版本控制，首先需要获得Git仓库
获取Git仓库通常有两种方式：
执行步骤如下：
1、在电脑的任意位置创建一个空目录作为我们的本地Git仓库
2、进入这个目录中，点击右键打开Git bash 窗口
3、执行命令git init
可以通过Git提供的命令从远程仓库进行克隆，将远程仓库克隆到本地的命令形式为：
git clone 远程Git仓库地址
1.3 工作目录、暂存区以及版本库概念
版本库：.git隐藏文件就是版本库，版本库存储了很多配置信息、日志信息和文件版本信息等
工作目录（工作区）：包含.git文件夹的目录就是工作目录，主要用于存放开发的代码
暂存区：.git文件夹中有很多文件，其中一个index文件就是暂存区，也可以叫做stage。暂存区是一个临时保存修改文件的地方
1.4 Git工作目录下文件的两种状态
Git工作目录下的文件存在两种状态：
Unmodified 未修改状态
Modified 已修改状态
Staged 已暂存状态
这些文件的状态会随着我们执行Git的命令发生变化
1.5 本地仓库操作
git status 查看文件状态
也可以使用git status -s使输出信息更简洁
git add 将未跟踪的文件加入暂存区，将已经修改的文件加入暂存区也是通过这个命令
git reset 将暂存区文件取消暂存
git commit -m “你的说明” 将暂存区文件提交到本地仓库
git rm 删除文件 说明：这种操作是直接将文件加入到暂存区里面，直接提交到本地仓库生效，而直接删除的话没有进入到暂存区，需要先把文件加入到暂存区之后，再提交到本地仓库。
将文件添加至忽略列表
一般我们总会有些文件无需纳入Git的管理，也不希望他们总出现在未跟踪文件列表。通常这些都是自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以在工作目录中创建一个名为.gitnore的文件（文件名称固定），列出忽略的文件模式。下面是一个示例：#代表注释
由于windows无法创建不含文件名的文件，因此我们需要在bash窗口中用如下命令创建。
git log 查看日记记录
1.6 远程仓库操作
如果想查看已经配置的远程仓库服务器，可以运行git remote 命令。它会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少可以看见origin，这是Git克隆的仓库服务器的默认名字
git remote -v 可以查看对远程仓库详细一点的说明
git remote show origin 可以查看对origin更详细的远程仓库的说明
运行git remote add 添加一个远程Git仓库，同时指定一个可以引用的简写
如果你想获得一份已经存在了的Git仓库的拷贝，这时需要用到 git clone 命令。Git克隆的是Git仓库服务器上的几乎所有数据（包括日志信息、 历史 记录等），而不仅仅是复制工作所需要的文件。当你执行git clone 命令的时候，默认配置下Git仓库中的每一个文件的每一个版本都将被拉取下来。
如果因为一些原因想要移除一个远程仓库，可以使用git remote rm
注意：此命令只是从本地移除远程仓库的记录，并不会影响到远程仓库
git fetch 是从远程仓库获取最新版本到本地仓库，不会自动merge
说明：如果使用fetch命令，拉取的文件会放到版本库里面，不会自动整合到工作区，如果需要整合到工作区，需要使用 git merge 远程仓库别名/远程仓库分支
git pull 是从远程仓库获取最新版本并merge到本地仓库
注意：如果本地仓库不是从远程仓库克隆，而是本地创建的仓库，并且仓库中存在文件，此时再从远程仓库中拉取文件的时候会报错（fatal：refusing to merge unrelated histories），解决此我呢提可以在git pull 命令后加入参数 --allow-unrelated-histories
git push
1.7 Git分支
几乎所有的版本控制系统都是以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。Git的master是一个特殊分支。它跟其它分支没有区别。之所以每一个仓库都有mater分支，是因为git init默认创建它，并且大多数人都懒得去改动它。
# 列出所有本地分支
$ git branch
#列出所有远程分支
$ git branch -r
#列出所有本地分支和远程分支
$git branch -a
git branch 分支名称
git checkout 分支名称
git push 远程仓库别名 远程仓库分支
git merge 分支名称 说明：在当前分支下合并其他分支
注意：如果两个分支存在同样的文件名且同行的内容不一样，那么会产生矛盾，需要自己手动修改产生矛盾后的文件，然后添加到暂存区然后提交。
git branch -d 分支名称
如果要删除的分支中进行了一些开发动作，此时执行上面的删除命令并不会删除分支，可以将命令中的-d参数改为-D
如果要删除远程仓库中的分支，可以使用命令git push origin -d branchName
1.8 Git标签
像其他版本控制系统一样，Git可以给 历史 中的某一给提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布结点（v1.0、v1.2等）。标签指的是某个分支某个特定时间点的状态。通过标签，可以很方便地切换到标记时的状态。
#新建一个tag
$ git tag [tagName]
$ git tag
#新建一个分支，指向某个tag
$ git checkout -b [branch] [tag]
#删除本地tag
$git tag -d[tag]
#删除远程tag
$git push origin :refs/tags/[tag]
③ Git上传文件及文件夹
最近做一批大麦转录组数据的分析，考虑到这个物种注释还不是很完善，所以自己做了一个orgdb的注释包，传到github上，供实验室的师弟和师妹用下。
第一个想到的就是git上传。
很早之前，就安装过git并绑定了github账号，但是一段时间不用，就忘记了。
所以记录下git建库及上传的过程。
首先进入到需要上传文件的项目文件夹里。（我自己建了个test文件夹）
（如果要上传文件，那么进入相应的文件夹里，上传，如果上传文件夹，可以直接在当前目录就行，我自己建了个test.txt文件）
④ git 如何忽略项目中的子文件夹
在使用git tracking 项目文件的变化时，如果项目中包含大的数据文件变化，会占用大量的空间用于记录历史，对于不需要tracking的文件，可以通过以下方法去除git tracking，以节省磁盘空间。
step1: 在git tracking目录下，简历文件,文件名为" .gitignore "。对于windows系统，系统禁止建立该文件名为“ .gitignore ”的文件，可以新建一个文件，重命名为" .gitignore. "
step2: 在文件中添加不需要跟踪的文件夹，并以'/' 结尾，如：
'excludedFOlder/'
reference: https://www.atlassian.com/git/tutorials/saving-changes/gitignore
注意，gitignor文件的编辑请使用windows自带notepad，如果某些时候gitignor不工作，使用下面语句清空cache：
git rm -r --cached .
git add .
git commit -m "fixed untracked files"
⑤ Git系列之底层原理篇
本章节是Git的核心知识点，主要是介绍Git底层原理与在使用Git过程中的几个重要区域，弄懂Git的整个使用流程，以及数据的存储过程。
工作区（Working Directory）:
工作区就是我们平时编写文本文件的地方
暂存区（Stage/Index）:
暂存区是我们提交文本文件到本地仓库的来源地，只有把工作区的文件添加至暂存区，才可以被提交至本地仓库。
本地仓库（Repository）：
本地仓库是保存每次文件更新的记录，包括提交人，提交时间，提交的内容等详细信息，方便追溯历史版本。
远程仓库（Remote Repository）：
远程仓库算是本地仓库的一个副本，主要是方便合作伙伴之间的仓库文件同步。
因此它的使用流程可以简单的概括为：
1、在本地搭建一个目录，用来创建git仓库
$ git init gitDirectory
2、在仓库目录下创建文本文件（工作区）
$ cd gitDirectory
$ echo "first txt" > first.txt
3、把工作区的first.txt文件添加至git暂存区
$ git add first.txt
4、将暂存区中的文件first.txt提交至本地仓库
$ git commit -m "first commit"
5、将文件保存至本地仓库就已经可以记录我们每次提交的历史信息了，但是为了方便其他伙伴一起协作，还需要搭建一个远程服务。（本次以GitHub为例）
在GitHub创建一个和本地一样名称的仓库，创建成功后会生成一个仓库地址：
https://github.com/mr-kings/gitDirectory.git
6、将本地仓库和远程仓库关联起来
$ git remote add origin https://github.com/mr-kings/gitDirectory.git
7、第一次将本地仓库提交至远程仓库
$ git push -u origin master
第一次需要添加 -u 参数，即把本地的master分支和远程仓库的master分支对应上
8、此时本地仓库和远程仓库就已经实现了同步，其他协作伙伴只需到远程仓库把仓库克隆到自己的电脑即可进行协作编辑
$ git clone https://github.com/mr-kings/gitDirectory.git
9、克隆下来以后会在本地生成本地仓库以及工作区，后续的操作和2步骤及以后步骤一致
需要注意的是：远程仓库有两种连接方式https/ssh，上面的例子使用的https，其实ssh方式会比https快的多，它还可以通过添加密钥的方式省去每次提交时都要输入用户名和密码的问题，这里不做详细介绍。https也是可以通过配置省去每次推送都需要输入用户名和密码的问题。
Git安装成功后，在本地新建一个Git仓库，$ git init Gitstudy会生成一个.git文件夹，如果你创建的时候没有发现.git目录那应该是你的电脑默认隐藏了.git文件夹，有两种方式可以查看它：
第一种方式：
命令行工具，在当前目录下，在命令行里输入 $ ll -a 即可查看
第二种方式：
在当前目录下，点击查看菜单，然后勾选上隐藏的项目即可
.git目录就是暂存区和本地仓库的位置，所以它的核心就在这里，下面看看它有哪些内容：
由上图可知，初始化的时候.git目录下有以下文件及文件夹：
config(文件)：存放当前仓库的一些配置信息，比如记住用户名和密码，别名等
下面是它的常用选项：
[core] ignorecase 是否忽略文件大小写
[remote "origin"] url 配置远程仓库地址
[remote "origin"] fetch 远程分支映射关系
[user] name 用户名
[user] email 邮箱
[alias] 命令别名配置 ： cmt = commit
description(文件)：创建仓库的描述文件
HEAD(文件)：指示当前被检出(所在)的分支，如当前在test分支，文件内容则为ref: refs/heads/test。
hooks/(文件夹)：包含客户端或服务端的钩子脚本(hook scripts)，如pre-commit，post-receive等
info/ (文件夹)：用以存储一些有关git仓库的信息，如exclude
objects/ (文件夹)：用以存储git仓库中的所有数据内容
refs/(文件夹)：包含 heads 文件夹，remote文件夹。heads 记录本地相关的各 git分支操作记录，remote 记录远程仓库相关的各git分支 操作记录
当第一次提交的时候还会生成以下文件及文件夹：
index (文件) -- （在git add file的时候生成）：是当前版本的文件索引，包含生成当前树(唯一确定的)对象的所虚信息，可用于快速比对工作树和其他提交树对象的差异(各commit和HEAD之间的diff)，可用于存储单文件的多个版本以有效的解决合并冲突。可使用git ls-files 查看index文件内容
COMMIT_EDITMSG(文件) -- （在git commit -m "first commit"的时候生成）：最近一次的 commit edit message
logs/ (文件夹) -- （在git commit -m "first commit"的时候生成）：放置git仓库操作记录的文件夹，包含HEAD文件 和 refs文件夹
以上简单介绍了.git目录下的文件及文件夹，重点则是objects文件夹：
经过第一次提交后objects文件夹下多出了3个文件夹：44/、d0/、f6/。通过提交的日志我们发现，commit后会生成一个40位的16进制字符串（前两位作为文件夹名称，后38位为内容哈希值）
官方描述：这是一个 SHA-1 哈希值——一个将待存储的数据外加一个头部信息(header)一起做 SHA-1 校验运算而得的校验和（前2位作为文件夹名称 -- 后面38位作为内容的哈希值）
通过cat-file -t sha-1 命令查看当前哈希值所属的类型：
由图可知它是一个commit对象
再通过命令cat-file -p sha-1查看该commit对象包含有哪些信息
由图知一个commit对象包含了tree对象，本地仓库信息，提交人信息及提交时的备注信息。
再通过上述命令查看tree对象又包含又哪些信息：
由图知tree对象又包含了blob对象，在多目录的情况下tree对象还会包含其他tree对象。
由此得出结论：刚才提交的时候生成的那个3个文件夹分别对应的是3个对象即：44/文件夹对应的是commit对象，f6/文件夹对应的是tree对象，d0/文件夹对应的是blob对象。层级关系是：commit对象对应一个tree对象，tree对象可以包含一个或多个其他tree对象和blob对象。
下面就简单介绍git中的几个对象：
blob：
blob对象只跟文本文件的内容有关，和文本文件的名称及目录无关，只要是相同的文本文件，会指向同一个blob。
tree:
tree对象记录文本文件内容和名称、目录等信息，每次提交都会生成一个顶层tree对象，它可以指向其引用的tree或blob。
commit:
commit对象记录本次提交的所有信息，包括提交人、提交时间，本次提交包含的tree及blob。
tag:
标签引用，它指向某一个commit。
用下面的图可以把今天的内容概括起来：上半部分描述了git的操作流程图，下半部分描述git底层数据存储结构图
Git流程及底层结构图
下面就对图的下半部分做个详细说明：
1、在与.git同级目录下新建文件夹directory，再在directory目录下新建一个文本文件first.txt，里面的内容为1。当执行$ git add first.txt 的时候就会在.git/objects/生成一个blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的第一个d00491 -- blob对象。
2、当执行$ git commit -m "first commit" 的时候就会在.git/objects/下新生成了2个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的f6589b -- tree对象,4a2e3e -- tree对象,6b18a7 -- commit对象。之所以生成两个tree对象是因为directory目录为一个tree对象还有与commit对象一一对应的顶层tree对象。这个时候HEAD游标指向的是当前master分支的first commit。并且在这次提交的时候打个v1.0版本的标签。
3、在与.git同级目录下新建一个新的文本文件second.txt，内容为2。当执行$ git add second.txt 的时候就会在.git/objects/生成一个新的blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的0cfbf0 -- blob对象。
4、当执行$ git commit -m "second commit" 的时候就会在.git/objects/下新生成了1个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的35e40c -- tree对象,d6dca9 -- commit对象。只生成一个与commit对象一一对应的顶层tree对象。由于本次提交directory目录下的first.txt内容没有变化，所以上图的35e40c -- tree对象还会指向f6589b -- tree对象。这个时候HEAD游标指向的是当前master分支的second commit(HEAD索引向前移动)，second commit 会指向上一次的提交即 parent指向first commit。
后续的操作以此类推，但需要注意的点是：
1、blob对象只对文件的内容有关，和文件名称无关，如果不同的文件名称，内容相同只会有一个blob对象，生成的新tree对象会指向该blob对象。例如上图的third.txt和four.txt里面的内容都为3。所以不会生成新的blob对象，新的tree对象只会指向同一个blob。
2、如果每次提交的时候包含的某些文件并没有改动（更新），那么就会直接指向它原来的索引，不会重新生成。例如上图的directory/first.txt，second.txt
3、每次commit对象都会和顶层的tree对象一一对应。
⑥ Git 进阶 - 子仓库 subtree
问题实例（真实诉求）
一个工具类库，有以下两个目标：
如果直接使用 Git 管理这个lib 添加到这个项目来呢，单独维护。可能就会出现每一次更新 repo 就要更新多个 repo 的情况。对于有很多开发协同者来说，简直是灾难。
git subtree 是什么？
git subtree 可以实现 一个仓库作为其他仓库的子仓库 ，能够相对较好的解决上面两难问题。
有个和 git subtree 概念类似的功能 git submole ，虽然都没有用过，但目前来看 git subtree 比 git submole 更加强大，是可以替代 submole 的方案。
subtree 的作用就是可以实现一个仓库作为其他仓库的子仓库，对于主项目来说，另一个项目只作为主项目的一个子目录而存在。
图片来自 ： https://segmentfault.com/a/1190000012002151
创建一个git repo GitStudy
创建一个 lib repo commonToolsCopy
使用 subtree 命令，将 tools 放到 gitStudy 目录下（作为lib）
下面 commonTools
上面命令执行后，就可以将 commonTools 仓库中 master 上的更新更新到本地
之后会生成两条日志信息
添加之后 commonTools 就是主项目的一个普通文件夹，如果这时候 commonTools 内容更新之后，正常 git push 即可，子项目对于主项目来说完全是透明的。
在主项目 git push 之后，对子项目修改的内容是不会直接更新到子项目自身的
需要执行 git subtree pull
如果单独对子项目做了更新，主项目就需要手动更新下了
执行之后，仍然会在主项目中生成相关的 commit 记录
在 subtree 相关命令经常会用到 <repository> 每次都写地址还是比较麻烦，这里可以用 git remote 命令简化写法，为这个远程地址定义一个 “别名”
比如使用 subtree push 的时候就可以使用如下命令
在添加 subtree 的时候是指定了分支的，如果要切换分支直接移除 subtree，重新加入子项目的分支
验证1：其他人 clone 该项目对 sub repo是无感知的
验证2：在主项目中修改 sub repo 的内容 push，在 app 中会形成 commit 在 sub repo 中不会有 commit
验证3：使用一下命令，可以push 到 sub repo 中 推送修改到源仓库
验证4：直接在 sub repo 项目中更新内容
那么 main repo 需要还是需要 pull 一下 从源仓库拉取更新
非原理性提示 不加 --squash 不可以，
在 pull 的过程中可能需要处理冲突
验证5：修改的内容同时包含主项目和子项目， 使用 git push 再使用 git subtree push 会做挑拣，但如果混杂的内容很多的话，这个过程也会变得复杂，so 建议 尽可能分开提交，减少这种冲突。
https://segmentfault.com/a/1190000012002151
http://einverne.github.io/post/2020/04/git-subtree-usage.html
⑦ git submole
添加后会多一个 .gitmoles 文件，文件的内容只是保存submole的引用信息，包括路径和repo地址
添加完后需要在主项目 git commit 提交新增子项目文件夹以及 .gitmoles 文件的修改
在子项目加入到项目的时候，其实做了这样三件事：
所以在当前项目push到remote repository的时候，只是更新了引用的 commit id ，那么在其他人clone项目的时候，就可以获取子项目的 commit id ，然后在 git submole update 的时候获取子项目 commit id 所表示的commit
查看子模块的commit id，如果子模块没有被checkout，前面会有 - ，那么就需要 git submole init ， git submole update
clone带有submole的项目的两种方法:
其实相当于
注意，在clone之后， cd submole/ ，然后 git status ，你会看到这样的状态
也就是说，现在是 detached HEAD ，使用 git branch 就可以查看到
所以需要 git checkout master 到master分支，然后在master分支上修改
为什么呢？因为父项目不记录子模块的修改，只记录commit id，所以clone的时候只获取到对应的commit，而不在任何分支上，但是master分支的commit id和HEAD保持一致，所以只要 git checkout master ，而不需要新建分支
注意： 只有子项目内容更新，就需要更新父项目引用的子项目的commit id
其实子项目和父项目只是独立的git项目，所以其他操作和一般git项目一样，在子项目修改，需要
其实普通的git项目一样操作，然后需要在父项目更新引用的子项目commit id，有 两 一种方法：
为什么这种方法不行呢，其实是个坑！就是你 git submole update 之后，你的子项目会恢复到你父项目引用的那个commit，也就是不是最新的commit，此时 git status 是干净的，就像第一次 git clone 项目然后 git submole init ， git submole update 一样，子项目指向的是父项目引用的那个commit，所以此时把子项目 git checkout master 之后，再切回到父项目，使用 git status ，你会发现提示子项目有新的commit，所以还是需要父项目更新引用的子项目的commit id
注意： 如果更新submole的时候有新的commit id产生，需要在父项目产生一个提交，用来更新对子项目commit id的引用
两种方法:
子项目一旦产生变动，有新的commit id，父项目必需产生一个提交，更新对子项目commit id的引用
Git Submole使用完整教程
使用Git Submole管理子模块
Git submole的坑
⑧ Git撤销与合并
1. git init
创建一个空的git repo，也就是创建一个.git的子目录，这个目录包含了几乎所有git存储和操作的东西。新初始化的.git目录的典型结构如下：
description文件仅供git web程序使用，平常无需关心。
config文件包含项目特有的配置选项。
info目录包含一个全局性排除文件，用以放置那些不希望被记录在.gitignore文件中的忽略模式。
hooks目录包含客户端或服务端的钩子脚本。
HEAD文件指向目前被检出的分支。
index文件（尚待创建）保存暂存区信息。
objects目录存储所有数据内容。
refs目录存储指向数据的提交对象的指针。
git的默认分支名字是master，git init时默认创建它。
2. git的三种状态，以及工作区(Working directory)，暂存区(Index)，HEAD
Git 有三种状态，你的文件可能处于其中之一：已修改（modified）、已暂存（staged）和已提交（committed）
基于刚才init的git project，做一些改动。
会看到在git add之后，.git下面多了一个index文件。
这时候，所做的改动就处于已暂存状态，体现在index文件中。
可以利用以下命令查看git缓存了的内容。
同时，.git/objects下面多了一个子文件夹，并生成了一个新文件。这个新文件就对应了刚才所做的改动。这就是git存储内容的方式--一个文件对应一条内容，以该内容加上特定头部信息一起的SHA-1校验和作为文件名。校验和的前两个字符用于命名子目录，余下的38个字符则作为文件名。后面会详叙。
可以通过cat-file命令从git那里查看存储的内容。
git cat-file -p
由于file1.txt的内容为空，所以这里显示为空。
这时候可以往file1.txt里添加一些内容，并git add。可以看到.git/objects又多了一个object。
查看这个新的对象的内容以及类型。会发现它是一个blob对象。
接下来commit这个change。
myProject $ git commit -m "first commit"
查看这个commit 对象的类型以及内容,commit的tree对象所指向的内容, 我们会发现，这个tree指向的是一个blob，而这个blob的内容，就是我们刚刚做过改动的文件。
同时，我们查看一下暂存区的内容：
会发现，暂存区指向的也是同样的blob对象。
至此，一个commit就提交了，工作区，暂存区，以及head又指向了同样的内容。
它们更新内容的顺序为，工作区->暂存区->head
3. git reset
将做过的change撤销掉，就像没有发生过一样。
git reset 应用的顺序为 head->暂存区->工作区。
(1) git reset --soft
当前，git的状态如下。
head指向的内容为：
（head是当前分支引用的指针，总是指向该分支上的最后一次提交。）
index指向的内容为：
(索引是你的预期的下一个提交)
我们来进行一次reset。（移动HEAD， --soft）
--soft将仅仅移动HEAD的指向，而并不会移动index以及工作区。
HEAD 指的是HEAD的父节点。HEAD 是父节点的父节点，也可以写成HEAD 2.
所以这个命令本质上是撤销了上一次git commit命令。
(2) git reset --mixed
接下来，再通过reset来更新索引。（--mixed，默认行为）
(3) git reset --hard
reset更新工作目录（--hard）
git reset --hard HEAD~
--hard标记是reset命令的危险用法，它也是git会真正销毁数据的几个操作之一。
如果这个commit已经被推送到远端，可以用这个命令使远端也回退到相应的版本。
git push origin <branch> --force
4. git revert
将做过的change撤销掉，通过“反做”某一个版本，用一个新的commit来消除做过的change。
当前git的状态：
revert其中一个commit：
再来看，多了一个commit，也就是用来revert的commit：
而若是想要revert某个版本，但是在这个版本后又做过change，则在revert的过程中可能出现冲突，则需要解决冲突之后再提交。
5. git merge 与git rebase
先来讲讲git merge。
当前master 和 dev branch：
接下来打算将dev的工作并入master分支。
另外，还想将master的工作也并入dev。
git merge之后，会发现dev branch指向了与master相同的commit：
所以，git merge是把两个分支的最新快照，以及两者最近的共同祖先进行三方合并，合并的结果是生成一个新的快照。
接下来，用git rebase来合并分支。
当前的git状态
此时，采用git rebase，将dev的工作并入到master。
当在master branch上执行git rebase dev的时候，实际发生的事情是，找到master和dev两个分支的最近共同祖先，对比当前分支（master分支）相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将master分支指向目标基底（dev的head指向的commit），最后以此将之前另存为临时文件的修改依序应用。
可以看到，rebase使得提交历史更加整洁。尽管实际的开发工作是并行在不同branch上进行的，但是它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
因此，变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。这两种方式，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同。
⑨ git的文件系统与底层原理
由于工作中使用git作为版本管理，之前对git的了解不多，特别是底层方面的原理方面的知识。为了能更好的使用git，有必要学习并梳理下相关知识。
步入正题：
执行git init 初始化后，会在.git文件夹下会创建多个目录，每个文件夹功能划分的很清晰。
Git 是一套内容寻址文件系统.通过键值对的方式存储和查找。
下面操作一遍，直观的看到整个过程，以便理解。
参考： https://git-scm.com/docs/git-hash-object
参考： http://man.linuxde.net/find
可以见到文件名称为数字和字母组成的字符串。这个是根据文件内容和头信息（Header），通过SHA-1算法计算得出的40位十六进制校验和。
SHA-1是一种加密哈希函数（cryptographic hash function）。SHA-1将文件中的内容通过其hash算法生成一个160bit的报文摘要，即40个十六进制数字（每个十六进制数字占4位）。它几乎可以保证，如果两个文件的SHA-1值是相同的，那么它们确是完全相同的内容（类似于生活中的指纹识别）；SHA-1主要有两种用途，一个是加密，一个是数据完整性校验。Linux kernel开创者和Git的开发者——Linus说，Git使用了SHA-1并非是为了安全性，而是为了数据的完整性。理论上SHA-1会在2^51攻击下实现哈希碰撞，所以也不是完全的安全。
参考： https://git-scm.com/docs/git-cat-file
模拟bolb对象存储流程
以上，说明了git的数据存储的基本方式。主要步骤：
下面是创建文件，修改文件，恢复文件的相关过程。
git会记录每个版本的修改，根据校验和可恢复到相应的版本。
小结： 这个过程中包括文件创建、文件修改、文件恢复，跟我们平时工作中使用的高级命令功能很相似。git会把整个过程转化为底层操作，同时对用户透明。
相关引用参考：
http://smilejay.com/2012/08/git-commit-sha-1/
https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1
⑩ 如何在Windows系统中创建并使用Git仓库
Git是用来管理文件版本的软件，使用它之前需要先创建仓库。那么在Windows系统中如何创建Git仓库呢？下面我给大家分享一下。
Git Bash
首先点击Windows的开始菜单，在弹出的界面中选择Git Bash选项，如下图所示
接下来进入到Git的命令行界面中我们用pwd命令先查看一下当前的路径，如下u图所示
接着用cd命令进入到要建仓库的磁盘，注意不要在C盘建立仓库，如下图所示
然后我们在磁盘下面用mkdir命令创建一个仓库文件夹，如下图所示
接下来我们进入仓库文件夹，通过git init命令对仓库进行初始化，如下图所示
然后我们打开仓库文件夹，这时你会看到文件夹下面多了一个git文件夹，这就代表此文件夹是git仓库文件夹，如下图所示
接着我们在Git仓库文件夹下面建立一个txt文本文件，并在文件中写入一些内容，如下图所示
最后我们回到Git Bash命令行，运用git add 和git commit命令对文件进行添加并提交即可，如下图所示