其他分享
首页 > 其他分享> > 一文带你走遍Git世界，教会你Git的使用

一文带你走遍Git世界，教会你Git的使用

作者：互联网

@

目录

茫茫人海千千万万，感谢这一秒你看到这里。希望我的文章对你的有所帮助！

愿你在未来的日子，保持热爱，奔赴山海！

这篇文章教会Git

1. Git是什么？

1.1 发展历程

​ 话不多说，Git具体发展历程这里我就不说了,看图就完事了。在2005年的时候，Linus这个人呢,只花了两周，自己用c语言就写出了一个分布式版本控制系统，一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。


来看一下Linus，膜拜一下，远远观望一下大佬！

1.2 Git是什么？

​ Git是目前世界上最先进的分布式版本控制系统（Distributed Version Control System，简称 DVCS）。

1.3 Git和SVN

接下来，让我们聊一聊，我们熟知的Git和SVN的区别吧：

2.Git有什么用?

首先让我们先看看企业开发存在的场景:

2.1 代码合并

​ 在一个项目当中，一个人不可能全部把所有模块全部解决。这时候就需要分配任务给其他人完成，其他人把各自的项目模块完成，再将其整合到一起。

​ 比如，小鱼和小猫是一个项目组的战友，今天产品经理提出两个需求，让小鱼和小猫一天做完。就这样，他们做完后，最后要合并呢？

2.2 代码备份

​ 小鱼今天在公司加班，凌晨一点的时候，终于一个项目模块眼看着就可以交付代码了。可是！！！万万没想到，公司停电了，小鱼的电脑关机了，付诸多少心血的代码就这样结束了！

2.3 代码还原

​ 今天产品经理对小鱼说，叫小鱼去弄一个比较复杂的功能模块，这个功能模块相对于整体项目来说及其不稳定，而且可能需要改项目中的许多代码，这个时候小鱼应该怎么做呢？

2.4 问题追溯

​ 小猫是项目组刚来的新人，写的代码bug比较多。并且不诚实，每次有bug，都会说不是他的问题，是之前人写的本来就有的。这样的话，我们如何判断这bug是谁造成的呢？

看着这些场景，你是否也会头皮发麻，不知从何下手呢，不用担心，Git可以完美的解决这些问题。

3. Git的使用（重点）

要想使用Git解决上述问题,客官你确定不下载一个Git来使用吗，而且它完全免费。

3.1 下载

这里只讲述在Windows上安装Git。

我们可以直接从Git官网下载安装程序，然后按默认选项安装即可，一路傻瓜“git init”即可。

安装完成后，我们可以在任意文件夹或者是桌面点右键，就可以看到以下菜单：

我们点击Git Bash Here，我们就会蹦出一个类似cmd（命令窗口）的窗口，就说明客官你的Git安装成功啦！

安装成功后，我们还需要最后一步的设置，相当于是自己机器的标签，因为Git是分布式版本控制系统，需要每一台机器的标识，不然会认不出谁是谁呢。

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

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置,相当于一个全局设置了这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

这里可以看下我的配置：

接下来可以看下我设置的全局配置

$  cat ~/.gitconfig

3.2 创建版本库

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

接下来，让我们学习创建版本库的命令吧：通过git init命令把这个目录变成Git可以管理的仓库：

​ 瞬间Git就帮你把版本库建好了，而且告诉你是一个空的仓库（empty Git repository），当然，细心的你可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的。注意：没事千万不要手动（作）修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了，导致你没办法使用。如果你没有看到.git目录，那是因为这个目录默认是隐藏的。可以看我这样子操作就行了

3.3 如何把文件添加到版本库中

​ 不知道各位客官有没有看过赵本山和宋丹丹的小品，里面有个桥段，宋丹丹问赵本山：把大象放进冰箱需要几步？而现在问你，把文件添加到本地仓库中，需要几步呢？

​ 现在告诉你，大象放进冰箱需要三步，而把一个文件放到Git仓库只需要两步。更方便快捷吧！

​ 首先，我们得先创建一个文件（hello.txt），然后并在其中添加文字：helloGit!

