大家好，我是讯享网，很高兴认识大家。



 <div id="navCategory"></div> 

讯享网

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了。

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

分布式：Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。首先找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器“仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。可以自已搭建这台服务器，也可以使用GitHub网站。

讯享网

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

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

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

this is the first line

因为

使指针HEAD指向（倒退）到版本1，
因此打印的内容就是版本1的内容，即this is the first line

版本2又回来了，内容也是原来的内容。

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

正确实例：
要用到版本号。

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

4.2.1 工作区（WorkingDirectory)

4.2.2 版本库（Repository)

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

前面讲了我们把文件往版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

上面提示我们code.txt被修改，而code2.txt没有被跟踪。

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

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

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

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

小结：
场景1:当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用 命令git checkout – file
场景2:当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步：
第一步用命令git reset HEAD – file,就回到了场景1,
第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节。

对比工作区和某个版本中文件的不同：

对比两个版本间文件的不同：
(1)现在要对比HEAD和HEAD ^版本中code.txt的不同，使用如下命令：

反过来

(2)现在你有两个选择，一种情况是确实要从版本库中删除该文件，那就用命令 gitrm删掉【永久删除，无法撤消】，并且 git

另一种情况是删错了，可以直接使用git checkout – code2.txt,这样文件code2.txt又回来了。
注意：两种情况有区别：
当执行第一种情况时【永久删除，无法撤消】，再执行第二种情况，会报错：

小结：
命令rm 删除是永久删除，要恢复数据的话可以恢复/扫描硬盘；
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了git又学会了SVN!

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

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

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

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

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

小结：
查看分支：
创建分支：
切换分支：
创建+切换分支：
合并某分支到当前分支：
删除分支：

这种情况下，git无法执行"快速合并"，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

(5)执行如下命令尝试将dev分支合并到master分支上来。

冲突原因：
现在，master分支和dev分支各自都分别有新的提交，并且编辑了同一个文件，变成了这样：

通常，合并分支时，如果可能，git会用模式，但是有些快速合并不能成功而且合并时没有冲突，这个时候git会帮我们在合并之后做一次新的提交，但这种模式下，删除分支后，会丢掉分支信息。【弹窗说明信息】

按 保存并退出。

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

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug,怎么办？

小结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场一下，然后去修复bug,修复后，再,恢复工作现场。

这里完成。

(2)在git的命令行中，回到用户的主目录下，编辑文件,修改某台机器的git配置。
修改为注册github时的邮箱，填写用户名。

完美：

分支名称
例：

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

例：

我的社交网址：https://github.com/Keegan-y

分支名称
例：

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

普通员工：
(1)在自己的电脑上，生成ssh公钥，然后把公钥给项目经理，项目经理把它添加的服务器上面。
(2)项目经理会给每个组员的项目代码的地址，组员把代码下载到自己的电脑上。
(3)创建本地的分支dev,在dev分支中进行每天的开发。
(4)每一个员工开发完自己的代码之后，都需要将代码发布远程的dev分支上。

项目里一般会有两个分支，如：
Master:用于保存发布的项目代码。
Dev:用于保存开发过程中的代码。所有的组员开发完自己的代码提交到该分支上。

到此，git使用教程就写完了，既是自己的实践记录【记不住哈哈】，也能帮助更多的道友管理控制代码，如果内容对读者有用，请关注我，为思考点赞！

最后奉上导图笔记：

到此这篇关于git使用教程(最详细、最傻瓜)的文章就介绍到这了,更多相关git使用教程内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！