Git

一、 Git概述

(1) 分布式版本控制VS集中式版本控制

1. 集中式版本控制

CSV, SVN（Subversion）, VSS都是有一个集中管理的服务器，保存所有的文件修订版本。协同工作的人从服务器取出最新的文件，在此基础上修改并提交更新。

但是，如果服务器突然挂了，就会导致两种糟糕的情况

1. 每个人手里的代码都是最新的版本，如果服务器修复后发现代码全没了，那么之前的版本标记都会消失，如果想回到之前的版本就回不去了。
2. 如果更新很多功能，但是在本地没办法做很多版本标记，直接将多次修改后的结果上传到服务器会导致代码难以维护。

2. 分布式版本控制

Git, Mercurial, Bazaar, Darcs…都是分布式版本控制器。有一个远程的代码托管中心，类似于集中式版本控制中的服务器，上面存着每次版本修改的记录和代码，保留有最新版本的代码。每个工作人员从远端将代码download下来以后在本地操作。

Git的优势就是可以在本地进行版本控制，做各种修改的版本标记，上传远端时将本地代码修改的版本标记也上传，方便代码维护。

如果遇到代码托管中心（服务器）挂了呢？

1. 首先，这些代码托管中心都是专门的大公司在维护，一般不会挂
2. 就算挂了，每个人可以在本地办公，并做版本控制标记，上传远端时注意代码处理与他人代码的冲突即可。
3. 如果托管中心的代码没了，每个人手里都有带着完整的代码版本控制标记的代码库，再上传到远端即可。

(2) Git的工作机制

工作区==》 写代码

在本地没有修改代码，不会留下记录
写完后想进行版本更新，需要首先提交到暂存区

暂存区==》 临时存储

暂存区临时存储修改过的代码，不满意可以直接删除，不会留下版本记录
想进行版本更新，推送到本地库即可

本地库==》 历史版本

代码一旦到了本地库，就会进行版本更新标记，这个标记是没办法删除的，会体现在版本分支中（除非删除整个本地库，重新拉取远端仓库中的代码）
下一步就是将代码push到远端仓库中

(3) 代码托管中心

代码托管中心是基于网络服务器的远程代码仓库，又称远端仓库，远程库

互联网（大部分开源）

GitHub （外网）
Gitee （码云，国内网站）

局域网（不开源）

GitLab

二、 Git基本命令

桌面右击，选择Git Bash here打开git

1. Git版本查看

git --version
1

2. 设置用户

设置用户签名，与登录github等没有关系，只是用于区分修改代码的windows用户

设置用户签名（如果不设置，之后提交代码会报错）

git config --global user.name 用户名
1

设置用户邮箱

git config --global user.email 邮箱
1

用户签名设置好后，可以用记事本打开.gitconfig文件查看

C盘/用户/26326（本地用户名）/.gitconfig

文件中的内容如下，则设置成功

3. 初始化本地库

新建一个目录，在目录中右键打开Bash，Bash会自动跳转到当前目录地址下

git init
1

此时发现出现一个文件夹

在Bash命令行中可以通过Linux命令行查看文件夹

查看文件目录

ll
1

好嘛，啥也没有，被隐藏起来了

查看隐藏文件目录

ll -a
1

文件目录的结构就展现出来了，可以再跳转到.git里看看

cd .git
1

ll
1

查看完重新回到.git所在的文件夹（即上一层）

cd ..
1

4. 查看本地仓库状态

查看仓库装态

git status
1

一开始什么都没有

创建一个hello.txt

vim hello.txt
1

点击i，输入内容，:wq退出并保存
再查看仓库状态，分支还在master，也没有任何提交，但是工作区出现了红色的hello.txt文件，提示该文件还没有被追踪。

5. 提交暂存区

提交到暂存区

git add hello.txt
1

再次查看状态，提示暂存区有为提交至本地库的内容。

删除暂存区命令

git rm --cached hello.txt
1

查看当前目录下的内容

ll
1

再次查看状态，发现工作区的hello.txt还没有被提交至暂存区（还没有被追踪）。

6. 提交本地仓库

将工作区内容提交至暂存区后，再提交至本地仓库

git commit -m "日志信息" hello.txt
1

再次查看状态发现，提示没有可提交的内容

修改一下hello.txt

vim hello.txt
1

再次查看状态，发现提示hello.txt被修改，且该内容未被提交至暂存区追踪