​ 接下来几个步骤都不截图，把代码放进来，各位看官可以自行复制粘贴到本地测试下！每一步后面都会有相应的注释。瞧，我多贴心。像我这么贴心的男生不多见了吧。O(∩_∩)O哈哈~

$ vim hello.txt （创建并进入vim编辑器，编辑hello.txt文件）

helloGit! （在vim编辑器中，输入i插入，写helloGit！最后使用左上角的Esc键，并输入:wq就可以				退出vim编辑器啦！）

​ 第一步，用命令git add告诉Git，把文件添加到仓库：

$ git add hello.txt （创建hello.txt后，执行这一步代码，可以实现把hello.txt暂存在缓存区							中，这个概念后面概述）

执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

​ 第二步，用命令git commit告诉Git，把文件提交到仓库：

$ git commit -m "添加hello.txt到本地仓库" （这里是把缓存区中的hello.txt提交到本地仓库）
[master (root-commit) 32b0ee3] 添加hello.txt到本地仓库
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

​ 这里我们简单解释一下git commit命令，-m后面输入的是我们对本次文件提交的简要说明，可以输入任意内容，当然最好是有意义的，这样你在需要回退版本号时，就能从历史记录里方便地找到改动记录。

​ 嫌麻烦不想输入-m "xxx"行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入提交说明对自己或者对别人阅读都很重要。实在不想输入说明的童鞋请自行Google，我实在不想告诉你这个参数，不想坑害你们。你们记得，这个提交说明一定要写并且有意义的。

​ git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的hello.txt文件）；1 insertion(+)：插入了两行内容（hello.txt有一行内容）。

所以为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

3.4 查看文件状态

​ 到这里，我们已经成功地添加并提交了一个hello.txt文件，现在，是时候继续工作了，于是，我们继续修改hello.txt文件，改成如下内容：

helloGit!
Git is nice software!

现在，我们 可以执行git status命令追踪文件现在状态：

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，hello.txt被修改过了，但还没有准备提交的修改。

虽然Git告诉我们hello.txt被修改了，但如果能看看具体修改了什么内容，能做个对比那该有多好啊。比如你上周去参加朋友的婚礼了，回来上班的时候，已经记不清上次怎么修改的hello.txt，所以，Git也有帮助我们查看文件修改的内容的命令，需要执行git diff这个命令看看：

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第三行种添加了Git is nice software。

知道了对hello.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add：

$ git add hello.txt

同样没有任何输出。在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

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

	modified:   hello.txt

git status告诉我们，将要被提交的修改包括hello.txt，下一步，就可以放心地提交了：

$ git commit -m "修改hello.txt内容"
[master a3c7c44] 修改hello.txt内容
 1 file changed, 2 insertions(+)

提交后，我们再用git status命令看看仓库的当前状态：

$ git status
On branch master
nothing to commit, working tree clean

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。

看到这里是不是觉得Git也太好用了吧！下面，Git更厉害的东西出来了。Git提供的"后悔药"。

3.5 后悔药

​ 现在你也学会了修改添加提交文件了。Now，我们再来练习一次，修改hello.txt文件如下：

helloGit!
Git is very nice software!

然后尝试添加提交：

$ git add hello.txt
$ git commit -m "hello.txt中添加very"
[master 7fbdd8f] hello.txt中添加very
 1 file changed, 1 insertion(+), 1 deletion(-)

​ 像这样，你不断对文件进行修改，然后不断提交修改到版本库里。比如，每次项目经理提了需求，你照做完成后，提交代码。但是，其中一次提交的版本，出现了Bug，或者一不小心把某个重要的文件删除了，导致整个项目不稳定奔溃了，这可怎么办呢？俗话说的好，人生在世，总有后悔莫及的事情，可是人生是没有后悔药可以吃的啊！但正是没有后悔药，人生注定会精彩无比，必然想好好活这一次，会变得无比意义。如果谁有，请给我一颗吧，让我回到某一时刻，对那个女孩说一句...咳咳，有点扯远了呢！哈哈

而在Git中，不要担心，因为Git总是会有后悔药可以吃的。

​ 在操作文件的时候，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。是不是觉得很赞！嘿嘿，具体怎么操作呢，请诸君看如下：

