推荐大家读一下大佬的《Git 原理详解及实用指南》，简单易懂，成功让我舍弃了图形化工具，转入命令行操作。

在我们日常的项目开发中，版本管理不可避免，一般常用的版本控制系统有两个 svn 和 git ，至于他们的区别，有兴趣的同学请自行研究。本文主要通过几个 git 命令的使用，结合项目开发的实际过程，来聊一聊 git 的基本使用方法。

一、初始化本地项目

当我们新接手一个项目时，首先要做的就是要从远端仓库拉取项目代码。

git clone ***** （* 为远程仓库地址）

以上是已有远程仓库时的做法，可是如果是一个全新的项目，还没有远程代码仓库，那么我们就需要先新建一个远程仓库，然后通过 git clone 命令来拉取项目代码。
你也可以先在本地初始化项目，然后关联到远程仓库：

git init   # 初始化本地的仓库，会生成.git文件
git add .  # 把所有改动添加到暂存区
git commit -m "first commit" # 编写 commit 信息
git remote add origin https://github.com/wumouren/git-demo.git # 关联本地仓库到远程
git push -u origin master # 推送本地更新到远程仓库，并设置默认推送路径

如图：

1、初始化本地仓库

2、创建远程仓库，获取远程仓库地址

3、新增本地文件，添加到暂存区，并编写 commit 信息，提交本地更新

4、关联本地仓库到远程仓库，并设置默认推送路径，推送本地更新到远端

经过上述步骤，我们再次打开远程仓库，发现本地更新已经成功推送到了远程仓库：

我们用寄快递来类比下 git 提交的过程：

git add . # 添加修改到暂存区   -->   类似与我们把需要寄出的快递挑拣出来

git commit -m '描述' # 编写 commit 信息 -->    相当于我们把快递打包，并填写快递单

git push # 推送本地更新到远程仓库   -->   相当于我们寄出快递

以上，我们简单的过了一遍 git 的使用流程，关于所用到的一些命令，在下边我们再来继续探讨。

二、添加文件改动到暂存区

当我们在本地进行需求开发时， git 总能追踪的代码的改变，我们可以通过 git status 来查看：

当我们修改 a.js 的内容，并新增 b.js 后，通过 git status 我们看到，控制台已经清晰的告诉我们，现在本地仓库有了哪些改变。我们可以通过 git add 来添加修改到暂存区。之后，我们再用 git status 来看下文件状态：

我们看到，通过 git add 把修改内容添加到暂存区后，所有的修改都变成了绿色，控制台提示信息也发生了改变。

关于 git add 的参数：这里有更多用法

git add <path>（可写多个） # 提交指定文件改动到暂存区

git add . # 提交所有被删除、被替换、被修改和新增的文件改动到数据暂存区等同于 git add -A
# 另：一些博文中说 git add . 只提交所有修改的和新建的文件改动到暂存区--即删除的文件不会被添加，可我实验多次，发现并不是这样，猜测和 git 版本有关，我的版本 2.15.2

git add -u <===> git add –update  # 提交所有被删除和修改的文件改动到数据暂存区（即新增的文件不会被添加）

git add -A <===>  git add –all   # 提交所有被删除、被替换、被修改和新增的文件改动到数据暂存区（综合了 git add . 和 git add -u）

当我们修改了多个文件后，想提交代码，可里边偏偏又有一个文件改动我们不想提交，这时我们需要用到另一个命令：

git reset 文件路径（可写多个）

如图：

上图中，我们新增了三个文件改动，然后通过 git add 把文件改动提交到暂存区，可是我们突然又觉得有些文件改动我们还不想提交，所有又通过git reset 命令撤销了相关提交。
以上操作仅做相关命令的演示，在实际的开发中，还望大家灵活使用。

关于 commit

我们把改动添加到暂存区后，下一步就是要 commit（类似与挑拣完需要快递的东西后，要进行打包填写快递单）。我们可以每一次 commit 后都进行 push 操作，也可以多次 commit 后，再进行 push 操作。我们可以 git log 来查看 commit 记录：

如图，我们通过三次 commit 分别提交了 a.js 、 b.js 、 c.js。然后通过 git log查看，可以清晰的看到我们三次 commit 分别的 commit 描述信息。（可以通过连续两个大写的 Z 来退出 git log）
如果我们突然想修改最后一次 commit 的描述信息，那么我们将会用到一个新的命令参数 git commit --amend ：

