git使用教程（最详细、最傻瓜）

⽬录

1.git 简介1.1 产⽣历史1.2 git两⼤特点2.安装配置3.创建⼀个版本库4.版本的创建与回退4.1 使⽤4.2 ⼯作区和缓存区4.3 管理修改4.4 撤销修改4.5 对⽐⽂件的不同4.6 删除⽂件5. 分⽀管理5.1概念5.2 创建与合并分⽀5.3 解决冲突5.4 分⽀管理策略5.5 Bug分⽀6.使⽤github6.1 创建仓库6.2 添加ssh账户6.3 克隆项⽬6.4 上传分⽀/推送代码6.5 将本地分⽀跟踪服务器分⽀6.6 从远程分⽀上拉取代码7.⼯作使⽤git8.思维导图笔记1.git 简介

1.1 产⽣历史

git是⽬前世界上最先进的分布式版本控制系统。

Linus在1991年创建了开源的Linux,从此，Linux系统不断发展，已经成为最⼤的服务器系统软件了。Linus虽然创建了Linux,但Linux的壮⼤是靠全世界热⼼的志愿者参与的，这么多⼈在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？事实是，**在2002年以前，世界各地的志愿者把源代码⽂件通过diff的⽅式发给Linus,然后由Linus本⼈通过⼿⼯⽅式合并代码！你也许会想，为什么Linus不把Linux代码放到版本控制系统⾥呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢，⽽且必须联⽹才能使⽤。有⼀些商⽤的版本控制系统，虽然⽐CVS、SVN好⽤，但那是付费的，和Linux的开源精神不符。不过，到了2002年，Linux系统已经发展了⼗年了，代码库之⼤让Linus很难继续通过⼿⼯⽅式管理了，社区的弟兄们也对这种⽅式表达了强烈不满，于是Linus选择了⼀个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于⼈道主义精神，授权Linux社区免费使⽤这个版本控制系统。**安定团结的⼤好局⾯在2005年就被打破了，原因是Linux社区⽜⼈聚集，不免沾染了⼀些梁⼭好汉的江湖习⽓。开发Samba的Andrew试图破解BitKeeper的协议（这么⼲的其实也不只他⼀个）,被BitMover公司发现了（监控⼯作做得不错！),于是BitMover公司怒了，要收回Linux社区的免费使⽤权。Linus可以向BitMover公司道个歉，保证以后会严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：

Linus花了两周时间⾃⼰⽤C写了⼀个分布式版本控制系统，这就是Git!⼀个⽉之内，Linux系统的源码已经由Git管理了！⽜是怎么定义的呢？⼤家可以体会⼀下。Git迅速成为最流⾏的分布式版本控制系统，尤其是2008年，GitHub⽹站上线了，它为开源项⽬免费提供Git存储，⽆数开源项⽬开始迁移⾄GitHub,包括jQuery,PHP,Ruby等等。历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费⽽超级好⽤的Git了。

1.2 git两⼤特点

版本控制：可以解决多⼈同时开发的代码问题，也可以解决找回历史代码的问题。

分布式：Git是分布式版本控制系统，同⼀个Git仓库，可以分布到不同的机器上。⾸先找⼀台电脑充当服务器的⾓⾊，每天24⼩时开机，其他每个⼈都从这个“服务器“仓库克隆⼀份到⾃⼰的电脑上，并且各⾃把各⾃的提交推送到服务器仓库⾥，也从服务器仓库中拉取别⼈的提交。可以⾃已搭建这台服务器，也可以使⽤GitHub⽹站。

2.安装配置

⼀路点Next即可，安装位置就放在C盘。装好git后

在终端⾥⾯敲⼊git,

出现这样的画⾯就表⽰你的git装好了，此处应该有掌声~~

3.创建⼀个版本库

(1)新建⼀个⽬录git_test,在git_test⽬录下创建⼀个版本库，命令如下：

接着初始化仓库

说明：可以看到在git_test⽬录下创建了⼀个.git隐藏⽬录，这就是版本库⽬录。

4.版本的创建与回退

4.1 使⽤

(1)在git_test⽬录下创建⼀个⽂件code.txt,编辑内容如下：

(2)使⽤如下两条命令可以创建⼀个版本：

git add code.txt

