【闲谈】git

怎么回事

某天下午，在拉取公司代码进行查看时，不小心自己在本地建了个dev分支，本着多一事不如少一事的原则，想把本地的分支删掉，但众所周知下午本就是迷迷糊糊的时间，点完delete后发现，公司git上的分支呢！吓得我赶紧和带我的老哥坦白，于是有了他对我如下的评价

就在我笑嘻嘻道歉的下一秒，部门老大冲进办公室就是一顿喊：谁tm干的

说来也是惭愧，在我两个月的开发经历中，只会clone、pull、push，之前在的公司是个小作坊，所有人的代码都往master上提交，而且事先分工明确，很少需要去手动合并代码，导致我到现在也是一问三不知

废话也不多说了，赶紧补一下git的基本知识

集中式vs分布式

集中式版本控制系统，版本库是集中存放在中央服务器的，这样就有个显而易见的问题：如果中央服务器挂了，大家今天都不用干活了（好耶）。但不干活肯定是不行的，毕竟要吃饭的嘛，所以现在用的git是分布式版本控制系统

所谓分布式就是根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，今天A哥电脑坏了，没关系，我从B哥那拷一份不就好了，这样就解决了集中式的弊端（当然了，这只是git的好处之一，其他让我们欲罢不能的优点放到后面再说）

git！

安装

（因为好多开发环境都是在Win上，这里就以Win为例）

在Windows上安装git很简单，只需去官网下载安装包一直下一步就好了。等安装结束后，随便找个地方右键就会发现出现Git GUI Here和Git Bash Here，前者代表了图形化界面，后者则是命令行

其实在很多工作环境中，做到这一步已经足够使用了，但最好还是完成以下的操作

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

创建版本库

所谓版本库就是仓库（repository），除了git的仓库还有我们熟知的maven仓库（跑题了）。其实版本库就是一个目录，只不过这个目录中所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”

创建版本库十分简单，尽管许多教程采用了命令行的方式进入目录并进行创建，但实际上都是动鼠标点点（至少我是这样的）。进入你想创建版本库的文件夹后，右键找到Git Bash Here，打开以后就进入了git的命令行模式，输入git init 就可以在当前目录下创建版本库了。这里需要注意的是，当你创建完版本库后，当前目录下会多出一个.git的目录，这个是git用来追踪管理版本库的，有事没事千万别动它

不建议使用公司项目用来练习git！

把文件添加到版本库

将文件添加到版本库的前置条件是文件在版本库的目录下

然后就是

$ git add readme.txt
$ git commit -m "wrote a readme file"

前者是告诉git要将文件添加到仓库中，后者则是把文件提交到仓库。git commit命令的-m选项输入的是本次提交的内容，当然可以选择不输入，但git诞生的初衷就是对版本进行控制，为了团队间关系和睦，最好还是把信息加上，就像代码需要注释一样（笑）

千万不要用记事本去编辑git仓库下的任何文件，原因的话可以点击这里去参考，取而代之的，可以选择VScode或是notepad++

实时关注你的仓库状态

git status可以让我们实时查看文件的修改状态，git diff是查看difference的，可以观察到文件上次怎么被修改的

版本回退

耍过游戏机的小伙伴都知道一个刷装备的技巧，就是save-load大法，每次在刷装备前先save保存一下，刷出的装备如果不合心意，就直接load之前的存档。git当中也是一样的，每当你绝对文件修改到一定程度时，就可以为文件创建一个“快照”，也就是commit，一旦文件乱了或是误删了，就可以直接从最近的一个commit恢复

然而在实际的开发中，我们不可能精准的记住每次更新的内容都有哪些，git贴心的为我们提供了一个命令用来解决这个问题

git log可以由最近到最远的提交记录，如果输出信息比较繁琐，可以通过--pretty=oneline选项进行格式化输出