3.6 深入剖析Git的工作

​ 经过一系列的学习，我们知道使用git add，git commit命令的时候，他把文件添加提交到了哪里吗，是直接添加到了本地仓库，还是推送到了远程仓库吗？接下来，让我们深入剖析下Git吧。

这个阶段学习，你就会弄明白对Git的工作流程，就会明天Git的很多操作到底干了些什么。不会处于在使用的过程中懵懵懂懂的。

3.7 撤销修改文件

当然，在工作过程中，你是不会犯错的！不过现在已经加班到凌晨两点半，你可能觉得在夜深人静的时候，可以干一些不为人知的事情，于是你在hello.txt中添加了一行：

$ cat hello.txt
helloGit!
Git is very nice software!
My stupid boss.

在你准备提交本次代码前，在泡的第9杯咖啡起了作用，你猛然发现了stupid boss可能会让你丢掉这个月的奖金！

既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下：

$ 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:   hello.txt

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

你可以发现，Git会告诉你，git checkout -- file可以丢弃工作区的修改,于是乎，你快速的执行这段代码：

$  git checkout -- hello.txt

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

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

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

总之，就是让这个文件回到最近一次git commit或git add时的状态,能够有效帮助撤销掉你做出错误的修改的内容。现在，我们再小心翼翼地看看hello.txt的文件内容：

$ cat hello.txt
helloGit!
Git is very nice software!

文件内容果然复原了。

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

时间来到了凌晨三点半，你不但写了一些胡话，而且还git add到暂存区了：

$ cat hello.txt
helloGit!
Git is very nice software!
My stupid boss.

$ git add hello.txt

值得庆幸的是，在git commit之前，你发现了这个问题。用git staus查看一下，修改只是添加到了暂存区，还没有提交：

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

        modified:   hello.txt

这个时候，贴心的Git同样会告诉我们，用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

$ git reset HEAD hello.txt
Unstaged changes after reset:
M       hello.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

再用git status查看一下，现在暂存区是干净的，工作区有修改：

$ 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:   hello.txt

还记得如何丢弃工作区的修改吗？

$ git checkout -- hello.txt

$ git status
On branch master
nothing to commit, working tree clean

啊！你会发现，去tmd工作，不做了。然后继续敲着代码加着班。嘿嘿，不工作是不可能的，我可是一位打工人！

可是现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把stupid boss提交推送到远程版本库，你就真的惨了……等着明天你老板把你拉进小黑屋谈话吧~~~

4.远程仓库

到目前为止，我们已经掌握了如何在本地仓库的文件操作，也再不用担心文件的备份丢失的问题了。这只是在本台电脑的备份，可是可是，一旦你电脑系统出现问题，奔溃，需要重装系统怎么办，你的文件不是一样还是丢失了。或者说，同一个项目组，想进行多人协作开发，应该怎么办。

Git帮你解决这些问题！

4.1 远程仓库介绍

从之前的学习，我们知道Git有两个仓库，本地仓库和远程仓库。本地仓库，我们知道了，可是远程仓库是什么？别着急，让我为各位客官慢慢讲述：

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

在这里你肯定会想，至少需要两台机器才能玩远程库不是？但是我只有一台电脑，你这不是为难我胖虎吗？

其实一台电脑上也是可以克隆多个版本库的，只要不在同一个目录下。不过，现实生活中是不会有人这么傻的在一台电脑上搞几个远程库玩（如果你真的这么可爱，那当我没说），因为一台电脑上搞几个远程库完全没有意义，而且硬盘挂了或者电脑坏了会导致所有库都挂掉，所以我也不告诉你在一台电脑上怎么克隆多个仓库。没必要对吧！

而实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

完全可以自己搭建一台运行Git的服务器，不过现阶段，我为了学习Git专门搭建一个服务器为自己服务，你告诉我现实吗？嘿嘿，别这样，肯定还有别的方法啦。

好在这个世界上有一个GitHub的神奇的网站。顾名思义，从这个名字就可以看出这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

但这毕竟是国外的网站，网速可能不是特别的流畅。在国内，我们甚至是很多公司都会使用另一个网站：码云，网址：https://gitee.com。接下来我会着重介绍码云如何使用，注册，连接本地仓库等问题。