git commit -m “版本1”

(3)使⽤如下命令可以查看版本记录：

git log

(4)继续编辑code.txt,在⾥⾯增加⼀⾏。

(5)使⽤如下命令再创建⼀个版本并查看版本记录：

(6)现在若想回到某⼀个版本，可以使⽤如下命令：

其中HEAD表⽰当前最新版本【请记死】，HEAD^表⽰当前版本的前⼀个版本，HEAD^^表⽰当前版本的前前个版本，也可以使⽤HEAD~1表⽰当前版本的前⼀个版本，HEAD~100表⽰当前版本的前100版本。

因为版本1的内容是1⾏：

this is the first line因为版本2的内容是2⾏：

this is the first linethis is the second line因为

$ git reset --hard HEAD^ HEAD is now at 51d36c7 版本1

使指针HEAD指向（倒退）到版本1，

因此打印的内容就是版本1的内容，即this is the first line

(7)假如我们现在⼜想回到版本2,这个时候怎么办？可以使⽤如下命令：

git reset --hard 版本号

（8）在终端执⾏如下命令：

版本2⼜回来了，内容也是原来的内容。接着玩

退出终端，再重进：

这个重进终端的操作让我们看不到版本2的版本号，要回到版本2怎么办？命令：git reflog来查看操作记录。

错误⽰例：

原因是按照当前版本1倒退的话，怎么也不会前进到版本2吧？逻辑错误。

正确实例：

要⽤到版本号。

查看版本2的内容：

不理解版本1，版本2有啥区别？

这个东西像游戏更新⼀样，版本2是在版本1的基础上添加新功能的，版本1内容不发⽣改变。例如王者荣耀版本更新，界⾯总会变化，但是英雄的属性（技能，名字）⼀般不会改变。

4.2 ⼯作区和缓存区

4.2.1 ⼯作区（WorkingDirectory)

⼯作区（WorkingDirectory) 电脑中的⽬录，⽐如我们的git_test,就是⼀个⼯作区。

4.2.2 版本库（Repository)

⼯作区有⼀个隐藏⽬录.git,这个不是⼯作区，⽽是git的版本库。git的版本库⾥存了很多东西，其中最重要的就是称为stage(或者叫index)的暂存区，还有git为我们⾃动创建的第⼀个分⽀master,以及指向master的⼀个指针叫HEAD。

因为我们创建git版本库时，git⾃动为我们创建了唯⼀⼀个master分 ⽀，所以，现在，git commit就是往master分⽀上提交更改。你可以简单理解为，需要提交的⽂件修改通通放到暂存区【计算机的缓存区】，然后，⼀次性提交暂存区的所有修改。

前⾯讲了我们把⽂件往版本库⾥添加的时候，是分两步执⾏的：

第⼀步是⽤git add把⽂件添加进去，实际上就是把⽂件修改添加到暂存区

第⼆步是⽤git commit提交更改，实际上就是把暂存区的所有内容提交到当前分⽀。(1)下⾯在git test⽬录下再创建⼀个⽂件code2.txt,然后编辑内容如下：

(2)然后编辑code.txt,操作如下：

注意的是创建⽂件和编辑⽂件都是在⼯作区⾥完成。（3）使⽤如下命令查看当前⼯作树的状态：

git status

翻译⼀下：

上⾯提⽰我们code.txt被修改，⽽code2.txt没有被跟踪。

(4)我们使⽤如下命令把code.txt和code2.txt加⼊到暂存区，然后再执⾏git status命令，结果如下：

注意：所有的 git add 命令是把所有提交的修改存放到暂存区。

(5)然后，执⾏git commit就可以⼀次性把暂存区的所有修改提交到分⽀并创建⼀个版本。

注意：指针HEAD永远指向当前版本。此时当前版本是版本3。

(6)⼀旦提交后，如果你⼜没有对⼯作区做任何修改，那么⼯作区就是“⼲净”的。执⾏如下命令可以发现：

现在我们的版本库变成了酱紫：

4.3 管理修改

git管理的⽂件的修改，它只会提交暂存区的修改来创建版本。(1)编辑code.txt,并使⽤git add命令将其添加到暂存区中。

(2)继续编辑code.txt,并在其中添加⼀⾏。