当我们输入git commit --amend 后，点击会车，我们会进入一个编辑页面。

在这个页面中我们可以修改 commit 描述信息，然后保存、退出。

具体操作为：
点击 i 建，进入插入模式，开始编辑信息。
完成后 按 esc 键，退出编辑模式。
然后输入英文 :wq! 保存退出

# 不熟悉命令行操作的同学，请自行研究

修改完 commit 信息后，我们再次通过git log命令来查看 commit 记录：

假定我们想修改的描述信息不是最后一次 commit 的 d.js ，而是 b.js ，那么，我们将会用到另一个命令 git rabase -i：

我们将 b.js 前的 pick 标识修改为 edit：

回车后我们发现分支已经不在 master 上了：

我们再次输入 git log 命令，可以看到，最近一次的 commit 已经变成了 b.js :

我们重复修改 d.js 的操作，之后根据命令行提示的信息，我们输入git rebase --continue命令：

我们再次打印 commit 记录,可以看到，b.js 成功被修改：

# 以上只是其中一种方法，其他方法请自行研究。

pull、push 与冲突

git pull 用于从远端仓库获取最新代码。
依旧用寄快递来类比，当我们将快递打包好并填好快递单后，在往寄存柜中存放之前，先要知道那些格子是被放过东西的，那些是还没有放东西的，我们的快递只能放在还没有放东西的格子中！

git pull 命令就可以看作是更新了最新的储物格信息。

假定，你想把快递放在第一排第一列，如果这个储物格是空的，自然可以放进去。可是，如果这个储物格已经放过了东西，你还想往里放，这样，就产生了冲突。git 中的冲突，大致也是这么个意思。

假定我们的同事小A，在和你协作开发，他也修改了 a.js 文件，然后提交了代码，这样在你进行 git push时，便会产生冲突。

# 左侧是我们正在编辑的 a.js ，右侧是 小A 的修改的 a.js

我们看到，两人在开发的时候都修改了相同位置的代码，然后小A开发完后，进行了提交：

然后我们再来提交自己的代码：

很明显，在代码中产生了冲突。这时，我们就要和小A来交流，来解决冲突。

和小A交流后，我们决定保留双方的代码，自己就删除了代码中那些奇奇怪怪的 hash ，重新进行了一次提交：

这样，一次简单的冲突就解决了。

当我们 push 完成后，远程仓库的代码已经再次发生了改变，小A突然想起来还有一个需求要修改，可是在修改前却忘记了更新本地代码，于是在完成修改之后，发现直接 push 时报了错：

控制台提示我们在 push 之前要先 pull ，我们按照提示输入 pull 命令：

控制台中又出现了那个我们熟悉的 commit 信息编辑界面：

我们保存退出后，重新 push ，就可以了。

注意的地方

以上，简单说了两个常见的冲突，当然在实际开发中，还会出现各种奇奇怪怪的问题。
在有问题时，我们不要慌（之前我会很慌，不知道该怎么办，瞬间手忙脚乱）应该多留意控制台信息，然后查找解决办法。
在提交代码前一定要先 pull ，把本地代码更新到最新，然后再 push , 这样做可以避免覆盖别人的代码。

分支与合并分支

在项目的开发中，常常会需要有多个分支。我们可以通过git branch命令来新建分支：

git branch        # 查看分支

git branch 分支名   # 新建分支

git checkout 分支名 # 切换分支

如图：

我们在 2018 分支上再做些修改，并提交代码：

通过 git log 我们看到，新提交的 2018 已经存在提交记录里了：

我们再切换到 master 分支，发现，信息为 2018 的提交记录并不存在，相应的改动当然也不存在：

这时我们就需要合并分支，把 2018 分支上的改动合并到 master 分支上，我们需要用到一个新的命令：git merge。

我们切换到 master 分支上，然后输入git merge，如图：

我们看到，在 2018 分支上的改动，已经出现在 master 分支上了。

最后

本文旨在梳理 git 使用的基本知识，对于一些命令的使用和描述并不全面，更多高级的用法，还望各位自行研究，这里不做赘述。
以上，如有描述不正确的地方，还望批评指正！