跟着实验楼的《Git实战教程》一步步学习，记录一下📝之前没注意的知识点！

概述

本节将讲解集中式和分布式版本控制系统的区别以及以下几个基本命令：

• git config：配置相关信息

• git clone：复制仓库

• git init：初始化仓库

• git add：添加更新内容到索引中

• git diff：比较内容

• git status：获取当前项目状况

• git commit：提交

• git branch：分支相关

• git checkout：切换分支

• git merge：合并分支

• git reset：恢复版本

• git log：查看日志

集中式和分布式版本控制系统

对于集中式版本控制系统，版本库是集中存放在中央服务器的，而大家工作的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始工作，工作完成，再把自己的修订推送给中央服务器。这类系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

Git基本指令

• 初始化Git仓库(仅创建时使用一次)：

  $ git init
  

• 查看当前Git仓库的状态：

  $ git status
  

• 检查缓存区哪些文件被修改了（没有加--cached会显示当前你所有已做的但没有加入到缓存区里的修改，按q退出）

  $ git diff --cached
  

• 将新建文件添加到缓存区（如果是git add . ,表示提交所有变化）

  $ git add file1 file2 file3
  

• 提交本地仓库（此时仍然是在本地）

  $ git commit -m “”
  

• 如果是修改文件，也需要使用 git add 命令添加到缓存区才可以提交。如果是删除文件，则直接使用 git rm 命令删除后会自动将已删除文件的信息添加到缓存区，git commit 提交后就会将本地仓库中的对应文件删除。

• 将本地仓库关联到远端服务器

  $ git remote add origin 你的仓库地址
  

• 将本地仓库同步到远端服务器

  $ git push origin master
  

分支与合并

Git 的分支可以让你在主线（master 分支）之外进行代码提交，同时又不会影响代码库主线。分支的作用体现在多人协作开发中，比如一个团队开发软件，你负责独立的一个功能需要一个月的时间来完成，你就可以创建一个分支，只把该功能的代码提交到这个分支，而其他同事仍然可以继续使用主线开发，你每天的提交不会对他们造成任何影响。当你完成功能后，测试通过再把你的功能分支合并到主线。

• 创建分支

  $ git branch 分支名
  

• 查看分支

  $ git branch
  

• 切换分支

  $ git checkout 分支名
  

  在分支上做的任何变化，回到master后都消失，只在对应分支里存在。

• 分支合并：两个分支有了各自不同的修改，分支的内容都已经不同，如何将多个分支进行合并呢？

  可以通过下面的 git merge 命令来合并 shaw 分支到主线分支 master：

  # 切换到master分支
  $ git checkout master
  # 将shaw分支合并到master
  $ git merge -m 'merge shaw branch' shaw
  

  由于两个 branch 修改了两个不同的文件，所以合并时不会有冲突，执行上面的命令后合并就完成了。如果有冲突，比如两个分支都改了一个文件 file3，则合并时会失败。首先我们在master分支上用vim修改file3 文件，删除代表冲突 ««« 等符号，在file3保留需要的内容，重新git add即可。

• 删除分支

  当我们完成合并后，不再需要shaw时，可以使用下面的命令删除：

  $ git branch -d shaw
  

  git branch -d只能删除那些已经被当前分支的合并的分支。如果你要强制删除某个分支的话就用git branch –D

• 撤销合并

  如果你觉得你合并后的状态是一团乱麻，想把当前的修改都放弃，你可以用下面的命令回到合并之前的状态：

  $ git reset --hard HEAD^
  # 查看file3的内容，已经恢复到合并前的master上的文件内容
  $ cat file3
  

• 快速向前合并

  还有一种需要特殊对待的情况，在前面没有提到。通常，一个合并会产生一个合并提交（commit）， 把两个父分支里的每一行内容都合并进来。但是，如果当前的分支和另一个分支没有内容上的差异，就是说当前分支的每一个提交（commit）都已经存在另一个分支里了，Git 就会执行一个 快速向前（fast forward）操作；Git 不创建任何新的提交（commit），只是将当前分支指向合并进来的分支。

Git日志

• 查看日志

  git log 命令可以显示所有的提交（commit）：

  $ git log
  

  如果提交的历史纪录很长，回车会逐步显示，输入 q 可以退出。

  git log 有很多选项，可以使用 git help log 查看，例如下面的命令就是找出所有从 “v2.5“ 开始在 fs 目录下的所有 Makefile 的修改（这个只是举例，不用操作）：

  $ git log v2.5.. Makefile fs/
  

  Git 会根据 git log 命令的参数，按时间顺序显示相关的提交（commit）

• 日志统计

  如果用 --stat 选项使用 git log，它会显示在每个提交（commit）中哪些文件被修改了， 这些文件分别添加或删除了多少行内容，这个命令相当于打印详细的提交记录：

  $ git log --stat
  

• 格式化日志

  你可以按你的要求来格式化日志输出。--pretty 参数可以使用若干表现格式，如 oneline：

  $ git log --pretty=oneline
  

  或者你也可以使用 short 格式：

  $ git log --pretty=short
  

  你也可用 medium，full，fuller，email 或 raw。 如果这些格式不完全符合你的需求， 你也可以用 --pretty=format 参数定义格式。

  --graph 选项可以可视化你的提交图（commit graph），会用ASCII字符来画出一个很漂亮的提交历史（commit his**tory）线：

  $ git log --graph --pretty=oneline
  

• 日志排序

  日志记录可以按不同的顺序来显示。如果你要指定一个特定的顺序，可以为 git log 命令添加顺序参数。

  按默认情况，提交会按逆时间顺序显示，可以指定 --topo-order 参数，让提交按拓扑顺序来显示（就是子提交在它们的父提交前显示）：

  $ git log --pretty=format:'%h : %s' --topo-order --graph
  

  你也可以用 --reverse 参数来逆向显示所有提交日志。

参考

[1] 实验楼Git实战教程