快速搞定Git（图文详情）

啥是GIt?简单的讲就是版本控制，至于具体是啥玩意及其优缺点联系度娘哈，这里就不多概述。本文目标：一文带你掌握Git绝技。

0 安装Git

官网链接：https://git-scm.com/

下载得到一个：Git-2.28.0-64-bit.exe文件，点击安装就行。
安装成功后，在开始菜单中会有Git新增项，或者点击鼠标右键，也能看到Git新增快捷项，后面我们主要使用Git Bash;

一切就绪，接下来练习此功。

1 创建/修改 版本库

1.1 创建版本库 (init)

俗话是，欲练此功，必先…那个建文件夹gitfolder（文件夹名称，也就是你的仓库名称）。进行你的刚建的文件夹，右键点击Git Bash Here

开始输入Git相关命令：
为了更好地使用 git, 同时也记录每一个施加修改的人. 这样人和修改能够对应上. 所以在 git 中添加用户名 user.namegit config --global user.name "Hiera DI" 和 用户email user.emailgit config --global user.email "hiera@email.com"，最后执行git init初始化了一个空的 git 管理库

接下来，我们就能在这个文件夹中建立 git 的管理文件了

1.2 添加文件管理 (add)

新建一个文件（1.py），可以手动创建，也可以使用下面第一个命令创建touch 1.py，通过git status查看当前版本库的状态

可以看到：当前 1.py 并没有被放入版本库中 (unstaged), 要使用 add 把它添加进版本库 (staged)
使用git add 1.py暂存到版本库（如果想一次性添加文件夹中所有未被添加的文件, 可以使用这个git add .），git status再次查看状态 status
从输出可以看出，版本库已识别 1.py (staged)。

我们已经添加好了1.py文件,最后一步就是提交这次的改变, 并在-m自定义这次改变的信息git commit -m "create 1.py"

以上，我们就完成了新增文件，并把新增的文件记录到仓库版本管理；
接下来，查看日志git log，可看到我们最近的提交记录

1.3 记录修改 (log & diff)

查看log
我么对文件1.py进行修改，添加：a=1，保存，再次使用git status查看状态

我们使用git add .暂存修改后的文件，然后提交此次修改git commit -m 'change 1'，最后查看下提交日志git log

查看修改diff
如果我们修改了文件，但是想看看都做了哪些修改，怎么办？
接下来我们尝试修改1.py内容，比如把 a = 1 改成 a = 2, 再添加一个 b = 1

分别查看 unstaged和staged状态下前后文件的差异

我们先使用git status查看状态，提示有个修改文件1.py

① 如果想要查看这次还没 add (unstaged) 的修改部分 和上个已经 commit 的文件有何不同, 我们将使用 git diff

② 如果已经 add 了这次修改, 文件变成了 “可提交状态” (staged), 我们可以在 diff 中添加参数 --cached 来查看修改git diff --cached

结果是一致的，只是不同状态下的查询命令不同而已。

还有种方法可以查看 add 过 (staged) 和 没 add (unstaged) 的修改
比如再修改一下 1.py 但不 add

目前 a = 2 和 b = 1 已被 add, c = b 是新的修改, 还没被 add.
对比三种不同 diff 形式

依次执行git add . 和 git commit -m "change 2"全部 add 变成 staged 状态, 并 commit.

2 回到从前

2.1 使用reset回到从前

有时候我们总会忘了什么，比如已经提交了 commit 却发现在这个 commit 中忘了附上另一个文件。
接着上述操作，我们最后一个 commit 是 change 2，我们将要添加另外一个文件，将这个修改也 commit 进 change 2。
①我们复制 1.py 这个文件， 改名为 2.py。
②把 2.py 变成 staged，执行git add 2.py
③然后使用 --amend 将这次改变合并到之前的 change 2 中，具体命令git commit --amend --no-edit（"–no-edit": 不编辑, 直接合并到上一个 commit）。

其中git log --oneline是git log的精简版，每个 commit 内容显示在一行。

reset 回到 add 之前
有时我们添加 add 了修改，但是又后悔，并想补充一些内容再 add。 这时，我们有一种方式可以回到 add 之前，比如在 1.py 文件中添加这一行：d = 3，然后 add 去 staged 再返回到 add 之前

reset 回到 commit 之前
穿梭到过去的 commit，每个 commit 都有自己的 id 数字号，HEAD 是一个指针，指引当前的状态是在哪个commit。我们如果要回到过去，就是让 HEAD 回到过去并 reset 此时的 HEAD 到过去的位置。
①git reset --hard HEAD不管我们之前有没有做了一些 add 工作, 这一步让我们回到 上一次的 commit

②有两种命令可以回到 24226cd change 1分别是：git reset --hard HEAD^（^表示再往上一次）和直接通过commit id回退 git reset --hard 24226cd

如果想回到前三次提交git reset --hard HEAD~3等价于git reset --hard HEAD^^^

回退后，如何返回
怎么 change 2 消失了!!! 还有办法挽救消失的 change 2 吗?
git reflog 里面最近做的所有 HEAD 的改动, 并选择想要挽救的 commit id。重复 reset 步骤就能回到指定的commit idgit reset --hard 7eadca2，然后就会发现我们又再次奇迹般的回到了 change 2。

2.2 使用checkout 针对单个文件回到从前

checkout 让文件回到过去
把某个文件回到历史某个提交，如把1.py回到change 1状态git checkout 24226cd -- 1.py

3 分支管理

3.1 分支 (branch)

使用 branch 创建和删除 dev 分支

$ git branch dev       # 建立 dev 分支
$ git branch -d dev    # 删除 dev 分支

使用 checkout 创建 dev 分支