(3)git commit创建⼀个版本，并使⽤git status查看，发现第⼆次修改code.txt内容之后，并没有将其添加的⼯作区，所以创建版本的时候并没有被提交。

注意：对于code.txt⾥的四⾏内容，每⼀个版本对应⼀⾏，例如版本1对应first line，以此类推。

4.4 撤销修改

(1)继续上⾯的操作，提⽰我们可使⽤git checkout – <⽂件>来丢弃⼯作区的改动。执⾏如下命令，发现⼯作区⼲净了，第⼆次的改动内容也没了。

(2)我们继续编辑code.txt,并在其中添加如下内容，并将其添加的暂存区。

(3)git同样告诉我们，⽤命令git reset HEAD file可以把暂存区的修改撤销掉，重新放回⼯作区。

(4)现在若想丢弃code.txt的修改，执⾏如下命令即可。

现在，如果你不但改错了东西，还从暂存区提交到了版本库，则需要进⾏版本回退。

⼩结：

场景1:当你改乱了⼯作区某个⽂件的内容，想直接丢弃⼯作区的修改时，⽤ 命令git checkout – file场景2:当你不但改乱了⼯作区某个⽂件的内容，还添加到了暂存区时，想丢弃修改，分两步：第⼀步⽤命令git reset HEAD – file,就回到了场景1,第⼆步按场景1操作。

场景3:已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退⼀节。

4.5 对⽐⽂件的不同

对⽐⼯作区和某个版本中⽂件的不同：(1)继续编辑⽂件code.txt,在其中添加⼀⾏内容。

(2)现在要对⽐⼯作区中code.txt和HEAD版本中code.txt的不同。使⽤如下命令：

(3)使⽤如下命令丢弃⼯作区的改动。

对⽐两个版本间⽂件的不同：

(1)现在要对⽐HEAD和HEAD ^版本中code.txt的不同，使⽤如下命令：

反过来

4.6 删除⽂件

(1)我们把⽬录中的code2.txt删除。

这个时候，git知道删除了⽂件，因此，⼯作区和版本库就不⼀致了，git status命令会⽴刻提⽰哪些⽂件被删除了。

(2)现在你有两个选择，⼀种情况是确实要从版本库中删除该⽂件，那就⽤命令 gitrm删掉【永久删除，⽆法撤消】，并且 gitcommit:

另⼀种情况是删错了，可以直接使⽤git checkout – code2.txt,这样⽂件code2.txt⼜回来了。注意：两种情况有区别：

当执⾏第⼀种情况时【永久删除，⽆法撤消】，再执⾏第⼆种情况，会报错：

加长版：

简短版：

⼩结：

命令rm 删除是永久删除，要恢复数据的话可以恢复/扫描硬盘；

命令git rm⽤于删除⼀个⽂件。如果⼀个⽂件已经被提交到版本库，那么你永远不⽤担⼼误删，但是要⼩⼼，你只能恢复⽂件到最新版本，你会丢失最近⼀次提交后你修改的内容。

5. 分⽀管理

5.1概念

分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习Git的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习SVN。

如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了git⼜学会了SVN!

分⽀在实际中有什么⽤呢？

假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤风险。

现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作。

5.2 创建与合并分⽀

git把我们之前每次提交的版本串成⼀条时间线，这条时间线就是⼀个分⽀。截⽌到⽬前只有⼀条时间线，在git⾥，这个分⽀叫主分⽀，即master分⽀。HEAD严格来说不是指向提交，⽽是指向master,master才是指向提交的，所以，HEAD指向的就是当前分⽀。

(1)⼀开始的时候，master分⽀是⼀条线，git⽤master指向最新的提交，再⽤HEAD指向master,就能确定当前分⽀，以及当前分⽀的提交点：

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

(2)当我们创建新的分⽀，例如dev时，git新建了⼀个指针叫dev,指向master相同的提交，再把HEAD指向dev,就表⽰当前分⽀在dev上：

git创建⼀个分⽀很快，因为除了增加⼀个dev指针，改变HEAD的指向，⼯作区的⽂件都没有任何变化。

(3)不过，从现在开始，对⼯作区的修改和提交就是针对dev分⽀了，⽐如新提交⼀次后，dev指针往前移动⼀步，⽽master指针不变：

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