添加至暂存区，然后再次查看，提示将用CRLF格式换行符替换LF格式换行符。

7. 版本穿梭

多进行几次修改并提交至本地仓库，生成多个版本后就可以开始版本穿越了。
所谓版本穿越就是回到之前版本的代码进行操作
首先查看当前版本信息

git reflog
1

当前有三次提交的版本记录，目前head->master->“third commit”，当前在第三次提交版本大的master分支。

用如下命令查看更详细的版本信息（包括提交者和提交时间）

git log
1

查看当前内容，即thrid commit的内容

穿梭回"second commit"

git reset --hard “second commit的地址”
1

再次查看，发现hello.txt的内容也回到了第二次提交时的内容

同理回到版本first commit查看，内容同样发生了改变

三、 Git分支操作

(1) 分支是什么

在多人协同工作时，每个人拥有一个自己的分支进行修改，不会影响主线分支上的使用，也不会影响其他分支的修改，完成一个功能后合并到主线分支或者合适的分支即可，方便多人协同操作。

好处：

1. 方便多人协同工作
2. 开发失败了，可以直接删除分支重新开始

(2) 分支操作

1. 查看分支

查看分支

git branch -v
1

2. 创建分支

git branch 分支名
1

3. 切换分支

将分支从master切换到hot-fix分支

git checkout hot-fix
1

4. 修改分支

切换到对应的分支进行修改即可

vim hello.txt
1

修改了hot-fix分支
提交到本地仓库

4. 合并分支

注意分支合并命令是将目标分支合并到当前分支，即需要将分支切换回当前分支，然后将目标分支合并到当前分支

git merge 目标分支名
1

可以看到分支合并成功，此是查看合并后结果

修改成功，此处这么顺利是因为只对一个分支某一行进行了修改，合并时直接将修改内容加入master分支即可。
但是，如果出现同一行在两个分支都进行了修改怎么办，如何修改呢？

5. 解决合并冲突问题

我们对master和hot-fix的同一行进行不同的修改，尝试合并
修改hot-fix分支，并提交到本地库

切换回master分支，做一些修改，并提交到本地库

此时在master分支将hot-fix分支合并

git merge hot-fix
1

由于在同一行进行了不同的修改，程序不知道如何取舍，此时合并失败，分支的状态进入了MERGING正在合并状态。

查看分支状态，提示两分支均进行了修改

此时用vim打开冲突的代码，自行修改

vim hello.txt
1

可以看到冲突部分被标记了出来，并且在将两个分支中的冲突部分分别显示

自行修改该部分后保存

保存后退出，并提交至本地库

这里需要注意，如果在MERGING状态下合并分支，不能在命令之后加分支名，否则会报错

git commit -m "备注" （不能加分支名）
1

正确修改后查看修改结果

合并成功

四、 Git团队协作机制

(1) 团队内协作

偷图理解：
岳不群和令狐冲是同一个团队的两人。
岳不群写了一个项目，push到远端仓库，令狐冲从远端clone到本地，进行了一些修改然后再次push到远端，这时团队内的人都可以看到令狐冲的修改。

(2) 跨团队协作

岳不群和令狐冲是同一个团队的成员，而东方不败属于另一个团队。如果有一天东方不败看到岳不群团队的项目，觉得他写的非常菜，想帮帮他们随便改改。
step1: 东方不败将岳不群的仓库fork出一份，给自己新建一个仓库
step2: 东方不败从远端仓库clone到本地修改，然后提交到自己的远端仓库。或者够强的话，直接在远端仓库进行修改
step3: 东方不败想把自己修改的超级牛B的代码发送给岳不群看看，于是她给岳不群发送了一个Pull request。
step4: 岳不群收到Pull request请求之后，先审核一下，发现这个东方不败的代码确实技术风骚，于是将代码merge进自己的分支，成为自己的代码。


整体上看，这就是东方不败和岳不群团队的跨团队协作。

五、 GitHub操作

(1) 准备工作

首先随便创建一个163邮箱
再利用邮箱创建一个github账号

(2) 创建远程仓库

(3) 远程仓库操作

1. 创建远端仓库别名

刚开始查看当前所有远程地址别名，发现还没有

git remote -v
1

找到远程仓库的https地址，创建仓库别名

git remote add 别名 仓库https地址
1

再次查看发现，仓库别名创建成功

git remote -v
1

（fetch） 用来拉取远端程序（pull，clone）

（push） 用来将本地修改推送到远端仓库

