Git实战演练与使用心得

Git实战演练与使用心得

以前听说过git是一款强大的版本控制工具，但自己也只是简单的了解一些，并没有深入的对其进行学习。在研究生阶段的第一学期的学习中很幸运地选到了孟宁老师的高级软件工程，孟宁老师的课程一改以往软件工程课程的千篇一律，在课程的前期教授了我们一些程序员工作中必会的技能与知识，Git就是其中一项。本文正是基于孟宁老师的课堂的讲解以及孟宁老师的文章。
参考文献：https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg

Git 基本操作

Git 常用的是以下 6 个命令：git clone、git push、git add 、git commit、git checkout、git pull，本文也正是对这些指令进行的解释与操作。如下图片可以帮助你更好的理解各个命令间的关系。

场景一：Git 本地版本库的基本用法

git init: 初始化一个本地版本库

要建立一个本地版本库版本库首先要有一个存储本地版本的文件夹，切换至我们要建立版本库的文件夹。

为了将该目录作为我们的本地本版库，我们需要执行

git init

此时在当前目录下创建了.git目录，这个目录是Git来跟踪管理版本库的。

git status: 查看当前工作区（workspace）的状态

首先在目录下创建一个txt文件

touch test1.txt
git status

此时显示当前工作区的test1.txt未被追踪。

git add [FILES]: 把文件添加至暂存区

执行如下命令

git add test1.txt
git status

此时test1.txt已被提交至暂存区，但未被提交。

git rm --cached : 回退到未添加文件到暂存区时的状态

执行如下命令

git rm --cached test1.txt
git status

此时test1.txt为未被追踪状态

git commit -m "wrote a commit log info": 把暂存区里的文件提交到本地仓库，后面是备注信息

执行如下命令

git commit -m "第一次提交test1.txt"
git status

此时test1.txt已被提交至本地仓库。

-a 参数设置修改文件后可以直接提交跟踪过的文件，不需要执行git ad 命令，直接来提交。但第一次创建的文件要执行add操作。

git log： 查看当前HEAD之前的提交记录，便于回到过去

执行如下命令

git log

可以看到之前提交test1.txt的记录，以及提交时所写的备注信息。

git reset [--soft | --mixed | --hard] [HEAD]： 用于回退版本

--mixed 为默认，可以不用带该参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。
修改并添加test1.txt，执行

git reset test1.txt

此时之前的add失效，文件为未添加状态。

--soft 参数用于回退到某个版本：
首先修改test1.txt添加一些信息，提交到本地仓库

执行如下命令

git reset test1.txt

此时修改test1.txt的操作被撤回。

--hard 参数撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交：
首先修改test1.txt添加一些信息，提交到本地仓库

执行如下命令

git reset --hard HEAD^

此时修改test1.txt的操作被撤回且删除回退点之前的所有信息。

git reflog: 可以查看当前HEAD之后的提交记录，便于回到未来

执行如下命令

git reflog

可以查看当前HEAD之后提交的记录。

场景二：Git 远程版本库的基本用法

git remote: 用于在远程仓库的操作

首先在Github上创建一个远程仓库，并创建本地库。

执行如下指令添加远程仓库，其中origin为你为远程仓库起的别名

git remote add origin git@github.com:hzgonlgan/test.git

执行如下指令用于显示所有远程仓库

git remote -v

git push: 用于从将本地的分支版本上传到远程并合并

命令格式如下（如果本地分支名与远程分支名相同，则可以省略冒号）

git push <远程主机名> <本地分支名>:<远程分支名>
git push <远程主机名> <本地分支名>

执行如下指令，新建一个文件并向远程仓库推送

touch test.txt
git add test.txt
git commit test.txt '第一次提交test.txt'
git push origin master

可以看到远程仓库收到了之前的推送。

git clone: 拷贝一个远程仓库到本地，让自己能够查看该项目，或者进行修改

切换到另一个目录执行如下克隆操作

touch test.txt
mkdir clone
cd clone
git clone git@git.zhlh6.cn:hzgonlgan/test.git

可以看到成功在当前目录下克隆到了之前的远程仓库的项目。

git pull: 从远程获取代码并合并本地的版本

