Git

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

前言


作为一名工程师,既然想要加入一个团队,并肩作战地协同开发项目,就必不可少要学会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 .

# 撤回已经commit到暂存区的文件
git reset <file-name>
# 撤回已经commit到暂存区的所有文件
git reset .
# 丢弃已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

打印日志



  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相关概念更加清晰了呢,那么恭喜你,再也不怕因为误操作,丢失同事辛辛苦苦写的代码了,而且将在日常工作的协同中游刃有余。



  • 💖建议收藏文章,工作中有需要的时候翻出来看一看~

  • 📃创作不易,如果我的文章对你有帮助,辛苦大佬们点个赞👍🏻,支持我一下~

  • 📌如果有错漏,欢迎大佬们指正~

  • 👏欢迎转载分享,请注明出处,谢谢~

链接:https://juejin.cn/post/6986868722136776718

0 个评论

要回复文章请先登录注册