Git学习心得

早在本科阶段，我就想系统地学习一下Git分布式版本控制系统，但无奈没有教授这门课的老师，也没有相关的开发经历，于是这就成了我本科阶段的一个遗憾。在研一上学期我有幸学习了孟宁老师教授的高级软件工程，让我学会了如何使用Git进行协同开发，在此表示衷心的感谢！此博客也是基于孟老师的文章所编写：https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg 。

众所周知，Git 是一种分布式版本控制系统，而且是目前世界上最先进的分布式版本控制系统（没有之一），主要在多人协同合作时用于版本控制。

Git 的基本操作：

 

 

 

本地仓库Repository，存在于项目根目录下.git文件夹中，内部可能有多个 branch，但至少有一个叫 master的branch。本地仓库中的某个branch被checkout到当前workspace，就能在当前源代码目录中看到一份完整的源码，这份完整的源代码就是workspace。

在workspace中新增文件或修改文件，只有完成add和commit两步操作才能将新增或修改的文件纳入本地仓库的存储库中进行版本管理。add和commit两步操作中间Index索引数据应该也是和本地仓库一样存在项目根目录下.git目录中。

那Git是怎么做到分布式的呢？ 

本地仓库中的branch与一个或多个远程仓库（上图中的Remote）中的 branch存在跟踪关系，这样就构成了Git分布式版本控制的网状结构。他们之间的数据同步操作有clone、fetch、push、pull。

Git有不同的应用场景，现在来进行一一演示。

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

首先初试化一个本地版本库，利用gitBash在项目根目录下新建一个.git文件夹，代码如下：

git init

 

 

 

 

该文件夹初始化的目录结构如下图所示：

 

 

 

 

查看当前workspace状态：

 git status

 

 

 

 

新建一个file1.txt文件，将其添加到缓存区：

git add file1.txt

 

 

 

 

把暂存区里的文件提交到仓库主要使用git commit命令，但是还会涉及撤销提交和查看日志的命令：

git commit -m "wrote a commit log infro"

 

 

 

 

将版本拉回至现在：

git reflog

 

 

 

 

至此，Git本地仓库的用法就讲解完了。

 

 

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

首先在GitHub官网上新建一个仓库，然后在GitBash上将远程仓库克隆到本地:

git clone https://DOMAIN_NAME/YOUR_NAME/REPO_NAME.git

 

 

 

 

这里使用git clone之后默认的分支，即远程为origin/master 和本地 master，没有创建其他分支。管理本地版本库跟踪的远程存储库的命令为:

git remote

 

 

 

 

使用git remote -v 可以查看更详细的远程存储库信息，包括fetch（抓取）的远程存储库URL和push（推送）的远程存储库URL。

 

 

 

 

现在我们开始项目的开发工作，在test目录下创建一个file1.txt里面内容为“你好，这里是李港！”。

 

 

 

 

使用add命令将file1.txt文件提交到本地暂存区：

git add file1.txt

 

 

 

 

使用commit命令将file1.txt文件提交到本地仓库：

git commit -m "[add]create file1.txt file."

 

 

 

 

可以使用git status命令查看现在工作空间中已经没有东西可以提交，使用git log能够看到本次提交的记录。

 

 

 

 

最后一步使用如下命令将这次提交推送到远端，然后就能在远端仓库看到这一次的开发成果了：

git push

在我们git push之前需要和远程仓库建立连接，要输入我们需要连接的仓库所有者的email和name:

 

 

 

 

 

 

到GitHub官网上查看仓库test，file1.txt添加成功！

 

 

 

 

至此，场景二的效果也已经演示成功了。

 

场景三 团队项目中的分工合作

有了前面的基础知识和技能之后，我们可以考虑更复杂一些的团队项目合作的工作流程。如果团队项目像场景二的方法一样多人同时向远程origin/master分支频繁提交代码，一来可能会有诸多冲突合并的情况发生；二来整个git log提交记录中多个开发者或多个代码模块的commit是交错排列在同一条时间线上，不利于回顾查看和回退代码，让跟踪代码的成长轨迹变得异常困难。

我们需要考虑新的方式来能够独立维护不同的开发者或者不同的功能模块的代码，让一段连续的工作在commit日志的时间线上呈现为一段独立的分支线段，只在关键节点处进行分支合并。

基于以上想法我们建议团队项目的每一个开发者都采用的工作流程大致如下：

1. 克隆或同步最新的代码到本地存储库；
2. 为自己的工作创建一个分支，该分支应该只负责单一功能模块或代码模块的版本控制；
3. 在该分支上完成某单一功能模块或代码模块的开发工作；
4. 最后，将该分支合并到主分支。

 

首先，如果使用Git命令的创建分支：

git checkout -b mybranch

然后使用git branch查看分支列表，如下所示mybranch前面有一个*代表当前工作区处于mybranch分支：

git branch

 

 

 

 

要将当前工作区切换到master分支只需要如上所示使用git checkout master命令：

 

 

 

 

使用如下Git命令合并mybranch分支到当前的master分支:

git merge mybranch

 

 

 

 

如果要保留mybranch分支为一段独立的分支线段，则需要使用--no-ff参数关闭"快进式合并"（fast-farward merge），Git命令如下:

git merge --no-ff mybranch

 

 

 

 

 

场景四 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节点。

 

新建两个txt文件分别命名为a和b， 先将他们提交到缓存区再提交到本地仓库：

 

 

 

 

使用git log 查看提交记录，发现a和b的提交记录都在：

 

 

 

 

 

 

使用git rebase 命令丢弃一次提交,删除log中a那行即可。

 

 

 

至此，第四种应用场景我们也演示完毕了。

 

最后再次感谢孟宁老师上课时的认真讲解，给了我这么珍贵的学习机会。我一定会更加努力学习，再接再厉！