博客定位

本篇博客主要讲解Git应用场景和工作原理，以及核心用法

Git的每一个指令，都有非常多灵活的用法，这里不会将单个指令细化讲解

但是会比较全面地涵盖所有常用知识，对于非深度用户来说，用一辈子已经够了

Git工作区域

工作区域划分

• Remote：远程仓库
• Repository：本地仓库
• Index：暂存区
• Workspace：工作区

暂存区设计目的

• 不必立刻将代码改动提交到仓库，可以等用户确认无误后再一次性提交
• 可以有效减少错误提交的次数，并且可以随时通过Index查看改动了哪些代码

Git基本操作

上面的图片基本包含了Git系统的核心需求，其它需求都是围绕这些，在多人多仓库的情景下产生的

核心操作

• add：将工作目录中新增或修改的内容，提交到暂存区
• commit：将暂存区中所有的改动，一次性提交到本地仓库
• push：将本地仓库中所有的改动，推送给远程仓库
• fetch：将远程仓库的最新改动拉取到本地，但并不会将代码合并到本地，用于查看其他人对远程仓库的改动
• merge：将一个仓库的代码合并到指定仓库，并更新工作区（准确说是合并分支，后面再说）
• checkout：将工作区文件恢复到最近一次add/commit时的状态（也可用于分支切换，后面再说）
• pull：拉取远程仓库代码，再合并到本地仓库，同时更新工作区，相当于fetch+merge

初始化和配置指令

• init：在空目录创建一个Git仓库
• config：配置或查询变量值，如配置账号
• remote：添加或修改远程仓库，本地仓库可以同时和多个远程仓库进行互动
• clone：从远程克隆仓库到本地，相当于init+remote+pull

HEAD指针

HEAD指针，是为了方便描述Git中的复杂操作，而抽象出来的一个概念

再Git系统中，所有仓库、所有分支中代码版本，都是用commit-id来表示的

Git系统简单概述起来，就是一个文本对比系统+commit-id-tree管理系统

HEAD指针，指向的就是本地仓库当前的commit-id

所有的Git合作，无非就是仓库切换，分支切换，pull到本地，push到远程

这些操作都要经过本地仓库，因此HEAD指针在描述复杂操作时，十分重要，但它本身仅仅代表本地仓库的commit-id而已

HEAD指针可以通过以下方式进行移动

• 移动本地HEAD指针：git checkout commit-id
• 移动特定分支的HEAD指针：git branch -f branch-name commit-id

Git版本回滚

Git用于版本回滚的有reset，revert，checkout三个指令，查看版本记录用log指令

指令介绍

• log：查看提交历史，可以拿到每次提交对应的commit-id
• reset：将本地仓库代码回退到指定的版本，并将中间的commit记录全部删除。此时在push，远程记录也会被删除
• revert：将本地仓库代码回退到指定的版本，并保留所有更改记录。本质是将旧代码拉到本地，作为一个新版本去提交
• checkout：将工作区代码回退到暂存区或本地仓库中的状态，即最近一次add/commit时的状态，不影响本地仓库和远程仓库代码
• revert会产生新的commit-id，但reset不会

reset有三种模式，它们对本地仓库的改动都是一样的，但是对暂存区和工作区的处理方式有所不同

reset模式

• hard模式：暂存区和工作区也会被重置
• soft模式：暂存区和工作区仍然保留改动
• mixed模式：暂存区被重置，工作区被保留

reset hard使用场景

• 将本地所有改动回退到目标版本，并清除中间所有的提交记录
• 使用方式：git reset --hard commit-id

reset soft使用场景

• 提交了错误的commit，想要撤回记录
• 发现merge处理方式错误，但想保留工作区最新代码
• commit提交到错误的分支

reset mixed使用场景

• 想保留工作区最新代码，同时想清空暂存区add记录

reset使用注意事项

• reset只会回退本地代码，并不会回退远程仓库，如果想回退远程仓库，必须手动push本地代码
• 由于HEAD指向的是已存在的旧版commit-id，远程仓库出于保护并不允许直接push，需要强制push
• 强制推送指令：git push origin:main -f
• GitLab会开启ForcePush保护，push -f 可能会识别，需要自己去网页关闭Repository Protect