2. 推送本地分支到远端仓库

git push 别名 分支
1

如果输入别名错误，远端找不到该仓库，会报错

由于github的服务器在外网，容易访问失败，push失败的话，多试几次

终于成功啦！试了十几次。。。



push成功后就可以在远端master分支上看到本地仓库的master分支代码

3. 克隆远端仓库到本地

由于只有一台电脑，利用多个本地仓库模拟多个用户
新建一个文件夹作为FH_FE的本地仓库

同理新建一个wushiyi-1和一个wushiyi-2,作为令狐冲和东方不败的本地仓库

在wushiyi-1下打开Bash,clone远端仓库

git clone 远端https地址
1

又是无数次的拉取失败

终于成功啦！泪目！

wushiyi-1中有了远端的仓库代码

跳转到仓库目录下，查看远端别名为origin

4. 邀请加入团队与提交到远端（push）

令狐冲（wushiyi-1）可以clone我的仓库，却不能将他的修改提交到远端，因为这需要我的认可，首先我要同意他加入我的团队，作为我的弟子。

1. 邀请合作者
   
   输入wushiyi-1找到该用户
   
   发送邀请
   
   
   登录wushiyi-1的github后查看邀请
   
   并接受邀请，即可加入团队
   
   此时wushiyi-1已经加入了FH_FE的团队，可以在本地进行修改，并提交到远端仓库
   
   将修改后的内容提交到暂存区和本地仓库，并push到远端。
   注意push时，wushiyi-1的仓库别名是origin

git push 远端别名 分支
1

此时在远端仓库可以看到最后是wushiyi-1提交的代码

5. 拉取远端库内容（pull）

FH_FE觉得wushiyi-1写的很可爱，迫不及待的将她的代码拉取到本地合并更新

git pull 远端别名 远端分支
1

拉取成功后，本地的master被远端master替换

6. 跨团队协作

wushiyi-2觉得FH_FE代码写的很烂，决定修改一下，但是wushiyi-2又不愿与目前这么菜的FH_FE在同一个团队中，于是她想来个跨团队协作。

1） wushiyi-2找到FH_FE的仓库，fork了一份到自己的仓库
FH_FE是真的菜，写的仓库混迹在一堆仓库中，一时不知道哪里去找，只能自己把https地址发给wushiyi-2
wushiyi-2登录github后将FH_FE的仓库网址进行一个搜索，然后fork到自己的仓库


此时fork得到的仓库的所有人（owner）是wushiyi-1

wushiyi-2这种优秀得让FH_FE配不上得女孩纸，直接在线编辑了仓库中得文件

修改内容

提交到仓库，并留下版本标记

上面wushiyi-2完成了在自己仓库中的修改，想让FH_FE接受自己的修改建议，先创建一个pull请求



到这里就完成pull请求的创建，还发现了github的聊天交流功能

此时回到FH_FE的github查看pull request请求

FH_FE坚定的回复wushiyi-2

FH_FE检查了一下，修改的非常好，采纳了，将代码merge到FH_FE的代码中合并

此时代码合并完毕

7. SSH免密登录

除了每次通过网页登录push代码到远端，还可以利用SSH地址进行访问。

(1) 删除用户当前的.ssh文档
打开 C:/用户/26326/，如果存在.ssh，则之前存在密钥，将其删除重新生成一次

也可以直接利用命令行删除，在FH_FE的本地库打开Bash，输入cd回到家目录，输入命令删除.ssh

rm -rvf .ssh
1

重新生成密钥

ssh-keygen -t rsa -C FH_FE的github的注册邮箱
1

三次回车之后，出现如下界面，密钥生成成功

查看密钥

cd .ssh
1

或者在 C:/用户/26326/直接查看

将公钥复制

随便写个title将公钥复制进去

出现如下界面，则添加成功

测试一下ssh传输怎么样

在FH_FE本地仓库打开Bash,首先查看hello.txt，还看不到wushiyi-2的修改

利用SSH密钥拉取wushiyi-2修改的内容

git pull SSH密钥 要拉取的分支
1

如果失败了就再试一次，我这里感觉SSH要快很多

再次查看，可以看到wushiyi-2的修改

再做一些修改试试SSH的push

对hello.txt进行修改，并提交至本地仓库

利用ssh密钥push到远端

git push SSH密钥 要push的分支
1

感觉真的快了许多

在远端仓库刷新检查一下，发现push成功

六、 IDEA集成Git

等我学了Java再说