Git的使用与五大场景的运用

一、Git的基础
- 1、Git的基本运作流程
- 2、Git与SVN的不同
二、Git的操作与使用
- 1、Git的基本配置
  - (1) 安装Git
  - (2) 配置GitHub
- 2、Git的基本操作
三、Git的使用案例与心得

Git是版本管理工具的一种，是分布式的控制系统。之前用过SVN，它是中心版本控制系统，与Git有很大的不同，当今主流的版本控制都是用的Git，所以希望借此课程的机会，了解一下Git的使用。

一、Git的基础

1、Git的基本运作流程

(1) workspace->index->Repository

在本地写的代码都在workspace中，通过add指令暂存到index中，然后通过commit提交到本地仓库Repository中。如果有多位项目成员，则每个成员都对应一套本地仓库管理系统，各自写的代码互不干扰。这也就是分布式的体现，成员之间并行进行，互不干扰。

(2) checkout

可以切换Repository中的某个分支。这是版本控制的重要功能，在不同分支上工作。

(3) pull, push, fetch/clone

这是远端Remote与本地之间的数据同步操作。

2、Git与SVN的不同

可见SVN并没有本地的仓库，只有一个集中的服务器，所有同步操作直接与服务器进行，这意味着必须要联网才能查看历史版本信息，进行版本控制，而Git拥有本地仓库，本地即有全部的版本历史信息，如果没有网络，只需提交到本地仓库，之后再与Remote同步即可。

svn这种集中式十分依赖于中心服务器，缺点不言而喻。Git分布式有去中心化的特点，每个使用者都是平等的，每人都有一套完整的版本库，并且每个人的又有各自修改后写入的新代码。使用者之间可以比较交换，同步。SVN和Git的关系类似于C/S和P2P。

二、Git的操作与使用

1、Git的基本配置

Github, Gitee等云平台都是基于Git的，它担任一个托管代码的服务器的角色，但它与SVN中的服务器还是不一样，因为它们与各个主机之间的关系是平等的。

无论是使用Github还是Gitee都需要本地有个Git工具，当与云端服务器同步时，都需要Git与它们通信。

(1) 安装Git

先下载安装Git: https://git-scm.com/download;
配置用户名邮箱：

git config --global user.name "your_name"

git config --global user.email "your_email"
生成SSH Key：

ssh-keygen -t rsa -C your_email
查看Key：

open ~/.ssh

将查到的Key复制下来，这就是公钥，之后会用来配置GitHub/Gitee

(2) 配置GitHub

在GitHub->settings->SSH keys中，如图，粘贴进之前查看到的Key即可。此时Git便可以与Github通信，每次同步Github时不需要再登陆。

2、Git的基本操作

git init - - 初始化代码仓库
git clone - - 克隆远程仓库

PS:如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：