checkout使用场景

• checkout用于恢复工作区文件，指令不改变本地仓库和暂存区
• 如果暂存区有未提交的add记录，则将工作区回退到上次add时的状态
• 如果暂存区无记录，则将工作区回退到上次commit时的状态
• 回退全部文件：git checkout – .
• 回退指定文件：git checkout file1 file2

Git分支管理

什么是分支

• 在单人开发、单版本开发的情景下，Git的版本记录是一个链表结构，版本要么新增，要么回退
• 在多人开发、多个子功能同时开发、不同版本之间需要进行功能合并的情景下，链表结构的版本管理便无法再满足需求
• 于是便诞生了树结构的版本管理方式，版本号允许新开分支进行单独的版本管理，而不影响主分支版本
• 需要合并不同分支功能的时候，允许不同分支之间进行代码合并

分支应用场景

• 开发版本和发布版本要独立维护
• BUG修复和新功能开发需要独立进行
• 两个小组开发不同功能，功能完成之前，不想同步彼此的代码
• 不同服务器、不同客户的产品版本号不一样，需要独立维护

分支相关指令

• 查看分支：git branch
• 创建分支：git branch branch-name
• 切换分支：git checkout branch-name
• 合并分支：git merge branch-name 注意，merge只是将分支合并到本地仓库，并不会自动push到远程仓库
• 删除分支：git branch -d branch-name
• 取消分支合并：git reset --hard HEAD~

被合并分支和目标分支

• 假定我们现在有两个分支，master和bugfix
• bugfix分支修复了一些问题，现在要将这些修复合并到master
• 此时我们称bugfix为被合并分支（merged-branch），master为目标分支（target-branch）

merge模式

• fast-forward模式：当master分支没变动过时，如果想要合并bugfix的改动，直接将master头指针移动到bugfix头指针位置
• no-fast-forward模式：即使master分支没有变动，仍然生成一个新的合并版本号，而不是快速移动指针
• squash模式：合并方式和no-fast-forward一致，但合并时会将bugfix的所有中间提交记录合并成一个commit
• git合并默认采用的是fast-forward模式，通过–no-ff，–squash参数指定另外两个模式
• 这三种模式都是针对master本身没有变动的情况，在master有变动时，处理方式都是一样的
• 在master有变动时，会采用类似于squash的方式，将bugfix所有改动合并成一个commit，合并到master

merge和rebase的区别

• 合并指令除了merge之外，还有rebase指令，他们的主要区别在于生成commit记录的方式不同
• merge会将bugfix的所有commit合并成一个新commit，合并到master上，同时移动master的HEAD指针到最新commit节点上
• rebase会将bugfix的所有commit逐个合并到master上，形成多个新的commit节点，同时移动bugfix的HEAD指针到最新commit节点上
• merge的目的在于将bugfix的改动合并到master，rebase的目的在于将master的改动合并到bugfix
• merge和rebase，都只会改变其中一个分支的HEAD，如果想将两个分支合而为一，需要手动将另外一个分支的HEAD指针也移动到最新的commit节点
• merge和base最大的区别在于，merge的记录比较简洁，rebase的记录比较详细，根据需要选择

分支合并的正确方式

• 合并前请先将本地最新代码push到所在远程仓库，避免操作出错时导致本地改动丢失

• 分支合并只会影响本地仓库，推送到远程仓库需要手动push

merge合并完整流程

• 提交本地改动：git commit

• 推送本地改动：git push

• 切换到目标分支：git checkout master

• 合并BUG分支：git merge bugfix

• 推送合并结果到master：git push origin master

• 移动bugfix到最新位置：git push -f origin bugfix

• 以上代码根据实际需要来执行，不需要的步骤可以跳过

rebase合并完整流程

• 提交本地改动：git commit
• 推送本地改动：git push
• 切换到目标分支：git checkout bugfix
• 改变目标分支的基线：git rebase master
• 推送合并结果到bugfix：git push origin bugfix
• 移动master到最新位置：git push -f origin master
• 以上代码根据实际需要来执行，不需要的步骤可以跳过

常见的分支划分方案