在之前克隆的仓库中修改test.txt，并推送到远程仓库

切换至test目录，执行如下指令从远程仓库获取此前修改后的版本

git pull origin

可以看到本地仓库以获取到克隆仓库推送的修改

git fetch: 命令用于从远程获取代码库

首先在克隆仓库下再次修改test.txt文件，并推送到远程仓库

在此前的本地仓库执行

git fetch origin master
git log

此时该本地仓库并没有显示此前的第二次提交修改

再执行

git merge origin/master

此时显示此前的第二次提交修改

场景三：团队项目中的分叉合并

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作，进而加快开发进程。

git branch [-v]： 查看分支（-v可以显示该分支最后一次提交的信息）

执行

git branch
git branch -v

可以看到当前的分支信息，现在只有默认创建的master分支。

git branch (branchname)： 创建分支

执行如下命令新建分支

git branch testing

再次查看分支可以看到testing分支被创建。

git checkout (branchname)： 切换分支

执行如下命令

git checkout testing

此时已切换到testing分支

我们也可以使用如下命令

git checkout -b (branchname) 

来创建新分支并立即切换到该分支下，从而在该分支中操作。

git merge (branchname): 合并分支

要切换到接受修改的分支上，然后进行合并，执行如下命令

git branch
git checkout master
git merge testing
git log

可以看到master分支合并了testing分支，添加了a.txt。

git branch -d (branchname): 删除分支

被合并的分支如果没有后续的用途可以删除，执行如下命令

git branch -d testing
git branch

可以看到testing分支已被删除

合并冲突：合并并不仅仅是简单的文件添加、移除的操作，也会合并修改。

我们新建一个分支change，并修改a.txt，再将其合并到mater分支，命令如下

git branch change
vim a.txt
git add a.txt
git commit -m '修改a.txt'
git branch master
vim a.txt
git commit -am '修改a.txt'
git merge change

此时合并发生冲突

此时要编辑文件，把文件修改到预期，保存退出并添加提交冲突文件。

vim a.txt
git commit -am '修改a.txt'

现在我们成功解决了合并中的冲突，并提交了结果。

场景四：Git Rebase

Git Rebase，就是mybranch分支上完成自己的工作之后，为了让log记录将来更容易回顾参考，用git rebase重新整理一下提交记录。但是不要通过rebase对任何已经提交到远程仓库中的commit进行修改。git rebase可以帮助项目中的提交历史干净整洁！！

git rebase -i [startpoint] [endpoint]：同于合并日志

其中-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支的HEAD。 一般只指定[startpoint] ，即指定从某一个commit节点开始，可以使用HEAD^^、HEAD~100、commit ID或者commit ID的头几个字符来指定一个commit节点，比如下面的代码指定重新整理HEAD之前的三个commit节点。

进行三次commit,然后执行rebase操作

$ echo 1 > a.txt
$ git commit -am  "master修改a.txt 1"
$ echo 2 >> a.txt
$ git commit -am  "master修改a.txt 2"
$ echo 3 > a.txt
$ git commit -am  "master修改a.txt 3"
git rebase -i HEAD^^^

可以看到

对提交信息进行修改

最后的提交信息，可以看到三次提交被合并成一次

git rebase (branchname): 用于合并分叉

它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 experiment）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支master）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 experiment 的提交历史，使它成为master分支的直接下游

master分支的log结构

test分支的log结构

执行

git reabase master

可见目录结构为线性

若通过merge合并分支则会出现分叉

场景五：Fork + Pull request

为了解决开源社区松散团队的协作问题，Github提供了Fork+ Pull request的协作开发工作流程。
当你想更正别人仓库里的Bug或者向别人仓库里贡献代码时，要走Fork+ Pull request的协作开发工作流程：

1.先 fork（分叉） 别人的仓库，相当于拷贝一份；
2.做一些 bug fix或其他的代码贡献；
3.发起 Pull request 给原仓库；
4.原仓库的所有者 review Pull request，如果没有问题的话，就会 merge Pull request 到原仓库中。

在Github上，fork别人的一个库到我们自己的账户

点击Pull request可以看到我们对其进行的修改

点击Create pull request按钮即跳转到原仓库，即可审核变更信息进行pull request。