Git使用心得
Git使用心得
本文基于孟宁老师文章所编写：https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg
Git简介
Git是目前世界上最先进的分布式版本控制系统。分布式版本控制系统与集中式版本控制系统有何不同呢分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
Git使用的五大场景
场景一：Git本地版本库的基本用法
VS Code附带了Git，我们可以直接在VS Code中使用Git。
初始化一个本地版本库
在 VS Code中打开文件夹，实际上就是打开一个项目工作区，也就是项目中的整套源代码。打开文件夹后，在项目根目录下执行git init命令即可以完成初始化一个Git本地版本库。
git init
打开源代码管理（Ctrl+Shift+G），可以看到当前workspace的状态。以绿色U标记的文件为没有添加到版本库进行跟踪的文件、以橙色M标记的文件为已修改未提交的文件。
在命令行下执行git status同样能达到此效果。
git status
暂存更改的文件
在命令行中执行git add FILES，是将更改的文件加入到【暂存的更改】列表里；执行git checkout -- FILES / git checkout . ，是将文件中的更改清除掉。
git add FILES # 指定文件或文件列表
git add . # 用“.”表示当前目录
上述命令将特定文件添加至暂存区。
git reset HEAD FILES # 指定文件或文件列表
git reset HEAD
如上两行命令是取消将特定文件（FILES）或者所有文件添加到暂存区（Index），即从暂存区（Index）中删除；只有在暂存区登记的文件才会在提交代码时存入版本库。
git checkout -- FILES # 不要忘记“--” ，不写就把FILES当分支名了
git checkout .
如上两行命令的效果是放弃特定文件（FILES）或者所有文件的修改，实际上重新检出特定文件（FILES）或者所有文件到工作区（workspace），注意会覆盖掉已修改未暂存的内容，不希望被覆盖的文件可以先使用git add将其添加到暂存区。
把暂存区里的文件提交到仓库
把暂存区里的文件提交到仓库主要使用git commit命令。
git commit -m "wrote a commit log infro"如上命令可以把暂存区里的文件提交到仓库。
git log如上命令可以查看提交日志，可以看到当前 HEAD 之前的所有提交记录。
退到任意一个版本，比如HEAD表示HEAD的前一个版本、HEAD^表示HEAD的前两个版本、HEAD~100表示HEAD的前100个版本，也可以用版本号字符串来指定任意一个版本。
综上所述，将场景一的命令做个总结如下
git init # 初始化一个本地版本库
git status # 查看当前工作区（workspace）的状态
git add [FILES] # 把文件添加到暂存区（Index）
git commit -m "wrote a commit log infro” # 把暂存区里的文件提交到仓库
git log # 查看当前HEAD之前的提交记录，便于回到过去
git reset —hard HEAD^^/HEAD~100/commit-id/commit-id的头几个字符 # 回退
git reflog # 可以查看当前HEAD之后的提交记录，便于回到未来
git reset —hard commit-id/commit-id的头几个字符 # 回退
场景二：Git 远程版本库的基本用法
通过git clone命令，将版本库克隆到本地完成本地版本库的初始化。git clone命令的用法如下：
git clone https://DOMAIN_NAME/YOUR_NAME/REPO_NAME.git
这里使用git clone之后默认的分支，即远程为 origin/master 和本地 master，没有创建其他分支。管理本地版本库跟踪的远程存储库的命令为git remote。使用git remote -v 可以查看更详细的远程存储库信息，包括fetch（抓取）的远程存储库URL和push（推送）的远程存储库URL。
对于一个单人项目，要么在本地提交代码到仓库，要么通过Web页面更新远程仓库，而且这两种方式不会同时发生。不管是在本地仓库还是远程仓库，对代码修改之前都首先进行代码同步操作，防止产生分叉和冲突。
-
git clone命令官方的解释是“Clone a repository into a new directory”，即克隆一个存储库到一个新的目录下。
-
git fetch命令官方的解释是“Download objects and refs from another repository”，即下载一个远程存储库数据对象等信息到本地存储库。
-
git push命令官方的解释是“Update remote refs along with associated objects”，即将本地存储库的相关数据对象更新到远程存储库。
-
git merge命令官方的解释是“Join two or more development histories together”，即合并两个或多个开发历史记录。
-
git pull命令官方的解释是“Fetch from and integrate with another repository or a local branch”，即从其他存储库或分支抓取并合并到当前存储库的当前分支。
在本地版本库基本用法的基础上，只需要用推送（git push）和拉取（git pull）就完成本地仓库和远程仓库的同步。但是其中涉及了抓取（fetch）、合并（merge），以及分支（branch）、提交项（commits）的概念。
我们使用add命令将新建文件提交到本地暂存区，使用commit命令将文件提交到本地仓库，最后一步使用push命令提交到远端，可见已经将文件提交至了github库
git add FILES
git commit
git push
至此，场景二就实现了。
场景三：团队项目中的分叉合并
如果团队项目像场景二的方法一样多人同时向远程origin/master分支频繁提交代码，一来可能会有诸多冲突合并的情况发生；二来整个git log提交记录中多个开发者或多个代码模块的commit是交错排列在同一条时间线上，不利于回顾查看和回退代码，让跟踪代码的成长轨迹变得异常困难。
我们需要考虑新的方式来能够独立维护不同的开发者或者不同的功能模块的代码，让一段连续的工作在commit日志的时间线上呈现为一段独立的分支线段，只在关键节点处进行分支合并。
首先，我们使用命令创建一个新分支，并重新查看分支列表。
git checkout -b mybranch
接着，我们将新建的文件添加至暂存区，并commit。然后使用git checkout main指令切换为主分支，使用merge指令将mybranch分支合并到主分支，特别注意的是默认的合并方式为"快进式合并"（fast-farward merge），会将分支里commit合并到主分支里，合并成一条时间线，与我们期望的呈现为一段独立的分支线段不符，因此合并时需要使用--no-ff参数关闭"快进式合并"（fast-farward merge）。
这时我们在分支上完成的工作已经同步到远程库了，至此，场景三的运用就已经完成了。
场景四：Git Rebase
场景四实际就是在场景三团队项目工作流程中增加一步Git Rebase，即在mybranch分支上完成自己的工作之后，为了让 log 记录将来更容易回顾参考，用 git rebase 重新整理一下提交记录。注意不要通过rebase对任何已经提交到远程仓库中的commit进行修改。
通过git rebase代码，我们可以看到文本编辑器大致如下
我们编辑删除了1版本，保存退出，可以看到如下冲突提示
可以根据提示选择保留哪个更改，也可以直接编辑文件去掉提示信息。解决冲突后需要将修改后的文件存入暂存区（git add），最后执行如下命令完成git rebase。
git rebase --continue
这时查看提交日志可以发现1版本已经不存在了。
至此，我们由简单到复杂、从实际操作到背后的基本原理，并通过VS Code和命令行两种方式相互对照，在五大场景下给出了Git的参考用法。