既然要回退，肯定要知道当前版本，也要知道回退到哪个版本。在git中，HEAD表示当前版本，上一个版本则是HEAD^，上上个版本则是HEAD^^，这么一想，坏了，上一百个版本咋整，安啦，可以用HEAD~100表示。所以回退到上一个版本的命令就是

$ git reset --hard HEAD^

在这个基础上还可以回退再上一个版本，但是先别着急，我们先用git log查看版本库状态

回退之前

$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append B
e475afc93c209a690c39c13a46716e8fa000c366 add A
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

回退之后

e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master) add A
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

会发现我们之前最新的那个版本已经看不见了！回退版本我们知道用什么命令，找回被回退的版本就要借助commit id了，即那一串字符

$ git reset --hard 1094adb7b9b3807259d8cb349e7df1d4d6477073

版本号没必要写全，但是也有可能git无法根据你给的前缀找到唯一的版本号，那就出事了，所以还是建议复制粘贴一下

当然了，也可能出现你在回退后不小心把窗口关闭了，找不到版本号是多少。但git总是会留有后路的，可以通过git reflog查询已经执行过的命令

工作区和暂存区

还记得在最一开始说的git add和git commit吗？因为博大精深的中文，“添加”和“提交”两个词似乎没什么区别，但是在git中这两个动作截然不同，现在就引入暂存区和工作区的概念来彻底立即什么是add什么是commit

其实说来也比较抽象，工作区是我们实际能看得见的文件目录，但是暂存区和分支更像是逻辑上的概念

工作区有隐藏目录.git，它不算工作区，而是版本库，版本库里就有暂存区，以及git自动创建的分支master，以及指向master的指针HEAD。可以简单的理解为“需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改”

当在版本库新建文件，且不对其进行add操作时，执行git status，会发现这个新建的文件状态为Untracked，代表这个文件并不受git的版本控制

管理修改

之前我们讨论的都是文件的修改，注意措辞，文件的修改，说明我们始终讨论的都是修改，而非文件，这也是在学习git时需要明确的概念：git管理的是修改，而非文件

这个结论可以通过一个小实验来证明

先对readme.txt做修改

然后添加并查看状态（Changes to be committed）

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   readme.txt
#

再对readme.txt做修改

然后提交并查看状态（Changes not staged for commit）

$ git commit -m "git tracks changes"
[master 519219b] git tracks changes
 1 file changed, 1 insertion(+)
$ git status
On branch master
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:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

会发现第二次修改并没有被提交（Changes not staged for commit）

我们来分析一下整个流程的思路：第一次修改 -> git add -> 第二次修改 -> git commit

根据我们之前说的暂存区的概念，add之后，第一次修改进入了暂存区准备提交，但是第二次修改过后直接commit，在其修改的内容并没进暂存区的前提下进行了提交，提交的内容只有暂存区中的内容，所以第二次修改并不会被提交

所以结局方式是：第一次修改 -> git add -> 第二次修改-> git add -> git commit

结论：没有被add的修改不会被commit

以上实验结果来自廖雪峰git专题中内容，我在本地测试的时候发现git不进行add也可以直接commit，版本为2.13.0.windows.1，目前还没有查到让我满意的解释方式，如果哪位老哥有知道的，可以给我留言，感谢！（跪了）

撤销修改

可以通过git check out -- <file>对已有的修改进行撤销，但是分情况

• 文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态
• 文件已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态

总之就是让文件回到最近一次git add或git commit状态

除此之外，如果修改过的文件添加到暂存区，可以用命令git reset HEAD <file>把暂存区的修改撤销掉，重新放回工作区，而工作区的修改直接用git check out -- <file>进行撤销了

删除

如果是在公司的项目中，这块我觉得还是不学为妙，毕竟会的越多，删的越多（笑）

但还是简单了解一下

当你删除某个文件后，无非就是两种情况

• 确实需要删
  • git rm <file>删除掉
  • git commit <file>
