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

前言

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

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

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

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

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

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

Git的区域

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

• 
  
• 远程仓库（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

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历史压缩为一次
    
  
  
  

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

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图示
    
  • git rebase图示
    
  
  
  

取消合并

# 取消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指针，在该次提交点后面的提交记录会丢失。
  

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

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

挑拣代码

git cherry-pick

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

git cherry-pick <commit-id>

暂存代码

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. 
   
2. git log
   

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

2. 
   
3. git reflog
   

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

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

• 
  
• Git下载地址
  
  • 
    
  • git-scm.com/downloads
    
  
  
  
• 两种拉取代码的方式
  
  • 
    
  • 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"
      
    • 
      
    
    
    
  
  
  
• Git 相关工具推荐
  
  • 
    
  • 图形化工具 SourceTree ：可视化执行git命令，解放双手
    
  • VSCode插件 GitLens：可以在每行代码查看对应git的提交信息，而且提供每个提交点的差异对比
    
  
  
  

结尾

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

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