阅读 2300

面试官:你知道git xx 和git xx的区别吗?看完这篇Git指南后直呼:内行!

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

前言

作为一名工程师,既然想要加入一个团队,并肩作战地协同开发项目,就必不可少要学会Git基本操作。面试过程中,面试官不止是考察1-3年的工程师,高级岗位也同样会考察团队协作的能力。相信小伙伴们经常会在面试中被问到以下问题吧,可以帮助你测试一下你的Git基础牢不牢固。

  • 代码开发到一半,需要紧急切换分支修复线上问题,该怎么办?
  • 代码合并有几种模式?分别有什么优缺点?
  • git fetchgit pull有什么区别,有合并操作吗?
  • git mergegit rebase有什么区别,它们的应用场景有哪些?
  • git resetgit revert有什么区别,该如何选择,回滚后的<commit-id>还能找到吗?

如果你心中已有答案,那么可以选择跳过这篇文章啦,愉快地继续摸鱼~

如果你对这些概念还有些模糊,或者没有实际操作过,那么就需要好好阅读本篇文章啦!

接下来马上进入正文啦,本文分四个部分介绍,大家可以自由选择阅读。

  • Git的区域示例图,帮助大家理解Git的结构。
  • Git的基本使用场景,介绍一些常用git命令。
  • Git的进阶使用场景,介绍一些高频出现的面试题目以及应用场景。
  • 最后介绍Git的下载地址、基本配置和工具推荐。

Git的区域

画了一个简单的示意图,供大家参考

yuque_diagram.jpg

  • 远程仓库(Remote):在远程用于存放代码的服务器,远程仓库的内容能够被分布其他地方的本地仓库修改。
  • 本地仓库(Repository):在自己电脑上的仓库,平时我们用git commit 提交到暂存区,就会存入本地仓库。
  • 暂存区(Index):执行 git add 后,工作区的文件就会被移入暂存区,表示哪些文件准备被提交,当完成某个功能后需要提交代码,可以通过 git add 先提交到暂存区。
  • 工作区(Workspace):工作区,开发过程中,平时打代码的地方,看到是当前最新的修改内容。

Git的基本使用场景

以下命令远程主机名默认为origin,如果有其他远程主机,将origin替换为其他即可。

git fetch

# 获取远程仓库特定分支的更新
git fetch origin <分支名>

# 获取远程仓库所有分支的更新
git fetch --all
复制代码

git pull

# 从远程仓库拉取代码,并合并到本地,相当于 git fetch && git merge 
git pull origin <远程分支名>:<本地分支名>

# 拉取后,使用rebase的模式进行合并
git pull --rebase origin <远程分支名>:<本地分支名>
复制代码

注意

  • 直接git pull 不加任何选项,等价于git fetch + git merge FETCH_HEAD,执行效果就是会拉取所有分支信息回来,但是只合并当前分支的更改。其他分支的变更没有执行合并。
  • 使用git pull --rebase 可以减少冲突的提交点,比如我本地已经提交,但是远程其他同事也有新的代码提交记录,此时拉取远端其他同事的代码,如果是merge的形式,就会有一个merge的commit记录。如果用rebase,就不会产生该合并记录,是将我们的提交点挪到其他同事的提交点之后。

git branch

# 基于当前分支,新建一个本地分支,但不切换
git branch <branch-name> 

# 查看本地分支
git branch

# 查看远程分支
git branch -r

# 查看本地和远程分支
git branch -a

# 删除本地分支
git branch -D <branch-name>

# 基于旧分支创建一个新分支
git branch <new-branch-name> <old-branch-name> 

# 基于某提交点创建一个新分支
git branch <new-branch-name> <commit-id> 

# 重新命名分支
git branch -m <old-branch-name> <new-branch-name>
复制代码

git checkout

# 切换到某个分支上
git checkout <branch-name>

# 基于当前分支,创建一个分支并切换到新分支上
git checkout -b <branch-name>
复制代码

git add

# 添把当前工作区修改的文件添加到暂存区,多个文件可以用空格隔开
git add xxx

# 添加当前工作区修改的所有文件到暂存区
git add .
复制代码

git commit

# 提交暂存区中的所有文件,并写下提交的概要信息
git commit -m "message"

# 相等于 git add . && git commit -m
git commit -am

# 对最近一次的提交的信息进行修改,此操作会修改commit的hash值
git commit --amend
复制代码

git push

# 推送提交到远程仓库
git push 

# 强行推送到远程仓库
git push -f
复制代码

git tag

# 查看所有已打上的标签
git tag 

# 新增一个标签打在当前提交点上,并写上标签信息
git tag -a <version> -m 'message' 