git合并分⽀也很快，就改改指针，⼯作区内容也不变。

（5）合并完分⽀后，甚⾄可以删除dev分⽀。删除dev分⽀就是把dev指针给删掉，删掉后，我们就剩下了⼀条master分⽀：

(1)执⾏如下命令可以查看当前有⼏个分⽀并且看到在哪个分⽀下⼯作。

(2)下⾯创建⼀个分⽀dev并切换到其上进⾏⼯作。

(3)下⾯我们修改code.txt内容，在⾥⾯添加⼀⾏，并进⾏提交。

(4)dev分⽀的⼯作完成，我们就可以切换回master分⽀：

查看code.txt,发现添加的内容没有了。因为那个提交是在dev分⽀上，⽽master分⽀此刻的提交点并没有变。【这⾥需要细细品味⼀下】

(5)现在，我们把dev分⽀的⼯作成果合并到master分⽀上：

git merge命令⽤于合并指定分⽀到当前分⽀。合并后，再查看code.txt的内容，就可以看到，和dev分⽀的最新提交是完全⼀样的。

注意到上⾯的rast-forward信息，Git告诉我们，这次合并是“快进模式“，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。

(6)合并完成后，就可以放⼼地删除dev分⽀了，删除后，查看branch,就只剩下master分⽀了。

⼩结：

查看分⽀：git branch

创建分⽀：git branch 切换分⽀：git checkout

创建+切换分⽀：git checkout -b

合并某分⽀到当前分⽀：git merge 删除分⽀：git branch -d

5.3 解决冲突

合并分⽀往往也不是⼀帆风顺的。(1)再创建⼀个新分⽀dev。

(2)修改code.txt内容，并进⾏提交。

(3)切换回master分⽀。

(4)在master的code.txt添加⼀⾏内容并进⾏提交。

这种情况下，git⽆法执⾏\"快速合并\"，只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突。(5)执⾏如下命令尝试将dev分⽀合并到master分⽀上来。

冲突原因：

现在，master分⽀和dev分⽀各⾃都分别有新的提交，并且编辑了同⼀个⽂件，变成了这样：

git告诉我们，code.txt⽂件存在冲突，必须⼿动解决冲突后再提交。

最重要的⼀步：

(6)git status也可以告诉我们冲突的⽂件：

(7)查看code.txt的内容。

(8)git⽤<<<<<<<<,========,>>>>>>>>标记不同分⽀的内容，我们修改如下后保存：

(9)再提交。

(10)现在，master分⽀和dev分⽀变成了下图所⽰：

(11)⽤带参数的git log也可以看到分⽀的合并情况：

(12)最后⼯作完成，可以删除dev分⽀：

5.4 分⽀管理策略

通常，合并分⽀时，如果可能，git会⽤fast forward模式，但是有些快速合并不能成功⽽且合并时没有冲突，这个时候git会帮我们在合并之后做⼀次新的提交，但这种模式下，删除分⽀后，会丢掉分⽀信息。【弹窗说明信息】(1)创建切换到dev分⽀下。

(2)新建⼀个⽂件code3.txt,编辑内容如下，并提交⼀个commit。

(3)切换回master分⽀，编辑code.txt并进⾏⼀个提交。

(4)合并dev分⽀的内容到master分⽀。

(5)出现如下提⽰时，这是因为这次不能进⾏快速合并，所以git提⽰输⼊合并说明信息，输⼊之后合并内容之后git会⾃动创建⼀次新的提交。

按 :x保存并退出。

(6)使⽤分⽀命令查看分⽀信息。

(7)删除dev分⽀。

如果要强制禁⽤fast forward模式，git就会在merge时⽣成⼀个新的commit,这样，从分⽀历史上就可以看出分⽀信息。(1)创建并切换到dev分⽀。

(2)修改code.txt内容，并提交⼀个commit。

(3)切换回master分⽀。

（4）准备合并dev分⽀，请注意–no-ff参数，表⽰禁⽤Fast forward:

因为本次合并要创建⼀个新的commit,所以加上-m参数，把commit描述写进去。

5.5 Bug分⽀

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

