说明：本文只专注于Git的常用操作，如果需要十分详细的内容，参考一些资料是必须的。

参考资料：

1. 官网 https://git-scm.com/
2. Pro Git https://git-scm.com/book/zh/v2
3. 尚硅谷Git https://www.bilibili.com/video/BV1vy4y1s7k6?from=search&seid=16729592651686011517

0. Git原理简述

Git是一个版本控制系统。其实在写毕业论文的时候，认真的同学早就学会了版本控制（看下图）。可以查看历史版本的同时，版本切换也十分方便（真实）。

但是这种方式比较憨。林纳斯，也就是Linux之父，手动版本控制了Linux代码十几年，把自己整累了，后面花了两个礼拜开发了分布式版本控制系统Git，中间有一段很长的故事就不在这里讲了。

下图为Git工作机制：

这个图还缺少最后一步：本地库文件再提交到远程库，如GitHub，码云等等。

1. 设置用户签名 git config

基本语法:

git config --global user.name 用户名
git config --global user.email 邮箱

设置完后可以在用户家目录查看

对于macOS用户，cd可以直接切换到家目录

macOS在该目录中，有.gitconfig文件，里面记录了用户的签名信息。

注意：这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任何关系

2. 初始化本地库 git init

基本语法：

git init

创建一个名称为git-space的文件夹进行演示。

假设有一个项目名称叫git-demo，你需要使用Git来托管这个项目，此时就需要本地库的初始化。

步骤为：进入到git-demo文件夹后，输入git init命令。可以看到本项目的本地库成功初始化。

因为我用的是oh-my-zsh和iTerm的搭配，所以终端看着比较赏心悦目。具体设置可以查看此教程 《iTerm2 + Oh My Zsh 打造舒适终端体验》。为了颜值折腾一阵子还是挺值的。

Windows用户可以用其他终端（如powershell）代替iTerm。

查看初始化本地库后的所有文件：

可以看到文件夹里多了个.git的隐藏文件夹。

3. 查看本地库状态 git status

基本语法：

git status

在git-demo文件夹中输入git status，可查看本地库状态。

在文件夹中添加hello.txt文件，再次查看本地库状态。状态如下。

可以看到，有文件需要add，同时终端的master分支从绿色变成橙色（终端配置一下真的挺舒适的）。

4. 本地文件添加到暂存区 git add

基本语法：

git add 文件名

使用git add 文件名命令后，可以将文件添加到暂存区。查看状态得下图。

下图也展示了取消暂存的指令git -rm ...，暂存区文件被删除并不会影响本地文件。

5. 暂存区的文件提交到本地库 git commit

基本语法：

git commit -m "日志信息" 文件名

实际操作还未提交的变更，可以看到commit后工作区变干净了，master恢复到了绿色状态。同时提交时可以看到此次提交对应的版本号的前七位。

6. 查看历史版本 git reflog

基本语法：

git reflog
或
git log

reflog查看的是精简后日志信息，带有7位版本号，而log查看的是完整的信息和完整的版本号。

输入git reflog得到下图，看到的是第一次提交的记录：

输入git log得到下图，内容更为详细：

7. 修改文件后提交到本地库

修改一下Hello.txt文件后输入git status，Git检测到了有文件被修改。需要重新add和commit。

具体输入的指令如下。可以看到Git是按行来维护文件的，一行新增一行删除代表了这个文件的代码修改了一行。

查看日志，可以看到多了第二条提交记录，同时指针指向了最新的提交，说明本项目的内容版本对应的是第二次提交。

查看文件内容：

8. 版本穿梭

比如写完了代码提交后，觉得这次写的还没之前好。这个情况，通过Git回退到之前的版本就行，不用自己手动修改回去。

基本语法：

git reset --hard 前7位版本号

步骤：

1. 先查看日志，复制想回退到的版本的对应的前七位版本号。
2. 输入上列指令，本项目便可回退为之前的版本。

大致的操作效果如下，回退到了第一行没有被修改的版本。

Git 切换版本，底层其实是移动的 HEAD 指针。

9. Git分支

什么是分支？

在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也是指针的引用）

**分支的好处：**同时并行推进多个功能开发，提高开发效率。各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

如上图所示，master为主分支，用于产品上线。hot-fix为快速修复bug的分支，feature-blue和feature-game是开发新特性的分支。这三条分支各自进行开发，相互之间不影响开发，也不影响主分支。

9.1 查看分支

基本语法：

git branch -v

可以看到现在只有一条分支。

9.2 创建分支

基本语法：

git branch 分支名

举例子：我们创建一个hot-fix分支。

git branch hot-fix

创建后查看分支，可以看到多了一条hot-fix。

9.3 切换分支

基本语法：

git checkout 分支名

举例子，咱们切换到hot-fix分支：

git checkout hot-fix

可以看到分支被成功切换。

9.4 在分支上做修改

举例子，咱们在hot-fix分支上对项目做快速修复。和在master分支上修改是一样的步骤。

修改后，add然后commit即可。

查看日志后，可以看到指针的切换都有被详细记录。

9.5 合并分支

基本语法：

git merge 分支名

把指定的分支合并到当前分支上。

举例：将hot-fix上的修改合并到master

9.6 合并产生冲突

合并产生冲突在企业里是常见的情况。

冲突产生原因：

合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。

举例子：

我们在master中的hello.txt文件第一行添加信息后并提交到本地库：

同时修改hot-fix分支上hello.txt文件上的第一行，为创造冲突做准备。同时记得切换回到master分支。

在master分支下合并hot-fix分支，发现有合并冲突。说明还未合并成功，需要手动合并代码，而且冲突的地方都有标明清楚。

9.7 解决冲突

解决冲突的方法很简单，删除特殊的符号，并决定要使用的内容。

特殊符号 <<<<<<< HEAD
当前分支的代码 =======
合并过来的代码 >>>>>>> hot-fix

hello.txt部分内容：

<<<<<<< HEAD
hello git! mater test~
=======
hello git! hot-fix test
>>>>>>> hot-fix
hello git! hot-fix!!!
hello git!
hello git!
hello git!

举例子：看了下代码，觉得两个分支写的代码都挺好，所以选择都留下。修改后的hello.txt内容如下：

hello git! mater test~
hello git! hot-fix test
hello git! hot-fix!!!
hello git!
hello git!
hello git!

修改后重新add和commit，成功解决冲突（注意：此时使用 git commit 命令时不能带文件名）。

10. 总结-下一步

Git的基本操作已经学习完了，后面需要学习Git在团队内的协作机制和跨团队的协作办法。下一步，需要熟悉GitHub的使用。