# 为指定提交点打上标签
git tag -a <version> <commit-id> 

# 删除指定标签
git tag -d <version> 
复制代码

Git的进阶使用场景

HEAD表示最新提交 ;HEAD^表示上一次; HEAD~n表示第n次(从0开始,表示最近一次)

正常协作

  • git pull 拉取远程仓库的最新代码
  • 工作区修改代码,完成功能开发
  • git add . 添加修改的文件到暂存区
  • git commit -m 'message' 提交到本地仓库
  • git push将本地仓库的修改推送到远程仓库

代码合并

git merge

自动创建一个新的合并提交点merge-commit,且包含两个分支记录。如果合并的时候遇到冲突,仅需要修改解决冲突后,重新commit。

  • 场景:如dev要合并进主分支master,保留详细的合并信息
  • 优点:展示真实的commit情况
  • 缺点:分支杂乱
git checkout master
git merge dev
复制代码

rf1o2b6eduboqwkigg3w.gif

git merge 的几种模式

  • git merge --ff (默认--ff,fast-farward)
    • 结果:被merge的分支和当前分支在图形上并为一条线,被merge的提交点commit合并到当前分支,没有新的提交点merge
    • 缺点:代码合并不冲突时,默认快速合并,主分支按时间顺序混入其他分支的零碎commit点。而且删除分支,会丢失分支信息。
  • git merge --no-ff(不快速合并、推荐)
    • 结果:被merge的分支和当前分支不在一条线上,被merge的提交点commit还在原来的分支上,并在当前分支产生一个新提交点merge
    • 优点:代码合并产生冲突就会走这个模式,利于回滚整个大版本(主分支自己的commit点)
  • git merge --squash(把多次分支commit历史压缩为一次)
    • 结果:把多次分支commit历史压缩为一次

image.png

git rebase

  • 不产生merge commit,变换起始点位置,“整理”成一条直线,且能使用命令合并多次commit。
  • 如在develop上git rebase master 就会拉取到master上的最新代码合并进来,也就是将分支的起始时间指向master上最新的commit上。自动保留的最新近的修改,不会遇到合并冲突。而且可交互操作(执行合并删除commit),可通过交互式变基来合并分支之前的commit历史git rebase -i HEAD~3
  • 场景:主要发生在个人分支上,如 git rebase master整理自己的dev变成一条线。频繁进行了git commit提交,可用交互操作drop删除一些提交,squash提交融合前一个提交中。
  • 优点:简洁的提交历史
  • 缺点:发生错误难定位,解决冲突比较繁琐,要一个一个解决。
git checkout dev
git rebase master
复制代码

dwyukhq8yj2xliq4i50e.gifmsofpv7k6rcmpaaefscm.gif

git merge和git rebase的区别

  • merge会保留两个分支的commit信息,而且是交叉着的,即使是ff模式,两个分支的commit信息会混合在一起(按真实提交时间排序),多用于自己dev合并进master。
  • rebase意思是变基,改变分支的起始位置,在dev上git rebase master,将dev的多次commit一起拉到要master最新提交的后面(时间最新),变成一条线,多用于整理自己的dev提交历史,然后把master最新代码合进来。
  • 使用rebase还是merge更多的是管理风格的问题,有个较好实践:
    • 就是dev在merge进主分支(如master)之前,最好将自己的dev分支给rebase到最新的主分支(如master)上,然后用pull request创建普通merge请求。
    • 用rebase整理成重写commit历史,所有修改拉到master的最新修改前面,保证dev运行在当前最新的主branch的代码。避免了git历史提交里无意义的交织。
  • 假设场景:从 dev 拉出分支 feature-a。
    • 那么当 dev 要合并 feature-a 的内容时,使用 git merge feature-a
    • 反过来当 feature-a 要更新 dev 的内容时,使用 git rebase dev
  • git merge和git rebase 两者对比图
    • git merge图示 image.png
    • git rebase图示 image.png

取消合并

# 取消merge合并
git merge --abort
# 取消rebase合并
git rebase --abort
复制代码

代码回退

代码回退的几种方式

  • git checkout
  • git reset
    • --hard:硬重置,影响【工作区、暂存区、本地仓库】
    • --mixed:默认,影响【暂存区、本地仓库】,被重置的修改内容还留在工作区
    • --soft:软重置,影响 【本地仓库】,被重置的修改内容还留在工作区和暂存区
  • git revert
# 撤回工作区该文件的修改,多个文件用空格隔开
git checkout -- <file-name>
# 撤回工作区所有改动
git checkout .