• 删错了！
  • git checkout -- <file>这个命令其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”

你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容
从来没有被添加到版本库就被删除的文件，是无法恢复的！

分支管理

从这一块开始，是我认为比较重要的部分了，毕竟正常公司并不会让所有人在开发阶段所有代码都往master上提交，都会有相应的dev、test分支

创建于合并分支

每次提交，git会把它们串成一条时间线，这条时间线就是一个分支。如果不去人为创建，默认只有一条分支，就是master分支。严格来说，HEAD并不指向提交，而是指向master，master才指向提交

当创建新的分支，比如dev分支的时候，git就新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上

从现在开始，操作的分支就不再是master而是dev了

当在dev上操作完成后，需要进行合并也很简单，就是让master指向dev

甚至可以删除分支（血泪的教训），就是把dev指针删除掉

$ git checkout -b dev

通过-b选项可以在创建新的分支时切换到上面，checkout -b等同于以下两个命令

$ git branch dev
$ git checkout dev

可以通过git branch查看当前所在的分支，前面带星号的代表当前所在的分支

$ git branch
* dev
  master

当一项工作进行完成，就可以将dev分支上的内容合并到master分支

$ git checkout master
$ git merge dev

这个命令的作用是将指定分支合并到当前分支

switch（建议使用）

在之前的操作中可以发现，切换分支命令git checkout <branch>与撤销修改命令git checkout -- <file>几乎一毛一样，为了能让二者的区别更加清晰，git推荐使用switch命令进行分支的切换

创建和切换到dev分支可以像这样

$ git switch -c dev

切换到master分支可以这样

$ git switch master

解决冲突

现在创建新的分支并对readme.txt做修改并进行提交

$ git switch -c feature1
Switched to a new branch 'feature1'

修改文档最后一行为
Creating a new branch is quick AND simple.

$ git add readme.txt

$ git commit -m "AND simple"
[feature1 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

然后切换回master分支也对文档的最后一行进行修改，最后进行提交

$ git switch master
Switched to branch 'master'

修改文档的最后一行为
Creating a new branch is quick & simple.

$ git add readme.txt 
$ git commit -m "& simple"
[master 5dc6824] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

然后现在试着进行合并，因为我们现在的状态如图所示，git的“快速合并”可能就没那么好使了

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

果然，提示Automatic merge failed，既然自动的合并不能成功进行，只能进行手动操作了，先看一下文档变成了什么样

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

git用<<<<<<<和>>>>>>>标记出了文档中冲突的位置，只需要根据实际情况对冲突的部分进行修改保留其一就可以了

再次提交

$ git add readme.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

现在的情况就变成了这样

分支管理策略

如果直接使用git提供的fast forward模式，在合并的时候会直接删除分支，这一点是不希望看到的。如果强制禁用fast forward模式，git会在merge时生成一个新的commit

使用--no-ff进行分支合并

$ git switch -c dev
Switched to a new branch 'dev'

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)

$ git switch master
Switched to branch 'master'

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

当不使用fast forward模式时，merge后分支状态如下所示

在实际开发过程中，分支管理策略大概就像这样

• master分支应当是非常稳定的，其作用为发布新版本，一般不直接把代码提交上去
• dev分支是不稳定的，当需要发布新版本时，会将dev分支上的内容合并到master分支上
• 每个人都有自己的分支，时不时将代码提交到dev分支上就行

最后说一句

在实际开发过程中，因为大多是团队项目，代码发生冲突的概率有那么一些的大，所以每次在提交代码之前，最好先把代码拉取下来，确认没有发生冲突后再去提交，提交的时候看清楚提交到哪个分支上就好了

可能关于git还有些我没那么了解或者没遇到的问题，后期如果出现了也会在这篇博客更新

最后再再提醒一句

在公司的项目中，无论是什么，只要涉及到delete的操作一定要万分小心，不管是不是在测试环境或者开发环境

本文内容参考
git教程