git面试题

• 1.什么是git?为什么要使用git?集中化版本控制系统和分布式版本控制系统的区别。
• 2.列举工作中常用的git命令
• 3.git的分支命令
• 4.git的远程仓库命令
• 5.git pull和git fetch的区别
• 6.代码出现bug,是如何解决的？
• 7.rebase(变基)命令和应用场景
• 8.git merge和git rebase的区别
• 9.如何做代码的review,谁来做代码的review
• 10.git分支的命名规范和提交记录规范
• 11.github常用词含义
• 12.github高级搜索

1.什么是git?为什么要使用git?集中化版本控制系统和分布式版本控制系统的区别。

(1)Git是一款免费的开源的分布式版本控制系统。
(2)为了保留之前所有的版本，方便回滚和修改。
(3)集中化版本控制系统例如SVN，客户端连接到中央服务器取出最新的文件或者提交更新。所以有个很明显的缺点就是如果中央服务器发生故障，故障期间谁都无法提交更新。
分布式版本控制系统例如Git,客户端不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这样即使中央仓库发生故障，我们可以先提交到本地仓库。等故障恢复后再提交到中央仓库。

2.列举工作中常用的git命令

初始化命令

git init 

新增文件

git add  filename 或者git add .  

提交文件，生成版本

git commit -m  

查看工作区状况

git status 

详细当前分支详细的提交历史记录

git log    --graph  --pretty=format:"%h %s"记录简洁图形展示

查看所有分支简化的提交历史记录（回滚当前版本之后的版本）

git reflog  

版本号 回滚版本

git reset --hard 

3.git的分支命令

查看分支

git branch

创建分支

git branch 分支名称

切换分支

git checkout 分支名称

创建并切换分支

git checkout -b 分支名称

合并分支(可能产生冲突)

git merge 要合并的分支名称 (注意要先切换分支再合并)

删除分支

git branch -d 分支名称

4.git的远程仓库命令

添加远程连接(别名)

git remote add origin 地址

推送代码

git push origin dev

克隆远程仓库到本地

git clone 地址

拉取代码

git pull origin dev
等价于  
git fetch origin dev + git merge origin/dev

修改远程仓库的地址

#直接修改配置里面的url即可
vim .git/config

5.git pull和git fetch的区别

git fetch只是将远程仓库的最新的版本下载到本地，但是不会自动merge,相当于工作区中的文件并没有更新
git pull会从远程仓库获取到最新的版本并merge到本地。
git pull origin dev=git fetch origin dev+git merge origin/dev;
git fetch更保险一些，git pull操作更简单

6.代码出现bug,是如何解决的？

创建一个bug分支，然后进行bug处理,处理完毕后，合并到主分支前要先创建pull request给小组长检查代码，组长review成功后才能够合并到master.合并完成之后删除bug分支。然后回到dev分支继续开发

具体流程
创建dev分支,并切换到dev分支开发自己的模块

dev分支开发过程中遇到线上出现bug(master分支出现bug)

切换回master分支，创建并切换到bug分支修复bug

再切换到主分支，把bug分支合并到主分支，合并完成后删除掉bug分支

之后再切换到dev分支开发自己的模块

模块开发完毕切换到master分支，把dev分支合并到master分支。发现有冲突

我们找个这个文件，手动修改。然后提交

7.rebase(变基)命令和应用场景

命令:
git rebase -i HEAD~3 合并最近的三次提交
git rebase master 将最新的分支同步到本地，可能需要手动解决冲突
git rebase --continue 解决完冲突 add添加文件后 执行此命令合并完成

场景一:比如在公司开发忘记把代码push到远程仓库，在家里又继续开发新的功能。然后到公司把昨天家里的代码合并到公司昨天代码的时候，可以用git fetch–>git rebase(修改完冲突后再使用git rebase --continue)这样提交记录就不会出现分叉，保持了提交记录的整洁
(1)公司开发忘记提交github了

(2)回到家继续开发新功能,并提交到github

(3)第二天回到公司,使用git fetch先把最新的版本下载到本地，可以先使用git diff看哪些地方不同

(4)使用git rebase合并，发现有冲突。然后看到有个提示 修改完冲突 add添加文件后 要执行git rebase --continue命令完成合并

发现没有分叉。

场景二:当我们开发一个功能时，可能会在本地有无数次commit，而你实际上在你的master分支上只想显示每一个功能测试完成后的一次完整提交记录就好了，其他的提交记录并不想将来全部保留在你的master分支上，那么rebase将会是一个好的选择，他可以在rebase时将本地多次的commit合并成一个commit，还可以修改commit的描述等
(这里强烈注意合并的提交记录最好都是没有提交到远程仓库的，不然远程仓库与本地仓库提交记录就会乱很麻烦)


