refs/heads/master: ⽂件⾥保存当前 master 分⽀的最新 commit id。
objects: 包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改。
前言
Git版本控制工具贯穿于我们生活中，尤其是对于从事计算机的同孩们，是一项必须掌握的技能，本文将全面对Git进行讲解，以下是大致的内容：
- 掌握 Git 企业级应⽤，深刻理解Git操作过程与操作原理，理解⼯作区，暂存区，版本库 的含义.
- 掌握 Git 版本管理，⾃由进⾏版本回退、撤销、修改等Git操作⽅式与背后操作原理.
- 掌握 Git 分⽀管理，从分⽀创建，切换，合并，删除的整个⽣命周期，灵活进⾏各种场景 下的分⽀管理，学习常⻅分⽀管理策略.
- 掌握 Git 远程仓库与本地仓库，结合版本管理与分⽀管理，做到基于分⽀级的个⼈级开发.
- 理解分布式版本控制系统，学习远程仓库与本地仓库的交互操作，掌握多⼈协作开发模式.
- 学习企业级常⻅分⽀策略(master/release/develop/feature/hotfix等)，理解不同公 司，不同环境下适合的分⽀模型。结合案例，引⼊⼯程师，测试⼈员，技术经理等⻆⾊，展现项⽬ 开发过程的全貌，深刻理解开发的整体流程，俯视Git在其中的作⽤.
通过学习本文内容，您将熟悉Git基本操作，但还需要勤加练习，学习是一个持续的过程，需要反复.
一、Git是什么？
1.1 版本控制器的概念
想要了解Git，需要先理解版本控制器的概念。所谓的版本控制器，就是能让你了解到⼀个⽂件的历史，以及它的发展过程的系统。通俗的讲就是⼀个可以记录⼯程的每⼀次改动和 版本迭代的⼀个管理系统，同时也⽅便多⼈协同作业。举个例子：比如你每天都要进行写代码，但有一天因为电脑突然发生故障，开不了机了，你每天保存的代码文件就丢失了，但有了版本控制器就不会发生这种情况，你可以为你代码文件创建一个仓库，进行管理，能清楚的知道，自己对哪些代码修改过，对代码文件了如指掌，及时电脑发送故障，代码文件丢失，但你通过版本控制器，可以将代码文件上传到远程服务器上，列如：Gitee、Github，你就多了一份保险了！
1.2 Git的强大
⽬前最主流的版本控制器就是 Git 。Git 可以控制电脑上所有格式的⽂件，例如 doc、excel、dwg、 dgn、rvt等等。对于我们开发⼈员来说，Git 最重要的就是可以帮助我们管理软件开发项⽬中的源代码⽂件！但Git也不是无所不能的，如以下：
所有的版本控制系统，Git 也不例外，其实只能跟踪⽂本⽂件的改动，⽐如 TXT ⽂ 件，⽹⻚，所有的程序代码等等。版本控制系统可以告诉你每次的改动，⽐如在第5⾏加了⼀个单词 “Linux”，在第8⾏删了⼀个单词 “Windows”。 ⽽图⽚、视频这些⼆进制⽂件，虽然也能由版本控制系统管理，但没法跟踪⽂件的变化，只能把⼆进 制⽂件每次改动串起来，也就是只知道图⽚从100KB改成了120KB，但到底改了啥，版本控制系统不 知道，也没法知道.
1.3 Git的安装
| 平台 | 安装命令 | 删除命令 |
| Linux-centos | sudo yum install git -y | sudo yum remove git-y |
| Linux-ubuntu | sudo apt-get install git -y | sudo apt-get remove git -y |
| 查看Git的版本 | git --version | |
| 查看是否安装Git | git | |
二、Git 基本操作
2.1 创建 Git 本地仓库
仓库是进⾏版本控制的⼀个⽂件⽬录。我们要想对⽂件进⾏版本控制，就必须先创建 ⼀个仓库出来。
| 创建本地仓库 | 配置用户名 | 配置邮箱 |
| git init（在本地文件目录下执行） | git config [--global] user.name "你的名称" | git config [--global] user.email "你的邮箱" |
| 查看本地仓库配置 | git config -l | |
| 删除用户名 | git config [--global] --unset user.name | |
| 删除邮箱 | git config [--global] --unset user.email | |
注：
- 执行完git init命令后，在该目录下会出现一个隐藏文件.git，.git ⽬录是 Git 来跟踪管理仓库的，不要⼿动 修改这个⽬录⾥⾯的⽂件，不然改乱了，就把 Git 仓库给破坏了。
- 配置项[--global]表示进行全局配置，简单来说就是无论在那个仓库中，我们都使用该用户名和邮箱。如果你希望在不同仓库中使⽤不同的 name 或 e-mail ，可以不要 --global 选项，但要注意的是，执⾏命令时必须要在仓库⾥。
- 当我们使用gitee或gihub时，配置的用户名与邮箱必须与平台上的一致。
2.2 认识⼯作区、暂存区、版本库
| 工作区 | 是在电脑上你要写代码或⽂件的⽬录。 | ||
| 暂存区 | 英⽂叫 stage 或 index。⼀般存放在 .git ⽬录下的 index ⽂件（.git/index）中，我们 把暂存区有时也叫作索引（index）。 | ||
| 版本库 | ⼜名仓库，英⽂名 repository 。⼯作区有⼀个隐藏⽬录 .git ，它不算⼯作区，⽽ 是 Git 的版本库。这个版本库⾥⾯的所有⽂件都可以被 Git 管理起来，每个⽂件的修改、删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。 | ||
- 图中左侧为⼯作区，右侧为版本库。Git 的版本库⾥存了很多东西，其中最重要的就是暂存区。
- 在创建 Git 版本库时，Git 会为我们⾃动创建⼀个唯⼀的 master 分⽀，以及指向 master 的⼀个指 针叫 HEAD。
- 当对⼯作区修改（或新增）的⽂件执⾏ git add 命令时，暂存区⽬录树的⽂件索引会被更新。
- 当执⾏提交操作 git commit 时，master 分⽀会做相应的更新，可以简单理解为暂存区的⽬录 树才会被真正写到版本库中。
- 通过新建或粘贴进⽬录的⽂件，并不能称之为向仓库中新增⽂件，⽽只是 在⼯作区新增了⽂件。必须要通过使⽤ git add 和 git commit 命令才能将⽂件添加到仓库中 进⾏管理！！！
- objects 为 Git 的对象库，⾥⾯包含了创建的各种版本库对象及内容。时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中，就位于".git/objects" ⽬录下。
- .git文件虽然处于工作区中，但它不属于工作区，而是版本库。
2.3 add、commit命令
| Add | commit | |
| 添加一个或多个文件到暂存区 | git add [file1] [file2] ... | git commit [file1] [file2] ... -m "message" |
| 添加制定目录到暂存区，包括子目录 | git add [dir] | / |
| 提交暂存区全部内容到本地仓库中 | / | git commit -m "message" |
| 添加当前⽬录下的所有⽂件改动到暂存区 | git add . | / |
注意：
- git commit 后⾯的 -m 选项，要跟上描述本次提交的 message，由⽤⼾⾃⼰完成，这部分内 容绝对不能省略，并要好好描述，是⽤来记录你的提交细节，是给我们⼈看的。
- 执行Commit后，才算真正的将文件储存到了git仓库中。
2.4 Git log命令
| 查看历史提交记录 | git log |
| 简化版(一行显示信息) | git log --pretty=oneline |
| 可视化查看历史提交记录(分支的合并时比较明显) | git log --graph |
| 简化commit id | git log --abbrev-commit |
注：
需要说明的是，我们看到的⼀⼤串类似 23807c5...56eed6 的是每次提交的 commit id （版本 号），Git 的 commit id 不是1，2，3……递增的数字，⽽是⼀个 SHA1 计算出来的⼀个⾮常⼤的数 字，⽤⼗六进制表⽰（你看到的 commit id 和我的肯定不⼀样，以你⾃⼰的为准）。
2.5 .git文件
- index 就是我们的暂存区，add 后的内容都是添加到这⾥的.
- HEAD 就是我们的默认指向 master 分⽀的指针：
- master分支中，存储的是：（保存的就是当前最新 的 commit id）
- objects 为 Git 的对象库，⾥⾯包含了创建的各种版本库对象及内容
查找 object 时要将 commit id 分成2部分，其前2位是⽂件夹名称，后38位是⽂件名称。 找到这个⽂件之后，⼀般不能直接看到⾥⾯是什么，该类⽂件是经过 sha （安全哈希算法）加密过的 ⽂件，好在我们可以使⽤ git cat-file 命令来查看版本库对象的内容：
tree为本地所有Commit id，用git cat-file -p 可以查看：
现在想查看test1对应的内容，就可以再一次执行git cat-file -p 命令，但要注意，真正的commit id是最后一条id：
-
index: 暂存区,git add 后会更新该内容。
-
HEAD: 默认指向 master 分⽀的⼀个指针。
-
refs/heads/master: ⽂件⾥保存当前 master 分⽀的最新 commit id。
-
objects: 包含了创建的各种版本库对象及内容，可以简单理解为放了 git 维护的所有修改。
2.6 修改文件
| 查看当前仓库的状态 | git status |
| 显示暂存区与工作区文件的差异 | git diff + 文件名 |
| 显示版本库与工作区的差异 | git diff HEAD -- 文件名 |
注：Git追踪管理的其实是修改，而不是文件
2.7 版本回退
| 只回退版本库中的内容 | git reset --soft [HEAD]/commit ID |
| 回退暂存区的内容 | git reset [HEAD]/commit ID |
| 回退所有内容 | git reset --hard [HEAD]/commit ID |
注：
- 默认为--mixed
- --hard 参数将暂存区与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命 令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。
- HEAD 说明：可直接写成 commit id，表⽰指定退回的版本 ◦
- HEAD 表⽰当前版本
- HEAD^ 上⼀个版本
- HEAD^^ 上上⼀个版本 ，以此类推...
- 可以使⽤ 〜数字表⽰：HEAD~0 表⽰当前版本 ， HEAD~1 上⼀个版本 ，HEAD^2 上上⼀个版本 ◦ 以此类推...
当进行回退后，又想回到回退前的状态，但拿不到Commit ID该怎么办？
- git reflog --> 用来记录本地每一次提交
- 找到想回退的Commit ID
- 使用git reset ..... 命令
注意：当我们在开发时，想找到Commit ID 并不容易，因此我们需要对git reset .... 命令谨慎。
Git 的版本回退速度⾮常快，因为 Git 在内部有个指向当前分⽀（此处是master）的 HEAD 指针， refs/heads/master ⽂件⾥保存当前 master 分⽀的最新 commit id 。当我们 在回退版本的时候，Git 仅仅是给 refs/heads/master 中存储⼀个特定的version，可以简单理解 成如下⽰意图：
2.8 撤销修改
情况一：在工作区进行代码开发中，想进行撤销：
git checkout -- 文件（将工作区文件回到最近一次add、commit时的状态）
情况二：当工作区和暂存区同时存在想撤销的代码时：
- 用 git reset .... 命令（回到当前版本库的版本），因为还没进行commit操作，版本库中的版本还是上一次的，用HEAD就表示当前版本。
- git reset --mixed HEAD 暂存区回到当前版本，然后再使用情况一的解决方法
- git reset --hard HEAD 所有内容回到当前版本
情况三：当工作区、暂存区、版本库均想撤销代码时：
git reset --hard HEAD^ 即可
注：撤销的目的是不影响远程仓库的代码。
2.9 删除文件
| 方法一（不推荐,只删除了工作区） | 方法二（推荐） |
| 1、rm + 文件 2、git add + 文件 3、git commit -m " " | 1、git rm + 文件 2 、git commit -m " " |
2.10 分支管理
| 查看当前本地仓库分支 | git branch |
| 创建分支 | git checkout+ 分支名 |
| 切换分支 | git branch + 分支名 |
| 合并分支 | git merge + 分支名 |
| 删除分支（已合并） | git branch -d + 分支名 |
| 创建+切换 | git checkou -b +分支名 |
| 可视化查看分支合并情况 | git log --graph [--pretty=oneline] --abbrev-commit |
| 合并分支+提交commit（no-ff模式下） | git merge --no-ff + 分支名 -m "描述" |
| 将工作区的内容进行暂时保存 | git stash |
| 查看stash中有哪些内容 | git stash list |
| 恢复工作区中的内容(stash中) | git stash pop |
| 当还没merge分支时想强制删除分支 | git branch -D + 分支名 |
注：
- HEAD可以指向其它分支，被指向的分支就是当前正在工作的分支。
- 查看分支时，分支名前有一个*
- 新创建的分支中，也是指向最新一次提交
- 当我们进行分支合并时，不能处于被合并分支上，需要切换回到选择分钟下进行
- 不能处在当前分支下删除自己
- 合并冲突问题：当两个分支同时对一个文件进行修改后，进行合并时，git不能替我们决定保留哪一些内容，因此，我们需要cat + 被修改文件，会看到<<<<<<<，=======，>>>>>> 来标记出不同分⽀的冲突内容，只需要保留自己想要的后，add、commit就可以了。
- merge合并有两种模式，一种为Fast forward模式，一种为no-ff模式，默认合并分支是Fast forward模式。
- 可视化查看合并分支时，Fast forward模式情况下，看不出是合并分支的提交还是正常提交。
- 建议使用no-ff模式，这种模式能更加直观的表示合并分支提交。
- master分支称为主分支，存储的文件必须是稳定的。
- 其它分支根据具体功能创建
- 有了分支管理，我们就能进行多人开发
- 出现bug时，我们开发到一半，需要创建一个分支解决bug，我们可以将正开发的工作区文件保存：git stash，但需要注意的是，该文件之前已经被git追踪管理过(add、commit过)，解决完bug后，在git stash pop恢复继续开发
2.11 远程操作
2.11.1 分布式版本控制系统
我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者 计算机上。⽽我们的 Git 其实是分布式版本控制系统！什么意思呢？ 可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹ 了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作 呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需 把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了。
分布式版本控制系统的安全性要⾼很多，因为每个⼈电脑⾥都有完整的版本库，某⼀个⼈的电脑坏掉 了不要紧，随便从其他⼈那⾥复制⼀个就可以了。 在实际使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能 你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开 机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅 是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部 丢失，包括git的所有内容）
2.11.2 远程仓库
常见的远程仓库：gitHub、Gitee.....等等。其目的是为了提高工作效率，比如每个⼈都从这个“服务 器”仓库克隆⼀份到⾃⼰的电脑上，并且各⾃把各⾃的提交推送到服务器仓库⾥，也从服务器仓库中 拉取别⼈的提交。
| 克隆远程仓库 | git clone + gitee 仓库地址 |
| 查看远程仓库信息 | git remote [-v](-v为更加详细) |
| 对于ssh协议，创建公钥和私钥文件 | ssh -keygen -t rsa -c "gitee上的邮箱" |
| 将本地仓库上某分支推送到远程仓库某分支上 | git push + 远程仓库名 本地分钟：远程分支（同名保留搞一个） |
| 拉去远程仓库某分支到本地仓库某分支上 | git pull + 远程仓库名 本地分钟：远程分支（同名保留搞一个） |
| 当已忽略的文件，想提交时 | git add -f (强制提交) |
| 查看某个文件为什么被忽略 | git check-ignore -v + 文件名 |
| 给git命令起别名 | git config [--global] alias.别名 + 命令名 |
| 推送本地仓库分支里内容到远程仓库分支上（前提条件是本地与远程分支已连接） | git push |
| 拉去远程仓库分支里内容到本地仓库分支上（前提条件是本地与远程分支已连接） | git pull |
Issues模版文件：用于发现bug的提示文件，可供他人在该文件对该项目提一些自己发现的bug，让我们解决。
Pull Requests模版文件：当开发者对自己的分支开发完毕后，想进行merge操作到master时，可以在该文件进行申请，申请后等待通过，称之为合并申请。
Https协议进行克隆：直接复制地址。
SSH协议进行克隆：使用的是公钥加密，公钥登录的机制。
- 想进行克隆操作，必须将本地公钥放到Gitee等托管平台中
- 创建SSH key，先查看主目录下是否有.SSH目录，有的话，再看该目录下是否有 id_rsa 和id_rsa.pub文件：id_rsa为私钥、id_rsa.pub为公钥 （打开公钥文件，复制内容，取gitee配置）
- 如果没有这两个文件。则使用命令创建
本地仓库领先远程仓库下：
push操作其实是本地与远程两个分支的交互。
pushi是将本地仓库上的修改推送到远程中，让远程仓库保持拥有最新的代码。
远程仓库领先本地仓库：
将最新的分支代码与本地进行了合并
.gitignore文件：
- 不想让git追踪管理某个文件时，写入其中。
- 该文件处于git工作区中
- 忽略单个文件时，直接写文件名
- 忽略一类文件时，*.+文件名后缀
- 表示不忽略某个文件：! + 文件名
- *.+文件名后缀 和 ! + 文件名 常搭配使用
- 编写完毕后，需要add、commit
注意：我们在配置Git name和email时，需要和gite等托管平台上的用户名和邮箱相同
2.12 标签管理
简单理解为对某次commit的一个标识，相当于起一个别名，可以给重要的东西打上tag，这样方便找到对应的commit id，进行内容查看。
| 给最新一次提交打上标签 | git tag + 标签名 |
| 查看当前有哪些标签 | git tag |
| 对之前提交打标签 | git tag + 标签名 + commit id |
| 创建带说明的标签 | git tag -a + 标签名 -m "描述" + [commit id / 不写，则为最新一次提交] |
| 查看该标签详细信息 | git show + 标签名 |
| 删除标签 | git tag -d +标签名 |
| 将本地仓库某个标签推送到远程仓库中 | git push + 远程仓库名 + 标签名 |
| 将本地仓库全部标签推送到远程仓库中 | git push + 远程仓库名 --tags |
| 删除远程仓库标签 | 1、在本地先删除：git tag -d 标签名 |
| 2、git push 远程仓库名 :标签名 |
三、Git多人协作
| 查看远程分支 | git branch -r |
| 查看当前分支情况（本地+远程） | git branch -a |
| 创建+切换+与远程分支建立联系 | git checkout -b + 分支名 + 远程分支名/远程仓库名 |
| 查看是否与远程分支建立联系 | git branch -vv |
| 与远程分支建立联系 | git branch --set-upstream-to=远程仓库名/远程分支名 + 本地分支 |
| 展示远程分支具体情况 | git remote show 远程分支名 |
| git remote prune 远程分支名 |
注意点：
- 在进行分支合并到master中时，我们可以先对master进行合并，查看是否发送问题，在合并到master分支上，这是一种好习惯，当发送问题时，我们可以进行解决，如果合并到master上发送问题，解决的过程容易改出更大的bug。
- git push 与 git pull 这两种命令后面可以直接使用，但前提是需要跟远程分支取得联系。
- 当进行clone操作时，本地仓库就与远程仓库取得了联系，但在后续的新分支上，需要自行创建，如不创建，则用git push 远程仓库名 + ... ，git pull 远程仓库名 +....
270
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