$ git checkout dev      # 建立 dev 分支
$ git checkout -b dev   # 建立分支同时head切换到新分支

合并分支

将 dev merge 到 master 中git merge dev
如果直接 git merge dev，git 会采用默认的 Fast forward 格式进行 merge，这样 merge 的这次操作不会有 commit 信息。log 中也不会有分支的图案。我们可以采取 --no-ff 这种方式保留 merge 的 commit 信息。

$ git merge --no-ff -m "keep merge info" dev  # 保留 merge 信息

使用git log --oneline --graph查看日志（带有分支图案）

3.2 merge 分支冲突

不同分支情况下，对统一文件进行修改，分支合并时候，会有冲突。
如：master 中的 1.py 加上 # edited in master，dev 中的 1.py 加上 # edited in dev。

$ git merge dev

# 输出
Auto-merging 1.py
CONFLICT (content): Merge conflict in 1.py
Automatic merge failed; fix conflicts and then commit the result.

在 1.py 中手动合并一下两者的不同就 OK 啦。我们将当前 HEAD (也就是master) 中的描述 和 dev 中的描述合并一下。然后再 commit 现在的文件，冲突就解决啦。

git commit -am "solve conflict"

# 再来看看 master 的 log:
$ git log --oneline --graph

# 输出
*   7810065 solve conflict
|\  
| * f7d2e3a change 3 in dev
* | 3d7796e change 4 in master
|/  
* 47f167e back to change 1 and add comment for 1.py
* 904e1ba change 2
* c6762a1 change 1

3.3 rebase 分支冲突

更高级的合并方式 rebase（重新基于分支）
假设共享的 branch 是master（主分支），假设我在 dev 上工作，有一天我发现master已经有一些小更新，我也想试试我的程序和这些小更新兼不兼容，我也我想合并，这时就可以用 rebase 来补充我的分支 master 的内容

$ git rebase dev 

# 输出
First, rewinding head to replay your work on top of it...
Applying: change 3 in dev
Using index info to reconstruct a base tree...
M	1.py
Falling back to patching base and 3-way merge...
Auto-merging 1.py
CONFLICT (content): Merge conflict in 1.py
error: Failed to merge in the changes.
Patch failed at 0001 change 3 in dev
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

$ git branch
* (no branch, rebasing master) # HEAD 在这
  dev
  master

这时 HEAD 并没有指向 master 或者 dev, 而是停在了 rebase 模式上；
打开 1.py, 手动合并一下两者的不同
执行 git add 和 git rebase --continue 就完成了 rebase

$ git add 1.py
$ git rebase --continue
$ git log --oneline --graph

# 输出
* c844cb1 change 4 in master    # 这条 commit 原本的id=3d7796e, 所以 master 的历史被修改
* f7d2e3a change 3 in dev       # rebase 过来的 dev commit
* 47f167e back to change 1 and add comment for 1.py
* 904e1ba change 2
* c6762a1 change 1
 #!! 注意 !! 这个例子也说明了使用 rebase 要万分小心, 千万不要在共享的 branch 中 rebase, 不然就像上面那样, 现在 master 的历史已经被 rebase 改变了. master 当中别人提交的 change 4 就被你无情地修改掉了, 所以在共享分支中使用 rebase要当心.

3.4 临时修改 (stash)

暂存修改
假设我们现在在 dev 分支上快乐地改代码git checkout dev在 dev 中的 1.py 中加上一行 # feel happy，然后老板的电话来了, 可是我还没有改进完这些代码，所以我就用 stash 将这些改变暂时放一边。

$ git status -s
# 输出
 M 1.py
------------------ 

$ git stash
# 输出
Saved working directory and index state WIP on dev: f7d2e3a change 3 in dev
HEAD is now at f7d2e3a change 3 in dev
-------------------

$ git status
# 输出
On branch dev
nothing to commit, working directory clean  # 干净得很

做其它任务

$ git checkout -b boss
#Switched to a new branch 'boss' # 创建并切换到 boss
#然后苦逼地完成着老板的任务, 比如添加 # lovely boss 去 1.py. 然后 commit, 完成老板的任务.
$ git commit -am "job from boss"
$ git checkout master
$ git merge --no-ff -m "merged boss job" boss
# merge 如果有冲突的话, 可以像上次那样 解决.打开冲突文件修改和提交
$ git commit -am "solve conflict"
$ git log --oneline --graph
*   1536bea solve conflict
|\  
| * 27ba884 job from boss
* | 2d1961f change 4 in master
|/  
* f7d2e3a change 3 in dev
* 47f167e back to change 1 and add comment for 1.py
* 904e1ba change 2

恢复暂存

#轻松了, 现在可以继续开心的在 dev 上刷代码了.
$ git checkout dev
$ git stash list    # 查看在 stash 中的缓存

# 输出
stash@{0}: WIP on dev: f7d2e3a change 3 in dev
# 上面说明在 dev 中, 我们的确有 stash 的工作. 现在可以通过 pop 来提取这个并继续工作了.

$ git stash pop

# 输出
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   1.py

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (23332b7edc105a579b09b127336240a45756a91c)
----------------------

$ git status -s
# 输出
 M 1.py     # 和最开始一样了

4 Github

4.1 Github 在线代码管理

本地仓库推到远程仓库
首先，建立 github 版本库，获得github链接地址
通过下面命令，使本地版本库和远程仓库建立连接

$ git remote add origin https://github.com/XXXX/git-demo.git

$ git push -u origin master     # 推送本地 master 去 origin
$ git push -u origin dev        # 推送本地 dev  去 origin

# 推送修改
$ git commit -am "change 5"
$ git push -u origin master