Git学习笔记

git学习

目前世界上最先进的分布式版本控制系统，进行版本控制和协同开发

1.git的诞生

Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git。

2.分布式管理系统

不需要联网，每个人都可以在本地进行开发和版本控制，再通过推送给别人进行合作开发。

而集中式管理系统如果中央服务器出故障，则无法使用，并且必须要联网进行开发。

3.安装git

直接搜索git，找到对应的系统进行安装。

安装之后需要做一些设置：

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

4.创建版本库

什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

1、创建一个版本库非常简单，首先，选择一个合适的地方，创建一个空目录（如果可以尽量避免中中文命名）：

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

2、通过git init命令把这个目录变为git可以管理的仓库：

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

也不一定必须在空目录下创建Git仓库，选择一个已经有东西的目录也是可以的。不过，不建议你使用自己正在开发的公司项目来学习Git，否则造成的一切后果概不负责。

3、添加文件

git add xxx.txt
git commit -m "add file xxx.txt"

小结：

初始化一个Git仓库，使用git init命令。

添加文件到Git仓库，分两步：

1. 使用命令git add <file>，注意，可反复多次使用，添加多个文件；
2. 使用命令git commit -m <message>，完成。

5.版本管理——时光穿梭

5.1 查看工作区状态

• 要随时掌握工作区的状态，使用git status命令。
• 如果git status告诉你有文件被修改过，用git diff可以查看修改内容。

关于git diff的输出信息格式，可以参考：https://www.cnblogs.com/Vayne-N/p/9086103.html

5.2 版本回退

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

5.3 工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

• 工作区（Working Directory）

  创建的文件目录

• 版本库（Repository）

  工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

  Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

  

  分支和HEAD的概念我们以后再讲。

  前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

  第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

  第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

  因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

  可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

5.4 管理修改

下面，我们要讨论的就是，为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。

什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。

每次修改工作区的文件之后，如果不使用git add到暂存区，使用commit就不会把这样的修改加入到仓库中。

5.5 撤销修改

5.5.1 撤销工作区的修改

两种方式：

1. git restore readme.txt
2. git checkout -- readme.txt

命令git restore readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

注意：git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

5.5.2 撤销暂存区的修改

两种方式：

1. git restore --staged file
2. git reset HEAD file

用命令git restore --staged file可以把暂存区的修改撤销掉（unstage）

5.5.3 小结

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令``git restore `。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git restore --staged <file>，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

更新到git 2.23版本之后，可以减少checkout的职责：

• git restore <file>代替git checkout -- <file>

• git restore --staged <file>代替git reset HEAD <file>

5.6 删除文件

删除工作区（目录）下的文件，然后使用git add或者git rm将修改放入暂存区，再执行git commit提交，即可修改到仓库。

6.远程仓库

如果只是在一个仓库里管理文件历史，Git和SVN（集中式版本管理）真没啥区别。本章开始介绍Git的杀手级功能之一：远程仓库。

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。

搭建一台运行Git的服务器，或者直接使用Github作为远程仓库，这样的服务器起到集中管理的功能。

使用远程仓库准备工作：

1. 注册gitee账号，创建仓库
2. 使用ssh-keygen -t rsa -C "xxxx"生成本机的ssh公钥和私钥
3. 将公钥添加到gitee中

远程仓库的一些命令：

# 查看远程关联信息
git remote -v
# 删除远程关联
git remote rm origin
# 关联远程仓库
git remote add origin https://gitee.com/xxxx/xxxxx.git
# 第一次向远程仓库传送
git push -u origin master
# 之后每次向远程仓库传送
git push origin master

7.分支管理

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

7.1 创建和合并分支

在版本回退那里，我们已经知道，每次提交，git都会把提交记录串成时间线，这条时间线就是一个分支。到目前为止，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

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

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

分支相关的命令：

# 查看分支
git branch

# 创建分支
git branch <name>

# 切换分支
git checkout <name>
git switch <name>

# 创建+切换分支：
git checkout -b <name>
git switch -c <name>

# 删除分支
git branch -d <name>

# 合并分支 假设存在master dev分支
# 1.切换到要保留的分支
git check master
# 2.合并分支dev
git merge dev

7.2 解决冲突

当两个分支对同一个文件在同一个地方修改发生了冲突，无法直接使用git merge进行合并了。

这时，需要自己先解决冲突，然后再提交文件。

最后可以使用git log --graph查看分支的合并情况。

7.3 分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

如果要保留分支信息，可以使用：

git merge --no-ff -m "merge with no-ff" dev

该命令合并之后的分支记录会像这样：

7.3.1 分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

7.3.2 小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

7.4 Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

参考链接：https://www.liaoxuefeng.com/wiki/896043488029600/900388704535136

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

7.5 Feature分支

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

7.6 多人协作

7.6.1 需要远程同步的分支

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；
• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

7.6.2 抓取分支

多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

7.6.3 小结

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

7.7 Rebase

Rebase也是一种合并的方式，会使得提交历史成为一条直线，但是会破坏原本的时间线，详细的分析可以参考：

https://blog.csdn.net/liuxiaoheng1992/article/details/79108233

8.标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

标签操作

• 命令git tag <tagname> <commit id>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
• 命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
• 命令git tag可以查看所有标签。
• 命令git show可以查看标签信息
• 命令git tag -d <tagname>删除标签
• 命令git push origin <tagname>推送标签到远程
• 命令git push origin --tags推送所有未推送的标签到远程
• 已推送到远程的标签删除要麻烦一些，需要先从本地删除git tag -d <tagname>再从远程删除git push origin :refs/tags/<tagname>

9.github和gitee的使用

9.1 github使用

• 在GitHub上，可以任意Fork开源仓库；
• 自己拥有Fork后的仓库的读写权限；
• 可以推送pull request给官方仓库来贡献代码。

9.2 gitee使用

使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况（原因你懂的）。

如果我们希望体验Git飞一般的速度，可以使用国内的Git托管服务——Gitee（gitee.com）。

和GitHub相比，Gitee也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，Gitee还提供了项目管理、代码托管、文档管理的服务，5人以下小团队免费。

完结

最后，符上git官方文档的链接，遇到一些问题可以当作手册查看：https://git-scm.com/book/zh/v2

另外，有一份git常用命令的小抄，可以打印出来经常看：https://liaoxuefeng.gitee.io/resource.liaoxuefeng.com/git/git-cheat-sheet.pdf