程序员：必备技能 Git
文章目录
每博一文案
想要生活事事如意，有两个诀窍，一是不为难自己，二是不为难别人。总结一句话就是爱人先爱己，责人先问心。如果对人对己，能做到这两点，那么你将会过得很愉快。
爱人先爱己，即是要学会尊重自己，也别和自己过不去，当我们喜欢一个人的时候，会不自觉把自己放得很低，明知道喜欢他，会让自己深陷泥泞，自却还是甘之如饴.等到很久之后，才发现自己已经为她，变得不像自己，会为了他
的一句话就疑神疑鬼，会因为说要放弃，却做不到，而后自己生气。其实明知道走不通，就别坚持着要去走了。
明知道爱一个人没结果，就别强撑着委屈自己了，爱自己是爱万物的基础。
责人先问心，即是说，在责怪别人之前，先想想有没有自身的原因，我们都习惯性在别人身上找问题，上班迟到，抱怨天气不好；提案失败，抱怨客户刁钻；考试不理想，抱怨出题偏。
这些抱怨并不能让自己感觉舒服，因为结果已经不能改变，反而会让别人觉得你充满负能量。
而如果你能把心放宽，面对问题，先从内在分析自我，保持冷静，总结经验，那么不仅会让能力和境界得到提升。
也会让别人对你充满敬佩，愿意与你相处，向你靠拢，那时你就会觉得世界都对你善待，而你自己也不会被琐事困扰。真正聪明的人”从来不和自己过不去，保持一颗看淡得失的平常心，拥有一颗与人为善的慈悲心，那么生活的纷纷扰扰就再也打扰不了你的心情。
—————— 一禅心灵庙语
1. Git 的概述
Git 是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种 项目。 Git 易于学习，占地面积小，性能极快。 它具有廉价的本地库，方便的暂存区域和多个工作 流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
1.1 版本控制
版本控制是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统。
版本控制其实最重要的是可以记录文件修改历史记录，从而让用户能够查看历史版本， 方便版本切换。
说白一点就是：就是对于修改的文件的备份拷贝，根据需要获取对应的修改的历史版本的文件。例如：如下
文档列表，我们对其中的 ”毕业论文版“ ，进行了，一个修改历史吧备份。
我们通过 Git 就可以实现这样的版本控制，但是好处就是：不需要，像上面一样创建多个文件备份，通过 Git 我们只需要一个文件就可以到达上述图片的作用。
1.2 SVN
集中式版本控制工具
CVS、SVN(Subversion)、VSS……
集中化的版本 控制系统诸如 CVS、SVN等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法。 简单的说就是，我们的版本控制都需要通过 上网 访问SVN 这个服务器才可以实现 我们的 版本控制
这种做法带来了许多好处，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果 服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。
1.3 Git
Git是分布式 的,Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用Git并且有个 中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的PC是一样的。我们可以 把它当做一个开发者的pc就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不 过“交换”修改不方便而已。简单的说，就是我们把上述的 集中化的 一份 服务器 ，放到了，自己的本地电脑上，自己本机电脑不需要上网 就可以实现上述的本版控制，而我们再配合 代码托管中心: Github, Gitee ，创建远程仓库就可以实现多人，团队协作的功能。
1.4 Git 和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库，一般我们简单称为远程库。
- 局域网 ：GitLab :https://about.gitlab.com/,
- 互联网 ：GitHub（外网）https://github.com/
- Gitee码云（国内网站） https://gitee.com/
2. Git的安装下载
下载与安装
官方网站: https://git-scm.com/
选择你对应系统的版本下载到了。
由于该软件是国外的，我们访问外网，可能比较慢，导致下载速度非常的慢
这里介绍一个小技巧，对于访问，外网下载软件，或者文件内容，比较慢的话，我们可以通过 国内的镜像下载
如下是我们国内的Git镜像网站：https://registry.npmmirror.com/binary.html?path=git-for-windows/
从下面的列表中，选择你需要的对应的版本下载就可以了 。这里我们选择 v_2_31_1.windows 版本的。
2. 15步一条龙安装 Git 服务
- 安装包下载好后，我们打开它。如下，点击下一步 next
- 选择
Git安装位置，注意: 要求是非中文并且没有空格的目录，然后下一步。
- 然后我们就来到了，Git选项配置的窗口中，推荐默认设置，然后下一步。
第一个在桌面上创建快捷方式，我们一般不勾选，因为对应 Git 的使用，主要是使用，鼠标右击打开的。
- 确认，Git安装目录名，不用修改，直接点击下一步。
- 我们来到了，选择
Git的默认编辑器，这里，个人建议使用默认的Vim编辑器了解Linux都知道Vim这个神器了。然后点击下一步。
- 默认分支名的设置，选择让Git 自己决定，就是分支名默认为
master，各大公司都是统一使用默认 的master，我们也就不要改了，下一步。
- 修改
Git的环境变量，选第一个，不修改环境变量，只在Git Bash里使用Git。
第二个表示，会修改我们的系统中的环境变量。
- 择后台客户端连接协议，选默认值OpenSSL，然后下一步。
- 配置
Git文件的行末换行符，Windows使用的是CRLF，Linux使用LF，我们知道，Git是由Linus大神两周时间开发出来的，所以Git中的是继承Liunx的，所以我们选择第一个自动转换，然后继续下一步。
为什么我们需要这个 自动转换 呢，因为我们是将 windows 系统下编写的文件，通过 Git 进行操作，其中存在一些冲突，就是上面的，文件内容中末尾的换行符产生了冲突，Windows 下的是 CRLF 而我们的 Git 是继承了 Linux的，Linux 下的是 LF 。为了，防止麻烦，就它自动转换为 LInux 的 LF 换行格式。
- 选择Git的凭据管理器，选择默认的跨平台的凭据管理器，然后下一步。
所谓的凭证管理就是如下 点开我们的 控制面板——> 用户账户——> 凭据管理
- 其他配置，选择默认设置，然后下一步。
- 实验室功能，技术还不成熟，有已知的bug，不要勾选，然后点击右下角的
Install按钮，开始安装Git。
- 点击Finsh按钮，Git安装成功！
- 最后验证是否，安装成功，右键任意位置，在右键菜单里选择
Git Bash Here即可打开Git Bash命令行终端。 如果是 windosw 11 的话需要点击 一下 显示更多才有，这个Git Bash Here显示。
- 在
Git Bash终端里输入git --version查看git版本，如图所示，说明Git安装成功。
Git GUI： Git提供的图形界面工具
Git Bash： Git提供的命令行工具
git --version
3. Git 的基本使用
注意 因为 Git 是由 开发 Linux 的大神开发的，所以，Git 兼容 Linux 中的命令，在 Git中可以尽情的释放你的 Linux 命令,
有关的 Linux 的命令，使用，大家可以，移步到 🔜🔜🔜 Linux_ChinaRainbowSea的博客-CSDN博客
3.1 设置用户签名
当我们将 Git 安装好后，要做的第一件事情就是，设置Git的用户名称和 email 地址 ，这是 非常重要 的，如果没有设置该用户名和 emial 地址的话，你是无法提交本地仓库的。无法使用 Git的功能。因为：每次使用 Git 提交都会使用 该用户的信息(用户名和 email 地址 ),需要注明该操作是谁做的，出了问题，由谁负责的。
补充:
签名的作用：是区分不同操作者的身份。用户的签名信息在每个版本的提交信息中都能看到，因此确认本次提交是谁做的，谁负责的，出来问题，找谁。
Git首次安装必须设置一下用户签名，否则无法提交代码
其中的用户名和 email的地址都可以不用实际存在的，随便编写(有意义就可以了)，Git并不会去，验证其信息的真实性。
**※注意：**这里设置用户签名和将来登录GitHub（或其他代码托管中心）的账号没有任何关系。
右键打开 Git 中的 Git Bash Here 中的命令行客户端。
设置Git用户名的命令格式
git config --global user.name 用户名
这里我们将，我的用户名命名为 RainbowSea
git config --global user.name RainbowSea
设置Git的 email 的命令格式
git config --global user.email 邮箱
这里我们将，我的 email 设置为我们 RainbowSea@.com
git config --global user.email RainbowSea@.com
在你的用户的家目录中可以找到一个有关于，你刚刚注册的用户的信息的文件，该文件名为 .gitconfig
补充
命令中的global 是全局变量的意思。
3.2 初始化仓库
要想使用 Git 对我们的文件(或代码)进行版本控制，首先需要初始化仓库，让我们的 Git拥有管理这个目录中的文件的权限。
初始化仓库的命令
git init
- 首先我们在电脑上创建一个空的文件夹，让
Git版本控制管理我们的这个目录，这里我们创建一个名为Hello的文件夹
- 我们进入到这个目录中，右击鼠标打开我们
Git bash窗口。为什么让我们进入到该目录中才打开Git bash窗口，因为这样可以让我们的 Git bash 直接索引到该文件夹中，不用我们使用cd的方式进入到这里面。偷个懒。
- 执行
git init初始化仓库的命令，如下：
git init
如果我们 初始化仓库 成功了的话，我们就可以在我们的 Hello 文件夹中，生成一个名为 .git 的隐藏文件。
注意: 需要将我们的的查看隐藏的项目勾选上，才可以看到 这个 .git 文件，不要将这个文件删除了，删除了，Git就无法对我们当前的文件夹进行版本控制了。看看可以，不要删除了。
如下图所示：
上面是使用 windows 的方式查看该 .git 文件，我们也可以在 Git 中使用，Linux中的查看文件的方式如下
ll # 查看当前文件(隐藏的文件无法查看)
ls # 和ll 作用是一样的,只是显示的方式不一样
ll -a # 查看当前全部的文件，可以查看到隐藏的文件
ls -a # 和 ll -a 是一样的作用，只是显示的方式不一样
3.2.1 第二种初始化仓库的方式
我们可以通过 clone 克隆的方式，初始化我们的本地仓库。这里我们不详细介绍，后面我们再详细说明这一点。
具体命令格式如下
git clone <远程仓库的链接> [本地目录]
3.3 查看本地库状态
我们查看本地库(文件夹的状态的命令)
git status
no branch master ： 表示当前在默认分支 master 中，和我们安装Git时的第 6 步，默认分支的配置
No commits yet ： 表示你还没有 commit 提交本地仓库的操作
nothing to commit (create/copy files and use “git add” to track) : 表示不需要提交(创建/复制文件并使用“git add”跟踪) ，就是当前暂存区中没有需要提交到本地库的数据，表示你没有什么东西需要提交到本地库的，还是一个空本地库
我们在该 Hello 文件夹中创建一个名为 test.txt 文件。
这里我使用 vim 创建该文件，大家也可以直接使用 windows 中的方式通过鼠标创建该文件
关于 vim 的使用大家，可以移步到 🔜🔜🔜 你一定可以看懂的：Linux编辑器-vim的使用_ChinaRainbowSea的博客-CSDN博客_shift加冒号按不出来
具体如下内容：
我们打开文件，可以看到多出来了一个名为 test.txt 的文件，
我们也可以通过 命令行的方式，我们上述使用过的命令 ll 查看
ll
当我们在，文件夹中创建了一个文件的时候，也就是我们的 工作区中的文件修改了，再次使用 查看本地库状态的 命令
git status
我们可以看到，具体显示如下：
on branch master : 这行信息没有改变，表示的是当前所在分支是
masterNO commits yet : 这行信息表示的是，你没有进行过提交
commit操作
Untracked files: (use "git add <file>..." to include in what will be committed)我们最后一行信息发生了改变，表示我们还有文件没有被Git追踪到（也就是没有提交到暂存区当中去），没有被Git追踪到(提交到暂存区) 的文件，会被 Git 标红 显示出来，如上图所示的test.txt文件。
如何解决这个问题呢，注意看，其实命令中已经提示我们了，使用 git add ，解决它
3.4 添加暂存区(git追踪到)
添加暂存区的作用：将我们工作区中的文件(也就是我们本地文件夹中的文件)一个或多个文件的修改添加到暂存区当中。
将本地文件提交到暂存区中的命令格式如下:
git add . # 使用通配符，将本地工作区中的文件的修改全部提交到暂存区当中去,也可以使用 *.xxx后缀的文件
我们也可以不使用 通配符指明需要提交的文件名，命令格式如下：
git add 文件名
这里我们使用指明文件名的方式，将我们添加的 test.txt 文件提交到 暂存区中(也就是被Git追踪到)
git add test.txt
如上图所示：其中给予了一个警告：warning: LF will be replaced by CRLF in test.txt.：其表示的意思是：**将 windows 中末尾换行符(CRLF) 自动转换为 Linux 中的末尾换行符(LF) ** ，这就是我们上述安装 Git 中的一个换行 第 9 步中提到的，自动转化末尾换行符的配置
好了，这时候，我们已经将 本地工作区中的修改的文件提交到了暂存区(Git 追踪到)当中去 了，
这时候，我们再次使用 查看本地库状态的命令查看一下，发现我们刚刚变成 test.txt 的文件变成了 绿色了
git status
当查看本地库状态中的文件变成了，绿色 就说明我们的对应工作区中的文件已经提交到了暂存区当中了(也就是被Git追踪到)。
Changes to be committed: 表示要提交的更改。
我们暂存区中的文件是可以被我们手动删除的。
删除暂存区中的命令格式如下：
git rm --cached 文件名 # 我们可以使用 Linux 的通配符 *.x 删除多个文件
这里我们测试将我们刚刚提交到 暂存区 的 test.txt 的文件删除。
git rm --cached test.txt
rm 表示该文件删除成功了。如，我们再次使用命令 git status 查看本地库的状态。我们会发现我们刚刚提交的 test.txt 文件又被重新标志成了，红色 .被标记成红色意味着，我们的该文件并没有被 提交到 暂存区当中 (没有被 Git追踪到)。
所以我们需要将，该文件重新提交到 暂存区 中，这里我们使用 git add . 通配符的方式，将本地工作区(文件夹)中的提交到 暂存区。
git add . # 我们可以使用 Linux 的通配符 *.x 存入多个文件
提交到本地工作区后，我们再次查看 git status 本地仓库状态。我们会发现我们刚刚提交的 test.txt 文件又被重新标志成了，绿色 .被标记成绿色意味着，我们的该文件被 提交到 暂存区当中 (被 Git追踪到)。
3.5 提交本地仓库
我们刚刚做了，将本地工作区中的文件提交到 暂存区 当中，接下来，我们要做的就是将暂存区中的文件提交到本地仓库
作用：将Git中暂存区中文件提交到 本地仓库 的当前分支。
注意： 只有存入到暂存区当中的文件才会被 commit 提交到本地仓库当中去。
提交本地仓库的命令格式
方式一: 表示将暂存区当中所有的文件提交到本地库
git commit -m "日志信息" # 表示将暂存区当中所有的文件提交到本地库
-m "日志信息"
日志信息:是必须要编写的,表示:你这次提交的文件到本地仓库的操作是干什么的。
如果不写的话，我们是无法提交这次文件到本地仓库的
-m 表示要你编写日志信息了，如果你不写的话，也没有关系，因为如果没有的话，Git会在后面弹出输入文本框，
提示你输入 日志信息。
所以我们为了，省略其Git 弹出输入文本框中，我们就可以提交在 -m 中编写好 日志信息
方式二: 指明提交到本地仓库中的文件
git commit -m "日志信息" 文件名 # 我们可以使用 Linux 的通配符 *.x 提交多个文件
我们将暂存区中的 test.txt文件，提交到本地仓库中。我们使用第一种方式。将暂存区当中 标记 绿色 的文件提交到本地仓库
如下：
git commit -m "first commit"
# 日志信息 我们写成是 first commit 即可
补充上述的提交提示信息:
[master (root-commit) 9c9ea2c] first commit # master 当前分支 9c9ea2c 表示的是该提交操作的编号,用于我们后面的版本控制使用。
1 file changed, 7 insertions(+) # 一个文件的发生了改变, 就是我们提交了一个文件, 其中添加了(insertions) 7 行的数据，注意在 Git中是行为单位的。
我们再次使用，git status 查看本地库状态。结果如下：
nothing to commit, working tree clean : 表示这是一个干净的库，就是说你没有什么文件，需要提交的到 本地仓库 中去。
其他的是和上面的 一样的结果，
只不过少了一个，No commits yet ： 表示你还没有 commit 提交本地仓库的操作。因为我们提交 commit 过了，所以就没有这句提示了。
3.6 添加文件至忽略列表
一般我们总会有些文件无需纳入到 Git的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如 “日志文件，或者编译过程中创建的临时文件，.class 字节文件。在这种情况下，我们可以在 主工作目录 (注意是：主工作目录)中创建一个名为 .gitignore 的文件 (注意: 文件名是固定的，不要改变 )。列出你要忽略的文件模式。注意: 在 Linux中 以 .开头的文件是隐藏文件。
在主目录下建立".gitignore"文件，此文件有如下规则∶
- 忽略文件中的空行或以井号(
#) 开始的行将会被忽略 - 可以使用 Linux 中的通配符。例如：星号(
*) 代表任意多个字符，问号 (?) 代表一个字符，方括号([abc]) 代表可选字符范围，大括号({string1,string2})代表可选的字符串等。 - 如果名称的最前面有一个感叹号(
!) ，表示例外的规则，将不被忽略 - 如果名称的最前面是一个路径分隔符 (
/) ，表示要忽略的文件在此目录下，而子目录中的文件不忽略 - 如果名称的最后面是一个路径分隔符 (
/) ,表示要忽略的是此目录下该名称的子目录，而非文件(默认文件或目录都忽略)
# 此为注释
*.txt # 忽略所有以 .txt 结尾的文件
!lib.txt # 但 lib.txt 除外
/temp # 仅忽略项目根目录下的 ToDo 文件，不包括其它目录 temp
build/ # 忽略build/ 目录下的所有文件
doc/*.txt/ # 会忽略 doc/notes.txt 但不包括 doc/sever/arch.txt
操作，我们定义在 Hello 文件夹中创建一个名为 .gitignore 文件名，并在其中编写 *.a 忽略 以 .a 结尾的后缀文件。注意文件名 .gitignore 可千万不要写错了，一个字符都不可出错，一旦错了，就没有省略效果了
编写 .gitigore 中文件内容，编写 *.a 忽略 以 .a 结尾的后缀文件。
再使用本地仓库的状态：并将该.gitigore 文件存入到 git add ——> 暂存区，再提交到 git commit——>到本地库中，才有省略文件的作用。
.gitigore 配置内容编写好后，我们在该 Hello 文件夹中添加一个名为 test2.a 的文件。
我们可以看到，当我们配置了.gitigore 内容省略以 .a 后缀的文件后，无论是我们，git status 还是 git add 都是不会去检测这个，以.a 后缀的 test2.a 文件，如下：
这就是我们，.gitigore 省略的列表的作用。
3.7 查看日志信息(历史版本信息)
所谓的查看日志信息版本信息其实就是 查看我们提交到本地仓库的操作的记录信息
在Git 中的历史版本信息是无法删除的，除非删除跑路。
其记录信息包含有：
HEAD—> master：当前 head 指针指向的 分支。- 历史版本：编号
- 提交到本地仓库中的 “日志信息”
- 所有的提交到本地仓库的历史记录
Author: 该提交操作的用户名和 emailDate: 该提交本地库的时间点。
查看日志信息的命令格式：
方式：查看简写的版本信息 ，当所显示的版本信息太多了时，我们可以使用 q 退出该查看
git reflog
上述显示的提示信息:
cea70fa # Git会对我们提交本地库的操作进行编号，记录下来，用于版本穿梭，这个数据前 7 位的历史版本编号
(HEAD -> master) # 表示当前 head 指针指向的分支(就是当前所在的分支)的历史版本
: commit: commit .gitignore , first commit # 就是我们在 commit 到本地库时所编写的日志信息
方式：查看详细的版本信息 : 可以查看到该 commit 提交本地库操作时谁提交的，什么时间提交的，以及完整的 历史编号。当所显示的版本信息太多了时，我们可以使用 q 退出该查看
git log
3.8 历史版本的穿梭
所谓的历史版本穿梭：就是将我们的文件回退到某个指定的修改的历史版本中去。
版本穿梭的命令格式
git reset --hard 历史版本编号 # 就是你想，回退到哪个的历史版本的文件对应的的编号
演示历史版本穿梭
准备工作：我们修改我们的 test.txt 文件中的内容，再 test.txt 最后一行中添加 666666，再 add 到缓存区——>再 commit 到本地库中，如下：
git status
git add test.txt
git commit -m "second commit" test.t
git reflog
我们查看当前 head->master head 指向 master 分支中的 04acd38 历史版本的文件：
注意：当我们的 head-> 指针指向哪个分支中的哪个历史版本的文件，我们所打开的文件就是 head -> 指针所指向的文件的历史版本，一般 head-> 指针指向的是最新的版本。
如下查看，当前我们 head->所指向的分支的历史版本中的 test.txt 文件的内容如下
cat test.txt
在 windows 中查看也是一样的
准备工作做完后，查看该历史版本信息 git reflog
注意这时候我们 Hello 文件夹中只有一个 test.txt 文件，
接下是见证，我们 Git 版本控制神奇的地方来了。—— 版本穿梭
我们需要做的操作就是，将我们的 test.txt 文件回到我们最开始没有 666666 的那个历史版本。
- 首先查看我们的历史版本信息找到 所需要穿梭到的历史版本编号，如下：
其中的 e2874e5 就是我们要穿梭的版本编号。
- 穿梭回退到
e2874e5历史版本中去，注意：一般历史版本编号，我们使用复制的方式，防止编写错误
git reset --hard e2874e5
HEAD is now at e2874e5 first commit ：表示我们的
head指针已经指向 该 e2874e5 编号的历史版本中
- 使用 git reflog 查看版本信息
我们可以看到，多出来了一个 e2874e5 (HEAD -> master) HEAD@{0}: reset: moving to e2874e5 的指针
e2874e5 (HEAD -> master) HEAD@{0}: reset: moving to e2874e5 # 表示的是我们当前版本穿梭的记录 reset 版本穿梭的关键字。
e2874e5 (HEAD -> master) HEAD@{3}: commit (initial): first commit # 表示当前 head 指针所指向的分支中的历史版本
我们可以发现 e2874e5 (HEAD -> master) HEAD@{3}: commit (initial): first commit 已经指向了我们指定的历史版本当中去了 e2874e5 ,这个历史版本中的 test.txt 文件中是没有 6666666的。
注意：我们的 head -> 指向哪个分支中的哪个历史版本，我们当前文件打开的就是哪个分支中的历史版本
这里我们打开我们的 test.txt 文件，查看其文件内容：发现没有 666666的内容了。
同样的我们可以将test.txt 回退到含有 666666 的历史版本中去。
git reflog
git reset --hard 04acd38
Git 切换版本，底层其实是移动的 HEAD 指针，具体原理如下图所示。
4. Git 分支
4.1 什么是分支
在 版本控制 中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作 从开发主线上分离开 来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也还是指针的引用）
4.2 分支的好处
分支的好处：
- 可以同时并行推进多个功能开发，提高开发效率。
- 提高项目的完整，稳定性，各个分支的存在时相互独立的，在开发过程中，如果某个分支开发失败了，不会对其他分支有任何的影响。失败的分支删除重新开始即可。
4.3 查看本地分支
查看本地分支的命令格式 ，
git branch -v
**或者是，省略 -v **
git branch
4.4 创建本地分支
创建本地分支的命令格式
注意：从哪个分支中创建的分支，该分支会复制当前分支下的所有内容
git branch 分支名 # 创建分支
如下：我们创建一个名为 hot-fix 分支：
git branch hot-fix
4.5 切换本地分支
切换本地分支的命令格式
git checkout 分支名
我们还可以直接切换到一个不存在的分支（创建并切换）
git checkout -b 分支名
例如：将当前分支切换为 hot-fix 分支
git checkout hot-fix
查看历史版本 git reflog 中会记录我们创建的分支操作
我们来验证，各个分支之间是相互独立的，当前分支的文件的修改不会影响到其他分支中的文件
- 我们首先在
hot-fix分支中，修改 test.txt 文件的内容修改为: 在最后添加一句 hot-fix,如下：
在 windows中也是一样的
- 注意：修改了文件需要，提交本地库：
查看历史版本信息 git reflog
- 切换到
master分支查看，test.txt 是否存在 hot-fix 添加的这一行数据的修改。
在 windows 中也是一样的
4.6 合并本地分支
合并本地分支：一个分支上的提交可以合并到另一个分支上 ，简单的说就是将其中分支中修改的内容与另外一个分支上的内容合并起来。
注意：合并分支，只是将分支之间的内容合并上，其合并的分支，并不会消失
合并分支的命令格式
注意是将其他分支合并到当前分支中
git merge 合并的分支名 # 注意是将其他分支合并到当前分支中
例如：将 hot-fix 分支合并到 master 分支中去
git merge hot-fix
Updating 04acd38…9f53055
Fast-forward
test.txt | 1 +
1 file changed, 1 insertion(+)表示：数据更新，文件 test.txt 一个文件 1
insertion(+)添加了一行，注意Git中是以 行为单位的
我们查看合并后的 master 分支中 test.txt 文件是否把其中的 hot-fix 的内容合并了。
注意：合并分支，只是将分支之间的内容合并上，其合并的分支，并不会消失
4.7 解决合并冲突
冲突产生的表现：后面状态为 MERGING
当两个分支上对文件的修改可能会存在冲突。
例如：两个分支同时修改了同一个文件的同一行(Git 是一行为最小单位)的内容。当我们合并这两个分支的时候，因为两个分支同一文件同一行位置都发生了改变，我们的 Git 就不知道你需要的是哪个修改的内容为准了。就爆出冲突 MERGING 。
解决冲突的方式
既然，我们的Git 不知道我们需要的是其中的哪一个修改内容，那我们自己做选择，手动修改自己需要的内容，来解决冲突
步骤如下：
-
处理文件中冲突的地方
-
将解决完冲突的文件加入暂存区(add)
-
提交到仓库(commit) 注意这时候的 commit 不可以指明 提交的冲突文件名，因为这时冲突中 我们的分支中存在两个一样的冲突文件，Git 它会说它又不知道你要提交的是哪一个文件了(报错)，所以我们干脆就全部提交上去，不然 Git做选择
冲突部分的内容处理如下所示：
- 准备工作制造 合并冲突，在 hot-fix 分支和 master 分支中的同一文件 test.txt 的同一位置最后一行，添加内容：
- hot-fix 添加为 hot-fix 999
- test.txt 添加为 master 999
- 这两个分支都提交commit 到本地仓库中
- 合并该这两个分支，将 hot-fix 分支的内容合并到 master 当中，触发冲突。如下:
Auto-merging test.txt # 表示合并的对象文件内容
CONFLICT (content): Merge conflict in test.txt # CONFLICT(冲突) content(内容) Merge conglice in test.txt 冲突的所在位置(的文件)
Automatic merge failed; fix conflicts and then commit the result. # 自动合并失败; 修复冲突，然后提交结果。
(master|MERGING) # 表示正在合并，但是没有合并成功
- 解决冲突：打开冲突文件 text.txt
- 手动删除，修改保留你需要的内容，删除，其中的
<<<<HEAD,====,>>>>>hot-fix这些提示修饰符，如下：
- 将解决完冲突的文件加入暂存区(add) ，并 commit 提交到本地仓库中
注意这时候的 commit 不可以指明 提交的冲突文件名，因为这时冲突中 我们的分支中存在两个一样的冲突文件，Git 它会说它又不知道你要提交的是哪一个文件了(报错)，所以我们干脆就全部提交上去，不然 Git做选择 如下：
不要指明冲突的文件名，commit 提交到本地仓库中
4.8 删除分支
注意：不能删除当前分支，只能删除其他分支
git branch -d 分支名 # 删除分支时，需要做各种检查
git branch -D 分支名 # 不做任何检查，强制删除
4.9 开发中分支使用原则与流程
几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离 开来进行重大的Bug修改、开发新的功能，以免影响开发主线。
在开发中，一般有如下分支使用原则与流程：
master： 生产分支，线上分支，主分支，中小规模项目作为线上运行的应用对应的分支develop：开发分支，是从 master 中创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要时，将内容合并到 master 分支，准备上线。feature/xxxx分支：从 develop 中创建的分支，一般是同期并行开发，但不同期上线时，创建的分支，分支上研发任务完成后，将内容合并到 develop 分支中去hotfix/xxxx分支：从 master 派生的分支，一般作为线上 Bug 修改使用，修复完成后需要，将内容合并到 master，test，develop 分支。还有一些其他分支，在此不再讲述，例如： test 分支(用于代码测试) ，pre 分支(预上线分支)等等
5. Git 远程仓库
前面我们已经知道了Git中存在两种类型的仓库，即本地仓库和远程仓库。
那么我们如何搭建Git远程仓库 呢？
我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有GitHub、码云、GitLab等。
gitHub（ 地址：https://github.com/ ）是一个面向开源及私有软件项目的托管平台，因为只支持
Git 作为唯一的版本库格式进行托管，故名gitHub
码云（地址： https://gitee.com/是国内的一个代码托管平台，由于服务器在国内，所以相比于
GitHub，码云速度会更快
GitLab （地址： https://about.gitlab.com/ ）是一个用于仓库管理系统的开源项目，使用Git作 为代码管理工具，并在此基础上搭建起来的web服务,一般用于在企业、学校等内部网络搭建git私服。
5.0 注册远程仓库 Github
5.1 创建远程仓库链接别名 “远程仓库别名”
创建远程仓库：在进行此操作时需要先初始化(git init)本地库，然后与已创建的远程库进行对接。
创建远程仓库的命令格式
git remote add <远程仓库链接的别名> <远程仓库的链接URL>
远端仓库链接的别名，默认是 origin，取决于远端服务器设置，许多大公司都是使用默认的别名origin，我们也不要改变了，就使用默认的 origin 远程仓库别名。
远程仓库的链接 URL：我们在 Github,gitee中创建的仓库的链接地址。
例如：我们将刚刚我们在 Github 中创建的远程仓库链接，添加到本地仓库中去
git remote add origin https://github.com/China-Rainbow-sea/java.git
5.2 查看远程仓库
查看远程仓库的命令格式
git remote # 查看远程仓库的别名
或者我们带上 -v 查看详细的远程仓库信息
git remote -v
补充说明:
origin https://github.com/China-Rainbow-sea/java.git (fetch)
origin https://github.com/China-Rainbow-sea/java.git (push)
为什么会有两个 远程仓库的链接别名
一个是 fetch 我们拉取远程仓库的链接
一个是 push 推送到远程仓库的链接
对于远程仓库而言这两个别名链接是不冲突的。
5.3 推送本地仓库分支到远程仓库
将本地仓库中的内容推送到远程仓库中的命令格式
强调： 我们一定要先将本地工作区中的文件提交到了本地仓库中后，再将本地仓库中的内容push推送到远程仓库中去。
注意：push 是将本地库代码推送到远程库，如果本地库代码跟远程库代码版本不一致push 的操作是会被拒绝的。也就是说，要想 push 成功，一定要保证本地库的版本要比远程 库的版本高！因此一个成熟的程序员在动手改本地代码之前，一定会先检查下远程库跟本地 代码的区别！如果本地的代码版本已经落后，切记要先 pull 拉取一下远程库的代码，将本地 代码更新到最新以后，然后再修改，提交，推送！
注意：后面需要跟上你推送的内容的分支名 (因为对于推送的最小单位是 分支)
git push <远程主机名> <本地分支名>:<远程分支名>
# 将本地仓库分支的内容推送到远程仓库中的远程分支中去
如果本地分支名与远程分支名相同，则可以省略冒号：如下
git push 远程仓库链接/远程仓库链接的别名 本地仓库分支名
举例：我们将我们本地仓库中的 test.txt 文件推送到 远程仓库中去
git push origin master
这里我比较幸运一次就成功了，注意: 因为 GitHub是国外的，所以我们可能要 push 多次才能成功 。
此时发现已将我们 master 分支上的内容推送到 GitHub 创建的远程仓库。
如果是第一次，push 远程Github 远程仓库的话，需要你输入Github 的账号密码登入上 Github，建立普遍凭据。
5.4 从远程仓库中抓取和拉取到本地仓库
对于远程仓库中的内容的更新，我们也可以通过了 pull 拉取到本地仓库
注意请时刻保持 远程仓库中的内容与 本地仓库中的内容一致，防止影响一些后面的项目操作
拉取远程仓库到本地仓库的命令格式 ，注意如果是一个空本地仓库可以通过 pull 得到远程仓库中的所有内容，但是不存在与远程仓库建立联系(clone),时，是无法pull 到远程仓库的内容的。
将远程仓库中的分支中内容拉取更新合并到本地指明的分支中去。
git pull <远程主机名> <远程分支名>:<本地分支名>
如果本地分支名与远程分支名相同，则可以省略冒号：如下
git pull 远程仓库的链接/远程仓库链接的别名 远程仓库的分支名
如果不指定远程仓库链接和分支名，则抓取所有并更新当前分支。
例如：
准备工作：我们将在 Github中编辑修改一下文件，用于 pull
- 编写好后，我们拉取 pull 一下远程仓库 到本地仓库,同样因为Github 是国外的，我们可能会 pull 失败，需要 pull 多次才可能成功，这里我也是 pull 十多下才成功了。
git pull origin master
我们查看本地库状态git status ，发现，Git 提示我们这是一个干净的库，说明 pull 会自动将拉取到的内容 commit 到本地库中
我们再查看历史版本 git reflog 信息，可以看到 Git记录了这次 pull 操作。
我们还有第二种方式：分步拉取远程仓库 该操作用于查找错误冲突。
使用这中方式之前，我们需要理解一下拉取远程仓库 的原理：其实拉取远程仓库也是一种远程分支的合并。远程分支也是一个分支，我们也是可以进行 merge 合并分支操作的。所以我们上述的第一种方式 pull 虽然只有一个命令，但是却做了两件事情：一是将远程仓库的分支内容抓取到本地，二是：将远程仓库中抓取到的分支内容合并到本地仓库中去。
而我们这里所谓的第二种方式其实，把 pull 操作分开执行而已。具体操作如下：
第一步 :抓取远程仓库的命令格式如下：
**注意: ** 抓取指令就是将仓库里的更新都抓取到本地，不会进行合并的，需要我们手动合并
如果不指定远程的仓库链接和分支名，则抓取所有分支。
git fetch 远程仓库链接或远程仓库链接别名 分支名
例如：我们抓取，在 github中的远程仓库的修改内容,同样的国外的原因，我们可能需要抓取 fetch多次才能成功。
git fetch origin master
第二步 ：将远程仓库中抓取到的内容 合并到本地仓库，和上面的合并分支是 一样的，只不过这里不同的是这里需要写名：远程仓库的链接别名/(斜杆) 远程仓库的分支名
git merge origin/master
其实我们的 pull 指令就是将这git fetch,git merge, 两个步骤结合成一个指令了而已。
5.5 克隆远程仓库到本地仓库
如果我们已经存在一个远程仓库了，想要将远程仓库中的内容全部复制到我们的本地仓库我就可以使用 clone 克隆的方式，将远程仓库中的内容都克隆到本地仓库中。
clone克隆远程仓库的同时 会：1.初始化本地仓库，2. 创建目录(文件夹)，3.拉取pull远程仓库中的所有内容。
克隆远程仓库的命令格式如下：
git clone 远程仓库的链接 设置目录名 # 设置目录名可以省略,默认采用远程仓库的名的后几位名字
如果 clone 克隆的是 pulloc 公开的仓库，是不需要输入Github 的账号密码的，如果是私有的就需要 输入Github的账号密码了。
举例：将我们在Github 中公开的仓库，克隆到本地仓库中
在本地中创建一个文件夹用于，存放从远程仓库克隆下来的内容clone ，如下：
git clone https://github.com/China-Rainbow-sea/java.git
虽然我们将远程仓库的内容克隆到本地了，但是我们需要时时 pull 将本地仓库的内容与 远程仓库中的内容同步上
5.6 远程仓库的拉取合并冲突的解决
说明pull远程仓库冲突的场景：
假设我们有两个用户分别是A用户和 B用户，协作开发一个项目。出现了Bug，其中我们的A 用户，将修改好的解决好Bug的代码 push 到了我们的远程仓库中。一个小时后，我们的B 用户也修改好的解决好Bug的代码，提交到了commit本地仓库中去后，此时的B用户想要查看远程仓库中 A 用户修改解决好 Bug的代码，就执行了 pull 拉取远程仓库的操作(忘记了，应该先同步上远程仓库的代码，再在本地仓库修改内容)。这时，巧合的是A用户修改好Bug的代码刚刚好是和 B用户修改好Bug中的同一个文件同几行 代码的位置，但是内容却是不一样的。同一个文件同几行修改的位置，发生了冲突，我们的Git 不知道你想要的是哪个修改的内容。因为在同一个文件同几行的位置发生了(内容不一样的)修改。
解决方案
这个冲突和合并分支 时，发生的冲突(同一文件同几行位置是一样的所以解决方式是一样的
因为：远程分支也是分支，所以合并时冲突的解决方式也和解决本地分支冲突相同的
既然，我们的Git 不知道我们需要的是其中的哪一个修改内容，那我们自己做选择，手动修改自己需要的内容，来解决冲突
步骤如下：
-
处理文件中冲突的地方
-
将解决完冲突的文件加入暂存区(add)
-
提交到仓库(commit) 注意这时候的 commit 不可以指明 提交的冲突文件名，因为这时冲突中 我们的分支中存在两个一样的冲突文件，Git 它会说它又不知道你要提交的是哪一个文件了(报错)，所以我们干脆就全部提交上去，不然 Git做选择
- 处理文件中冲突的地方，打开冲突文件 text.txt，手动删除，修改保留你需要的内容，删除，其中的 `<<<<HEAD,====,>>>>>a3a3da0922 这些提示修饰符，如下：
- 将解决完冲突的文件加入暂存区(add)
- 提交到仓库(commit) 注意这时候的 commit 不可以指明 提交的冲突文件名，因为这时冲突中 我们的分支中存在两个一样的冲突文件，Git 它会说它又不知道你要提交的是哪一个文件了(报错)，所以我们干脆就全部提交上去，不然 Git做选择
6. 总结：Git工作流程图以及命令汇总讲解
Git工作流程图
注意我们的 Git 命令需要在含有 .git 文件中打开执行
Git常用命令总结如下：
- git init ：初始化本地库
- git status： 查看本地库状态
- git add 文件名： 添加暂存区(被Git追踪到) 使用通配符 *.xxx后缀的文件，
.全部文件 - git commit -m “日志信息” 或文件名 : 暂存区中的文件提交到本地仓库，通配符 *.xxx后缀的文件，或不写文件名表示全部暂存区中的文件提交到本地库中
- .gitignore ： 设置省略的文件
- git reflog/git log：查看提交本地仓库的信息，历史版本编号，当前head指针,当前分支
- git reset --hard 历史版本编号： 历史版本穿梭(版本回退)
- git branch -v/ git branch：查看本地分支
- git branch 分支名：创建分支
- git checkout 分支名：切换分支
- git merge 合并的分支名：合并分支内容
- git branch -d 分支名/git branch -D 分支名：检查删除分支/强制删除分支
- git remote add <远程仓库链接的别名> <远程仓库的链接URL>：创建远程仓库在本地仓库的链接别名
- git remote ： 查看远程仓库链接的别名
- git push 远程仓库链接/远程仓库链接的别名 分支名：将本地仓库中的内容推送到远程仓库中去
- git pull 远程仓库的链接/远程仓库链接的别名 远程仓库的分支名：将远程仓库中的内容同步到本地仓库中，时刻保证远程仓库的内容同步到本地仓库 ，相当于
fetch+merge的两步操作 - git fetch 远程仓库链接或远程仓库链接别名 分支名：抓取远程仓库中的内容到本地仓库当中，不合并远程仓库分支内容。需要自己手动合并。
- git clone 远程仓库的链接：将远程仓库中所有的内容克隆到本地仓库中，初始化仓库，提交本地仓库，创建目录
- push 的内容需要先存在于本地仓库中，才可以push 到，修改远程仓库的代码，先pull 同步上,再修改本地仓库中的内容，在push 到远程仓库，防止冲突的发生。
- 注意：push 是将本地库代码推送到远程库，如果本地库代码跟远程库代码版本不一致push 的操作是会被拒绝的。也就是说，要想 push 成功，一定要保证本地库的版本要比远程 库的版本高！因此一个成熟的程序员在动手改本地代码之前，一定会先检查下远程库跟本地 代码的区别！如果本地的代码版本已经落后，切记要先 pull 拉取一下远程库的代码，将本地 代码更新到最新以后，然后再修改，提交，推送！
- 对于你
省略列表的配置，需要先提交到commit 到本地仓库中，才有效果不然，该配置的是无效的。
7. 最后:
限于自身水平，其中存在的错误，希望大家可以指教，韩信点兵——多多益善，谢谢大家，后会有期，江湖再见 ！！！
1877
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