# 放弃已git add到暂存区的指定文件的缓存(HEAD表示最新版本)
git reset HEAD <file-name>
# 放弃所有的缓存
git reset HEAD .
# 丢弃已commit的其他版本,hard参数表示同时重置工作区的修改
git reset --hard <commit-id>  
# 回到上一个commit的版本,hard参数表示同时重置工作区的修改
git reset --hard HEAD^

# 撤销0ffaacc这次提交
git revert 0ffaacc     
# 撤销最近一次提交
git revert HEAD       
# 撤销最近2次提交,注意:数字从0开始
git revert HEAD~1      

# 回退后要执行强制推送远程分支
git push -f 
复制代码

git reset和git revert的区别

  • reset是根据来移动HEAD指针,在该次提交点后面的提交记录会丢失。

hlh0kowt3hov1xhcku38.gif

  • revert会产生新的提交,来抵消选中的该次提交的修改内容,可以理解为“反做”,不会丢失中间的提交记录。

3kkd2ahn41zixs12xgpf.gif

  • 使用建议
    • 公共分支回退使用git revert,避免丢掉其他同事的提交。
    • 自己分支回退可使用git reset,也可以使用git revert,按需使用。

挑拣代码

git cherry-pick

  • “挑拣”提交,单独抽取某个分支的一个提交点,将这个提交点的所有修改内容,搬运到你的当前分支。
  • 如果我们只想将其他分支的某个提交点合并进来,不想用git merge将所有提交点合并进来,就需要使用这个git cherry-pick
git cherry-pick <commit-id>
复制代码

2dkjx4yeaal10xyvj29v.gif

暂存代码

git stash

  • 当我们想要切换去其他分支修复bug,此时当前的功能代码还没修改完整,不想commit,就需要暂存当前修改的文件,然后切换到hotfix分支修复bug,修复完成再切换回来,将暂存的修改提取出来,继续功能开发。
  • 还有另一种场景就是,同事在远程分支上推送了代码,此时拉下来有冲突,可以将我们自己的修改stash暂存起来,然后先拉最新的提交代码,再pop出来,这样可以避免一个冲突的提交点。
# 将本地改动的暂存起来
git stash 
# 将未跟踪的文件暂存(另一种方式是先将新增的文件添加到暂存区,使其被git跟踪,就可以直接git stash)
git stash -u 
# 添加本次暂存的备注,方便查找。
git stash save "message" 
# 应用暂存的更改
git stash apply 
# 删除暂存
git stash drop 
# 应用暂存的更改,然后删除该暂存,等价于git stash apply + git stash drop 
git stash pop
# 删除所有缓存
git stash clear
# 查看缓存列表
git stash list
复制代码

打印日志

  1. git log

可以显示所有提交过的版本信息,如果感觉太繁琐,可以加上参数  --pretty=oneline,只会显示版本号和提交时的备注信息。

  1. git reflog

git reflog 可以查看所有分支的所有操作记录(包括已经被删除的 commit 记录和 reset 的操作),例如执行 git reset --hard HEAD~1,退回到上一个版本,用git log是看不出来被删除的,用git reflog则可以看到被删除的,我们就可以买后悔药,恢复到被删除的那个版本。

Git的下载、配置、工具推荐

  • Git下载地址
  • 两种拉取代码的方式
    • https:每次都要手动输入用户名和密码
    • ssh :自动使用本地私钥+远程的公钥验证是否为一对秘钥
  • 配置ssh
    • ssh-keygen -t rsa -C "邮箱地址"
    • cd ~/.ssh切换到home下面的ssh目录、cat id_rsa.pub命令查看公钥的内容,然后复制
    • github的settings -> SSH and GPG keys-> 复制刚才的内容贴入 -> Add SSH key
    • 全局配置一下Git用户名和邮箱
      • git config --global user.name "xxx"
      • git config --global user.email "xxx@xx.com"
      • image.png
  • Git 相关工具推荐
    • 图形化工具 SourceTree :可视化执行git命令,解放双手
    • VSCode插件 GitLens:可以在每行代码查看对应git的提交信息,而且提供每个提交点的差异对比

结尾

阅读到这里,是不是感觉对Git相关概念更加清晰了呢,那么恭喜你,再也不怕因为误操作,丢失同事辛辛苦苦写的代码了,而且将在日常工作的协同中游刃有余。

  • 💖建议收藏文章,工作中有需要的时候翻出来看一看~
  • 📃创作不易,如果我的文章对你有帮助,辛苦大佬们点个赞👍🏻,支持我一下~
  • 📌如果有错漏,欢迎大佬们指正~
  • 👏欢迎转载分享,请注明出处,谢谢~

参考

文章分类
前端
文章标签