• master：用于发布管理的分支，每个版本会贴上版本号标签
• develop：日常开发用的分支
• feature：独立功能开发用的分支，开发完毕合并到develop
• release：为发布做准备的分支，来自develop，合并到master
• hotfix：对已发布的版本做紧急BUG修复

Git分支仓库

Git可以通过Fork功能，创建一个拥有一模一样版本记录的仓库副本，并且允许这两个副本直接相互合并代码

GitHub开源项目的管理方式，运用的便是这一种方式，开发者不允许直接修改仓库，只能自己Fork一份仓库进行修改

修改结束后，可以向父仓库发起Merge Request，管理员审核通过后才会合并成功

fork操作完整流程

• 从父仓库的Git页面中，点击Fork按钮，复制一份到自己的仓库
• 将fork仓库拉到本地：git clone fork-git-url（fork仓库在本地的别名默认为origin）
• 查看远程仓库配置：git remote -v
• 添加父仓库配置到本地：git remote add parent parent-git-url（parent是父仓库的别名）
• 拉取父仓库信息：git fetch parent
• 合并父仓库分支代码：git merge parent/main
• 推送分支代码到fork仓库：git push origin main

本地仓库

• 本地仓库本身相当于一个独立的分支仓库，可以创建子分支，可以从任何分支拉取代码，也可以向任何分支推送代码
• Git也可以没有远程仓库，只创建本地仓库，此时仍然能使用commit和revert，但不能再使用push和pull
• Git的大多指令，都是针对本地仓库进行操作的，只有经过push后，才会推送到远程仓库
• Git中通过树结构，记录了所有分支的版本号演变过程，如果push会导致版本树后退，那么必须使用push -f才能强制推送
• 如果我们不想手动解决冲突，并且确定自己的代码是最终的、正确的，也可以通过push -f来强制推送

版本号标签

标签是给版本号起的一个别名，方便记住和操作

• 查看标签列表：git tag
• 给当前分支最新版本打标签：git tag tag-name
• 给指定版本打标签：git tag tag-name commit-id
• 删除指定标签：git tag -d tag-name
• 推送标签到远程仓库：git push origin --tags
• 添加和删除标签都需要push，才能对远程仓库生效

文件对比

• 对比分支差异：git diff <branch-name-1> <branch-name-2> [specified-path] [specified-file]
• 查看工作区和指定分支差异：git diff <branch-name>
• 对比版本号差异：git diff <commit-id-1> <commit-id-2>

Git常见问题处理方案

Git是如何判断和解决冲突的

Git是基于文件名和文本行来判断冲突的

如果两个来自不同用户的commit，都修改了同一个文件的同一行文本，即被视为冲突

Git命令行工具会列出具体冲突的文件和行数，手动编辑文件解决冲突后，再重新合并代码

如果用的是图形化工具或IDE插件的话，一般会自己弹出对比窗口，方便用户去预览和修改冲突

提交代码的正确步骤是

add => commit => pull => push

为什么push代码前，一定要先pull

因为从上次拉取代码，到现在提交代码，中间远程仓库的代码可能已经被修改了

这样就有可能和我们的修改产生冲突，所以必须先pull远程代码改动，解决冲突后再提交

为什么pull代码前，一定要先commit

因为pull代码可能会和工作区代码产生冲突

只有将工作区的改动commit到本地仓库，Git才能在pull时对比出冲突的地方

如果不commit的话，pull会将远程仓库的代码同时拉到本地仓库和工作区，这样未提交的本地改动将会丢失

怎么减少冲突的可能性

每次准备修改代码前，先pull远程代码

每次push代码前，先pull远程代码

不要隔很久才push代码，做完一小块完整任务就可以push

这些措施虽然不能避免冲突，但是可以将冲突限制在小范围内，降低了merge难度

想pull远程代码，又不想commit本地改动，怎么办

git stash save指令可用于将本地改动缓存到暂存区

这样本地的代码就还原到改动前的状态，就可以从远程pull代码了

pull完代码之后再通过git stash pop，可以再将之前的改动合并到pull后的代码当中

如果pull的代码和save的代码有冲突的话，需要手动去解决冲突

git stash save

git pull

git stash pop