• Git工作区域
  • 工作区域划分
  • 暂存区设计目的
  • Git基本操作
  • 核心操作
  • 初始化和配置指令
  • HEAD指针
  • Git版本回滚
  • 指令介绍
  • reset模式
  • reset hard使用场景
  • reset soft使用场景
  • reset mixed使用场景
  • reset使用注意事项
  • checkout使用场景
  • Git分支管理
  • 什么是分支
  • 分支应用场景
  • 分支相关指令
  • 被合并分支和目标分支
  • merge模式
  • merge和rebase的区别
  • 分支合并的正确方式
  • merge合并完整流程
  • rebase合并完整流程
  • 常见的分支划分方案
  • Git分支仓库
  • fork操作完整流程
  • 本地仓库
  • 版本号标签
  • 文件对比
  • Git常见问题处理方案
  • Git是如何判断和解决冲突的
  • 提交代码的正确步骤是
  • 为什么push代码前，一定要先pull
  • 为什么pull代码前，一定要先commit
  • 怎么减少冲突的可能性
  • 想pull远程代码，又不想commit本地改动，怎么办


博客定位

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

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

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

Git工作区域

工作区域划分
  • Remote：远程仓库
  • Repository：本地仓库
  • Index：暂存区
  • Workspace：工作区
暂存区设计目的
  • 不必立刻将代码改动提交到仓库，可以等用户确认无误后再一次性提交
  • 可以有效减少错误提交的次数，并且可以随时通过Index查看改动了哪些代码

gitlab网页revert_处理方案

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

gitlab网页revert_gitlab网页revert_02

分支相关指令
  • 查看分支：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上的所有新的commit拷贝过来，再将master的head移动到bugfix最新commit的位置
  • no-fast-forward模式：当master分支没变动过时，会将bugfix上的所有新的commit拷贝过来，再生成一个新的merge版本号，将master的head指向该版本号
  • squash模式：当master分支没变动过时，会将bugfix的所有新的commit合并成一个整的commit，该commit不会自动添加到当前分支上，需要手动执行git commit -m "xxx"来生效
  • git合并默认采用的是fast-forward模式，通过–no-ff，–squash参数指定另外两个模式
  • 这三种模式都是针对master本身没有变动的情况，在master有变动时，处理方式都是一样的
  • 在master有变动时，会采用类似于squash的方式，将bugfix所有改动合并成一个commit，合并到master
  • master有变动时，merge操作一般由 git merge edit file git add git commit 四步组成

gitlab网页revert_处理方案_03

gitlab网页revert_gitlab网页revert_04

gitlab网页revert_gitlab网页revert_05

merge和rebase的区别
  • 合并指令除了merge之外，还有rebase指令，他们的主要区别在于生成commit记录的方式不同
  • merge会将bugfix的所有新的commit合并成一个merge commit，合并到master上，同时移动master的HEAD指针到merge commit上
  • rebase会以master的HEAD作为base，将bugfix的所有新commit逐个合并到master上，每个commit形成一个新的merge commit，移动bugfix的HEAD到最新的merge commit上，并将base之前的记录改为和master完全一致
  • merge和rebase，都只会改变当前分支记录，不影响目标分支，如果想将两个分支合而为一，需要手动将目标分支的HEAD也移动到最新的merge commit位置
  • merge和base最大的区别在于，merge不会改变之前的提交记录，rebase由于调整了新的fork base位置，所以会修改merge以前的记录

gitlab网页revert_应用场景_06

gitlab网页revert_应用场景_07

gitlab网页revert_git_08

从上图可以看出，rebase之后，以D作为新的fork base，并将自己的改动，通过创建新的commit的方式，来逐个同步过来

分支合并的正确方式
  • 合并前请先将本地最新代码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修复

gitlab网页revert_处理方案_09

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