4.2 码云的使用

4.2.1 官网地址：

官网:https://gitee.com

4.2.2 注册账号

不会注册？别慌！秉着为人民服务，这里我也会详细的告诉你如何操作：

嘿嘿，妈妈再也不担心我不会注册码云账号了！

4.2.3 创建远程仓库

当你注册完账号后，接下来就可以进行下一步，创建仓库啦。

到这里，你的远程仓库宣布创建完毕啦。是不是一下子有了远程仓库，很开心。但是，你要怎么添加远程仓库呢？

4.2.4 添加远程仓库

话不多说，来看看添加远程仓库的两种方式吧：

我们本地电脑和远程服务器可以使用两种方式来传输数据:HTTPS和SSH协议。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V1gQiLPc-1623550287379)(C:\Users\43835\Desktop\文章需要的图片\git\本地仓库如何与远程仓库沟通.png)]

HTTPS协议在推送代码时需要输入账号密码比较麻烦。SSH协议只需要配置一次，以后不再需要输入账号密码，比较方便。所以，我们学习SSH方式（没办法，懒是一个能很好促进人类发展的词语）

4.2.5 克隆远程仓库

远程仓库做好了，这时候，公司来一个新员工小鱼后，需要拿到远程服务器中的代码到本地进行开发，克隆远程仓库也就是从远程把仓库复制一份到本地，克隆后会创建一个新的本地仓库。选择一个任意部署仓库的目录，然后克隆远程仓库。

小鱼现在需要怎么做呢？来吧，跟着我的操作走一遍，保准你成功！

5. 分支管理（重点）

让我们来看看分支在实际开发中的用处吧

5.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的分支组合拳吗，看得出来有些提交是通过分支完成的吗？

5.2 解决冲突

月有阴晴圆缺，人生的事也总不会太完美，合并分支之路 也不会是一帆风顺的。

让我们来看看合并分支的时候究竟发生了什么：

准备新的dev1分支，继续我们的新分支开发：

$ git checkout -b dev1
Switched to a new branch 'dev1'

修改hello.txt最后一行，改为：

creating a new branch.

在dev1分支上提交：

$ git add hello.txt
$ git commit -m "测试合并冲突问题"
[dev1 927155c] 测试合并冲突问题
 1 file changed, 1 insertion(+), 2 deletions(-)

切换到master分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

这里Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

在master分支上把hello.txt文件的最后一行改为：

creating a old branch master.

提交：

$ git add hello.txt 
$ git commit -m "在master修改hello.txt"
[master c4fe80d] 在master修改hello.txt
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和dev1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

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

这里我们注意到，在执行了git merge dev1命令之后，Git控制台上的后面分支信息发生变化：

分支从master变成了master|MERGING,这也告诉了我们这次合并有文件冲突。

果然冲突了！Git告诉我们，hello.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

$ 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:   hello.txt

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

我们可以直接查看hello.txt的内容：

helloGit!
Git is very nice software!
<<<<<<< HEAD
creating a old branch master.
=======
creating a new branch.
>>>>>>> dev1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们把这些标记出来的内容行删掉，并修改如下后保存：

helloGit!
Git is very nice software!
creating a new branch.

再提交：

$ git add hello.txt 
$ git commit -m "修改冲突问题"
[master f8e3e2a] 修改冲突问题

我们就能看出来，之前的分支信息master|MERGING又变回master了

总结来说，每次当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

5.3 Bug分支

在真正的项目开发中，Bug如同家常便饭一样每天都可能发生。但是有了Bug就需要修复，不然一个项目就会存在了不稳定性或者来自各方的问候。

而在Git中，由于分支是如此的强大，所以，每个Bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到测试妹纸提出一个代号66的bug的issue时。你本来不想改的，或者想等到后面有时间后再来修改Bug，但是测试妹纸一直催你改Bug。

最后没办法，你还是得来改Bug，很自然的，你想创建一个分支issue-66来修复这个Bug。等等，想创建一个分支来修复Bug，但是当前正在dev上进行的工作还没有提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   git.txt

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:   hello.txt