(1)当你接到⼀个修复⼀个代号001的bug的任务时，很⾃然地，你想创建⼀个分⽀bug-001来修复它，但是，等等，当前正在dev上进⾏的⼯作还没有提交：建议先敲clear清屏。

并不是你不想提交，⽽是⼯作只进⾏到⼀半，还没法提交，预计完成还需1天时间。但是，必须在两个⼩时内修复该bug,怎么办？(2)git还提供了⼀个stash功能，可以把当前⼯作现场“储藏“起来，等以后恢复现场后继续⼯作：

(3)⾸先确定要在哪个分⽀上修复bug,假定需要在master分⽀上修复，就从master创建临时分⽀：

(4)现在修复bug,这⾥假设把code.txt⾥的第9⾏删掉，然后提交。

(5)修复完成后，切换到master分⽀，并完成合并，最后删除bug-001分⽀。

(6)现在bug-001修复完成，是时候接着回到dev分⽀⼲活了！

(7)⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤git stash list命令看看：【帮助我们列出保存的⼯作现场】

⼯作现场还在，git把stash内容存在某个地⽅了，需要恢复⼀下：

⼩结：

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

当⼿头⼯作没有完成时，先把⼯作现场git stash⼀下，然后去修复bug,修复后，再git stash pop,恢复⼯作现场。

6.使⽤github

6.1 创建仓库

(1)注册github账户

登录后，点击\"New respository\"

(2)在新页⾯中，输⼊项⽬的名称【如2020】，勾选'readme.md',点击'Create repository'

这⾥完成。

6.2 添加ssh账户

(1)点击账户头像后的下拉三⾓，选择'settings'如果某台机器需要与github上的仓库交互，那么就要把这台机器的ssh公钥添加到这个github账户上。

(2)在git的命令⾏中，回到⽤户的主⽬录下，编辑⽂件.gitconfig,修改某台机器的git配置。修改为注册github时的邮箱，填写⽤户名。

完美：

6.3 克隆项⽬

接着：

6.4 上传分⽀/推送代码

(1)项⽬克隆到本地之后，执⾏如下命令创建分⽀：

(2)创建⼀个views.py并提交⼀个版本：

(3)推送前github上⽂件列表如下图:

(4)推送前github上分⽀列表如下图:

(5)推送分⽀，就是把该分⽀上的所有本地提交推送到远程库，推送时要指定本地分⽀，这样，git就会把该分⽀推送到远程库对应的远程分⽀上：

git push origin 分⽀名称

例：

git push origin smart

（6）再次查看github分⽀：接下来操作重新加载页⾯：

点击smart,再点击views.py,如图所⽰：

6.5 将本地分⽀跟踪服务器分⽀

git branch --set-upstream-to=origin/远程分⽀名称 本地分⽀名称

例：

git branch --set-upstream-to=origin/smart smart

6.6 从远程分⽀上拉取代码

git pull orgin 分⽀名称

例：

git pull orgin smart

使⽤上述命令会把远程分⽀smart上的代码下载并合并到本地所在分⽀。

7.⼯作使⽤git

项⽬经理：

(1)项⽬经理搭建项⽬的框架。

(2)搭建完项⽬框架之后，项⽬经理把项⽬框架代码放到服务器。

普通员⼯：

(1)在⾃⼰的电脑上，⽣成ssh公钥，然后把公钥给项⽬经理，项⽬经理把它添加的服务器上⾯。(2)项⽬经理会给每个组员的项⽬代码的地址，组员把代码下载到⾃⼰的电脑上。(3)创建本地的分⽀dev,在dev分⽀中进⾏每天的开发。

(4)每⼀个员⼯开发完⾃⼰的代码之后，都需要将代码发布远程的dev分⽀上。项⽬⾥⼀般会有两个分⽀，如：Master:⽤于保存发布的项⽬代码。

Dev:⽤于保存开发过程中的代码。所有的组员开发完⾃⼰的代码提交到该分⽀上。

到此，git使⽤教程就写完了，既是⾃⼰的实践记录【记不住哈哈】，也能帮助更多的道友管理控制代码，如果内容对读者有⽤，请关注我，为思考点赞！最后奉上导图笔记：

8.思维导图笔记

到此这篇关于git使⽤教程(最详细、最傻⽠)的⽂章就介绍到这了,更多相关git使⽤教程内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！