$ git clone git://github.com/schacon/grit.git mygrit
git add - - 把需要提交的所有修改放到暂存区（Stage）
- git add file – 提交指定文件
- git add . || git add -A – 提交所有文件
- git add *.js – 提交所有.js格式文件
- git add -f file – 强制添加
git diff - - 查看当前目录的所有修改(#当暂存区中没有文件时，git diff比较的是，工作区中的文件与上次提交到版本库中的文件。

#当暂存区中有文件时，git diff则比较的是，当前工作区中的文件与暂存区中的文)
- git diff HEAD - - file – 比较工作区中的文件与版本库中文件的差异。HEAD指向的是版本库中的当前版本，而file指的是当前工作区中的文件。
git commit -m “message” - - 提交代码
git rm - - 会把文件从当前目录删除（不会保存删除的文件）。如果需要从Git仓库中删除，但保留在当前工作目录中，亦即从跟踪清单中删除，可以使用git rm -r --cached readme.md

PS:如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
git log - - 查看历史记录，git log命令显示从最近到最远的提交日志
- git log --graph – 查看分支合并图
git reflog - - 用来记录你的每一次命令
git remote - - 查看当前的远程库
git remote -v - - 可以显示对应的克隆地址（对于多个远程仓库很有用）
git remote add [short_name] - - 可以添加新的远程仓库
git remote add origin < address > - - 关联一个远程库
git fetch [remote-name] - - 可以从远程仓库抓取数据到本地。
git pull - - 更新数据
git push [remote_name] [branch_name] - - 推送数据到远程仓库默认使用origin和master
git push -u origin master [-f] - - 第一次将本地库的所有内容推送到远程库上
git remote show origin - - 查看远程仓库信息
git remote rename [old_name] - - 远程仓库重命名
git remote rm [remote_name] - - 删除远程仓库
git branch -d < name > - - 删除本地分支
git tag - - 显示当前库中的标签
git branch - - 可显示当前所有分支。可以使用–merged和–no-merged查看已经合并、未合并的分支。
git branch <branch_name> - - 创建新分支
git branch -r - - 查看远程仓库分支
git checkout <branch_name> - - 切换到指定的分支
git checkout -b <branch_name> - - 创建新分支并切换到该分支
git merge 合并分支

举例：

将hotfix分支合并到master上需要：

git checkout master

git merge hotfix

合并之后可以使用git branch -d hotfix删除分支。

如果合并时存在冲突，需要手工修改

合并分支时，加上—no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
git checkout . --恢复上次提交状态
- git checkout --file - - 文件在工作区的修改全部撤销
- 一种是file修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
- 一种是file已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
git status – 用于显示工作目录和暂存区的状态。使用此命令能看到那些修改被暂存到了, 哪些没有, 哪些文件没有被Git tracked到。git status不显示已经commit到项目历史中去的信息。
git reset --hard HEAD^ - - #版本回退
- git reset --hard commitId - - 取消回退，commitId为你想要回到的未来版本号
- PS:Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，上一个版本就是HEAD，上上一个版本就是HEAD^，当回退版本较早时可以写成HEAD~100。
git stash - - 储藏可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中，随时可以重新应用。

现在你想切换分支，但是你还不想提交你正在进行中的工作；所以你储藏这些变更。为了往堆栈推送一个新的储藏，只要运行git stash。把所有未提交的修改（包括暂存的和非暂存的）都保存起来，用于后续恢复当前工作目录。

PS:需要说明一点，stash是本地的，不会通过git push命令上传到git server上。
git stash list - - 查看现有的所有储藏，此命令显然暗示了git stash可以多次保存工作进度，并用在恢复时候选择。
git stash pop [–index] [ < stash > ] - - 重新应用已经实施的储藏（删除储藏）
- 如果不使用任何参数，会恢复最新保存的工作进度，并将恢复的工作进度从存储的工作进度列表中清除。
- 如果提供< stash>参数（来自git stash list显示的列表），则从该< stash>中恢复。恢复完毕也将从进度列表中删除< stash>。
- 选项–index除了恢复工作区的文件外，还尝试恢复暂存区。
git stash drop [< stash >] - - 删除一个存储的进度。（默认删除最新的进度）
git stash clear - - 清空当前所有的stash
git stash branch < branchname > < stash > - - 基于储藏进度创建分支。

三、Git的使用案例与心得

1、场景一：在本地创建工程

在工程目录里使用：git init，便可初始化一个版本库

查看本地版本库的状态：

git status

如图，可以看到当前本地版本库与remote的库的同步情况（remote操作后面再讲）。
开始在本地添加工程文件：

git add HomeWork/Git使用心得体会.md

此指令会将文件放到暂存区（Index）中，如下图中的Staged Changes：
再提交到本地版本库（Repository）当中：

git commit -m "add HomeWork/Git使用心得体会.md"
版本控制初步：
- 假设有一个文件"git.md"，对它做了四次修改，第i次版本，会将里面内容改成"version i"，每次都对其提交。
用git log指令可查看提交记录：

现在欲将其恢复到版本2，则使用命令：git reset --hard HEAD^^ 其中HEAD指向当前分支最新提交的一个版本，一个^{代表回退一个版本，两个}即可回退到version 2。该指令有多种切换方法：

git reset —hard HEAD^^/HEAD~100/commit-id/commit-id的头几个字符
- 此时若要返回至version 4，则需要查看commit-id，可使用：git reflog，之后再使用reset指令即可。
- 所以这么看下来，很像是链表操作，HEAD即指针，可移动其切换版本。

2、场景二：与远程版本库进行交互

因为Git是分布式的，成员各自编写的代码都在本地仓库，最终完成一个工程肯定要统一合并，一般都合并到GitHub之类的服务器端。但因为写代码，彼此之间并不知道对方写了什么，改了什么，增加了什么，所以在合并时，势必会有冲突，所以最好是先拉取GitHub的内容与自己的合并，再提交到GitHub，以减少冲突，但仍然不能完全避免冲突。

先将远程仓库拉取下来（fetch/clone 或 pull）

如果第一次，自然是fetch/clone。否则，需要和远程同步时，则先需要pull，可以使用git pull [远程仓库名] [要拉取的分支]
再进行push

如果直接push，冲突概率很大，因为在你编写代码的时候，同事提交它修改的代码，而你的写的和他的就可能有很大不同。所以要先pull，因为远程仓库里的东西，是一段时间后“达成的共识”，将它拉取下来基本没错，因为它是在比较过提交的各方的代码之后确定下来的暂时版本。拉取下来之后，也可能会有冲突，自己在本地进行修改，解决冲突部分，这样也不会因为直接提交到远程，导致远程的代码混乱，使得各个成员也失去了一个标准参照的版本。
push即是merge远程和本地两个不同的分支

注意：同一分支里的某个版本实际上是对上一个版本的增量补丁，即记录不同行对比的差异(line diff)。

3、场景三：团队协作

团队的每个成员都各自负责不同的某一个功能块，各占一个分支，各自在本地有一个仓库，有自己的master和branch，branch下可以有更多的branch，最后成员完成时，将自己的分支合并到自己的master，再提交到服务器端。

合并的分类

(1) 快进式合并

这个在合并的时候会将分支和主线合并成一条时间线，如图：

(2) 相对应的，要体现多条分支，须使用：--no-ff参数

比如：git merge --no-ff mybranch
截取一段分支合并图，可见，很像一个有向无环的活动图。带箭头的有向边相当于活动，图中的点相当于事件，或者说是一个版本。在多人合作当中，可以并行进行，但效率取决于关键路径的长短，即如果有人进度落后，是不能按时合并成一个期望的版本的。

4、场景四：GitBase

本地与服务端的同步，即pull再push，pull实际上就是将两个分支（本地分支和服务器分支）merge，这就会表现出两条分支线：

实际上可以用另外一种方法，让分支历史看起来像没有经过任何合并一样，用 git rebase:

gitbase的原理：

这个命令会把"mywork"分支里的每个提交(commit)取消掉，并且把它们临时保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新为最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。当"mywork"分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。
冲突的解决：

在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决冲突；在解决完冲突后，用git-add命令去更新这些内容的索引(index), 然后，无需执行git -commit, 只要执行:

git rebase --continue

这样git会继续应用(apply)余下的补丁。

在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。

git rebase --abort

5、场景五：Fork + Pull request

如果向开源项目贡献代码，则需要先fork一下别人的仓库（即拷贝），当写完自己的代码后，发起Pull request给原仓库，原仓库的所有者来决定要不要merge进去。

例如，在github上fork一个gitignore项目，里面有很多写好的.gitignore文件：
之后便看到这个仓库进了自己的，如果自己有添加或修改了代码，可以点击Pull request：
提交之后，在原仓库的Pull request里看到提交的请求：

参考链接：

https://blog.csdn.net/weixin_43606158/article/details/90729743

https://blog.csdn.net/hudashi/article/details/7664631/