合并提交的时候需要改两个文件 s表示合并到 上一个版本 ，还要设置下合并提交点提交的信息。之后再切换到主分支，将dev分支merge到主分支

场景三:本地的两个分支使用rebase合并不会产生分叉。你自己用dev分支开发自己的模块，如果别人master分支提交到远程仓库新的版本，你拷贝master分支新的版本到自己的远程仓库，如果此时你dev分支开发完成，要跟master分支进行合并时，如果使用merge就会产生新的提交点而且出现分叉，如果你想要线性的提交就必须用rebase
(1)rebase之前需要经master分支拉到最新，具体做法是切换分支到需要rebase的分支，这里是dev分支
执行git rebase master，有冲突就解决冲突，解决后直接git add . 再git rebase --continue即可(这里演示没有冲突的情况，场景一已经演示有冲突的情况)

(2)切换到master分支，执行git merge dev


总结：
1.rebase能够将多条提交记录合并为一条；
2.rebase合并分支的时候不会出现分叉。

8.git merge和git rebase的区别

git merge 操作合并分支会让两个分支的共同提交点之后每一次提交都按照提交时间（并不是push时间）排序，并且会将两个分支的最新一次commit点进行合并成一个新的commit，最终的分支树呈现非整条线性直线的形式

git rebase操作实际上是将当前执行rebase分支的所有基于原分支提交点之后的commit打散成一个一个的patch，并重新生成一个新的commit hash值，再次基于原分支目前最新的commit点上进行提交，并不根据两个分支上实际的每次提交的时间点排序，rebase完成后，切到基分支进行合并另一个分支时也不会生成一个新的commit点，可以保持整个分支树的完美线性

参考文章

9.如何做代码的review,谁来做代码的review

小组长做review
自己开发的模块完成后，合并到分支前发送一个pull request给小组长，提醒他去审核pull request,系统也会发邮件提醒reviewer.如果需要修改代码，就根据reviewer的要求进行调整，修改好之后再commit/push到服务器。然后reviewer再次检查，直到代码没有问题了。reviewer或者代码的作者就可以将任务merge到master分支。

10.git分支的命名规范和提交记录规范

git分支的命名规范

git 分支分为集成分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数。不可使用 features、future、hotfixes、hotfixs 等错误名称。

1.git主分支(master):它是自动建立，用于发布重大版本更新
2.git开发主分支(develop):日常开发在此分支上进行
3.git临时分支:用于应对一些特定母的的办法开发(验证成功后应该删除此分支)，主要有

• 功能分支(featuer):它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后要再进入Develop。可以采用feature-的形式命名
• 预发布分支(release):指发布正式版本之前(合并到master分支之前)，我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-的形式
• 修复bug分支(hotfix):当出现bug需要修复时，需要创建修复bug的分支从Master分支上分出来。修补结束以后再合并进Master和Develop分支。它的命名也可以采用hotfix-***的形式

注意事项:一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。feather分支在申请合并之前，最好是先pull一下develop主分支下来，看一下有没有冲突，如果有就先解决冲突后再申请合并。

提交记录规范
每个git commit记录需要按照固定格式
具体格式为:
第一行: 作者:功能模块名称(或功能模块id)
第二行:提交描述，中英文皆可

+：增加代码
*：修改代码
-：删除代码

11.github常用词含义

watch: 会持续收到该项目的动态
fork: 复制某个项目到自己的github仓库中
star,可以理解为点赞
clone，将项目下载至本地
follow，关注你感兴趣的作者，会收到他们的动态

12.github高级搜索

(1)in关键词限制搜索范围
springboot in:name 项目名中包含springboot
springboot in:description 项目描述中包含springboot
springboot in:readme 项目的readme文件中包含springboot
springboot in:name,description,readme 组合使用，搜索项目名或者项目描述或者readme文件中包含springboot

(2)stars,fork 按照stars,fork的数量去搜索
springboot stars:>=5000 查找stars数大于等于5000的springboot项目
springboot forks:>=5000 查找fork数大于等于5000的springboot项目
springboot stars:2000…5000 forks:500…800 查找stars数介于2000到5000 fork数介于500…800的springboot项目

(3)awesome加强搜索
awesome redis 搜索优秀的redis相关的项目，包括框架，教程等

(4)高亮显示某一行代码
1行: 地址#L数字

多行:地址#L数字-L数字

(5)项目内搜索 按英文t就可以把文件罗列成一个列表

(6)搜索某个地区的大佬 location:地区 language:语言
location:beijing language:java 查询地区北京的java方向的用户