当然，这并不是你不想提交，而是工作只进行到一半，还没法提交。可是预计完成还需两三天的时间。但是，测试只给你两个小时内必须修复该Bug，这该怎么办？

幸好，Git还提供了一个git stash功能，可以把我们目前的工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: f8e3e2a 修改冲突问题

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复Bug，这个以你出现的Bug的最新提交分支来定，如果实在找不到，就假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-66
Switched to a new branch 'issue-66'

现在修复Bug，需要找到Bug的位置，进行修改。现在这里只需要把“Git is very nice software!”改为“Git is very good software!”，然后提交：

$ git add  hello.txt
$ git commit -m "fix bug 66"
[issue-66 ee213a8] fix bug 66
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后删除issue-66分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

$ git merge issue-66
Updating f8e3e2a..ee213a8
Fast-forward
 hello.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

这样就修复完Bug了，是不是很方便，原来的工作空间没有动过，而且改完Bug的分支不想要了，也可以删掉。删掉分支的命令之前也介绍了。而且原计划两个小时的bug修复只花了5分钟！现在该干嘛呢？

嘿嘿，在线偷偷摸鱼吗？摸鱼这辈子是不可能的了。摸鱼一时爽，但最终摸鱼还是要付出代价的，这种在带薪提升自我的时候，怎么能浪费呢？人从工作中可以得到乐趣，这才是一种巨大的好处。现在我的心里只有一件事，就是敲代码。

现在，是时候接着回到dev分支干活了！

$ git checkout dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean

可是可是，工作区是干净的，刚才的工作现场存到哪去了？不会不见了吧，要怎么找回来呀？放心，老夫不会坑害你的。嘿嘿，"耗子尾汁"吧。

现在我们用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: f8e3e2a 修改冲突问题

工作现场还在，只是Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash pop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   git.txt

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:   hello.txt

Dropped refs/stash@{0} (16d1c361031a39e7a97b8e63c3a6dcdef58ac37e)

再用git stash list查看，就看不到任何stash内容了：

$ git stash list

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

学到这里，是不是学会在修复Bug的时候们会通过创建新的Bug分支进行修复，然后合并，最后删除。

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

6. 标签管理

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

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

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

如果换一个办法：

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

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

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

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

这样也可以及时发现在哪个版本出现问题后，可以快速定位在哪个分支下，或者直接使用这个tag来修复Bug。Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

6.1 创建标签

我们了解了标签的用处，那如何在Git中打标签呢？

6.2 操作标签

6.2.1 删除标签

如果我们的标签打错了，也是可以删除的：

$ git tag -d v1.2
Deleted tag 'v1.2' (was d0b0a0a)

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

6.2.2 推送标签到远程

$ git push origin v1.0
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (15/15), 1.33 KiB | 454.00 KiB/s, done.
Total 15 (delta 2), reused 0 (delta 0)
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:favorite_canned_fish/test-git.git
 * [new tag]         v1.0 -> v1.0

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:favorite_canned_fish/test-git.git
 * [new tag]         v1.1 -> v1.1

6.2.3 删除远程的标签

6.2.4 这里小结下

7. 完结散花

相信各位客官看到这里，相信你对Git已经初步掌握。一开始，可能觉得Git上手比较困难，没关系，多操练几次，就会越用越顺手。Git虽然极其强大，命令繁多，但常用的就那么十来个，掌握好这十几个常用命令，你已经可以得心应手地使用Git了。

这里总结下我们工作中常用的Git命令吧，如果有人跳过直接看到这里，哈哈我算你狠。是个狠人，年轻人不讲武德啊，希望你耗子尾汁。

以上即是项目开发中所需要常用的命令。

学到这里，今天的世界打烊了，晚安！虽然这篇文章完结了，但是我还在，永不完结。我会努力保持写文章。来日方长，何惧车遥马慢！

感谢各位看到这里！愿你韶华不负，青春无悔！

注: 如果文章有任何错误和建议，请各位大佬尽情留言！也可以微信搜索太子爷哪吒公众号进行关注一波，感谢各位大佬！

标签：git,一文,Git,master,分支,txt,hello,走遍
来源： https://www.cnblogs.com/taiziyenezha/p/14928927.html