前端面试题汇总-git篇_拉取请求(pull request)”和“分支(branch)”之间有什么区别?

Q1: 什么是 Git 复刻（fork）？复刻（fork）、分支（branch）和克隆（clone）之间有什么区别？

复刻（fork） 是对存储仓库（repository）进行的远程的、服务器端的拷贝，从源头上就有所区别。复刻实际上不是 Git 的范畴。它更像是个政治/社会概念。

克隆（clone） 不是复刻，克隆是个对某个远程仓库的本地拷贝。克隆时，实际上是拷贝整个源存储仓库，包括所有历史记录和分支。

分支（branch） 是一种机制，用于处理单一存储仓库中的变更，并最终目的是用于与其他部分代码合并。

Q2: “拉取请求（pull request）”和“分支（branch）”之间有什么区别？

分支（branch） 是代码的一个独立版本。

拉取请求（pull request） 是当有人用仓库，建立了自己的分支，做了些修改并合并到该分支（把自己修改应用到别人的代码仓库）。

Q3: “git pull”和“git fetch”之间有什么区别？

- git pull：相当于是从远程获取最新版本并merge到本地

- git fetch：相当于是从远程获取最新版本到本地，不会自动merge

简单来说，git pull 是 git fetch + git merge。

当你使用 pull，Git 会试着自动为你完成工作。它是上下文（工作环境）敏感的，所以 Git 会把所有拉取的提交合并到你当前处理的分支中。pull 则是 自动合并提交而没有让你复查的过程。如果你没有细心管理你的分支，你可能会频繁遇到冲突。

当你 fetch，Git 会收集目标分支中的所有不存在的提交，并将这些提交存储到本地仓库中。但Git 不会把这些提交合并到当前分支中。这种处理逻辑在当你需要保持仓库更新，在更新文件时又希望处理可能中断的事情时，这将非常实用。而将提交合并到主分支中，则该使用 merge。

Q4: 如在 Git 恢复先前的提交？

要撤销提交但保留更改：git reset  +当前文件

                                       git status检测更改

要修改提交中的更改：git reset --hard +当前文件名

你使用了 --hard，所以你的文件将重置到提交 B 时的状态。

撤销提交但保留文件和索引：git reset --soft +文件名

Q5: 什么是“git cherry-pick”？

命令 git cherry-pick 通常用于把特定提交从存储仓库的一个分支引入到其他分支中。常见的用途是从维护的分支到开发分支进行向前或回滚提交。

这与其他操作（例如：合并（merge）、变基（rebase））形成鲜明对比，后者通常是把许多提交应用到其他分支中。

Q6: 解释 Forking 工作流程的优点

Forking 工作流程 与其他流行的 Git 工作流程有着根本的区别。它不是用单个服务端仓库充当“中央”代码库，而是为每个开发者提供自己的服务端仓库。Forking 工作流程最常用于公共开源项目中。

Forking 工作流程的主要优点是可以汇集提交贡献，又无需每个开发者提交到一个中央仓库中，从而实现干净的项目历史记录。开发者可以推送（push）代码到自己的服务端仓库，而只有项目维护人员才能直接推送（push）代码到官方仓库中。

当开发者准备发布本地提交时，他们的提交会推送到自己的公共仓库中，而不是官方仓库。然后他们向主仓库提交请求拉取（pull request），这会告知项目维护人员有可以集成的更新。

Q7: 告诉我 Git 中 HEAD、工作树和索引之间的区别？

该工作树/工作目录/工作空间是你看到和编辑的（源）文件的目录树。

该索引/中转区（staging area）是个在 /.git/index，单一的、庞大的二进制文件，该文件列出了当前分支中所有文件的 SHA1 检验和、时间戳和文件名，它不是个带有文件副本的目录。

HEAD是当前检出分支的最后一次提交的引用/指针。

Q8: 你能解释下 Gitflow 工作流程吗？

Gitflow 工作流程使用两个并行的、长期运行的分支来记录项目的历史记录，分别是 master和 develop 分支。

Master，随时准备发布线上版本的分支，其所有内容都是经过全面测试和核准的（生产就绪）。

Hotfix，维护（maintenance）或修复（hotfix）分支是用于给快速给生产版本修复打补丁的。修复（hotfix）分支很像发布（release）分支和功能（feature）分支，除非它们是基于 master 而不是 develop 分支。

Develop，是合并所有功能（feature）分支，并执行所有测试的分支。只有当所有内容都经过彻底检查和修复后，才能合并到 master 分支。

Feature，每个功能都应留在自己的分支中开发，可以推送到 develop 分支作为功能（feature）分支的父分支。

Q9: 什么时候应使用 “git stash”？

git stash 命令把你未提交的修改（已暂存（staged）和未暂存的（unstaged））保存以供后续使用，以后就可以从工作副本中进行还原。

Q10: 如何从 git 中删除文件，而不将其从文件系统中删除？

如果你在 git add 过程中误操作，你最终会添加不想提交的文件。但是，git rm 则会把你的文件从你暂存区（索引）和文件系统（工作树）中删除，这可能不是你想要的。

换成 git reset 操作：

git reset filename          # or

echo filename >> .gitingore # add it to .gitignore to avoid re-adding it

上面意思是，git reset <paths> 是 git add <paths> 的逆操作。

Q11: 是么时候使用“git rebase”代替“git merge”？

这两个命令都是把修改从一个分支集成到另一个分支上，它们只是以非常不同的方式进行。

考虑一下场景，在合并和变基前：

A <- B <- C    [master]

^

\

  D <- E       [branch]

在 git merge master 之后：

A <- B <- C

^         ^

\         \

  D <- E <- F

在 git rebase master 之后：

A <- B <- C <- D <- E

使用变基时，意味着使用另一个分支作为集成修改的新基础。

何时使用：

如果你对修改不够果断，请使用合并操作。

根据你希望的历史记录的样子，而选择使用变基或合并操作。

更多需要考虑的因素：

分支是否与团队外部的开发人员共享修改（如开源、公开项目）？如果是这样，请不要使用变基操作。变基会破坏分支，除非他们使用 git pull --rebase，否则这些开发人员将会得到损坏的或不一致的仓库。

你的开发团队技术是否足够娴熟？变基是一种破坏性操作。这意味着，如果你没有正确使用它，你可能会丢失提交，并且/或者会破坏其他开发者仓库的一致性。

分支本身是否代表有用的信息？一些团队使用功能分支（branch-per-feature）模式，每个分支代表一个功能（或错误修复，或子功能等）。在此模式中，分支有助于识别相关提交的集合。在每个开发人员分支（branch-per-developer）模式中，分支本身不会传达任何其他信息（提交信息已有作者）。则在这种模式下，变基不会有任何破坏。

是否无论如何都要还原合并？恢复（如在撤销中）变基，是相当困难的，并且/或者在变基中存在冲突时，是不可能完成的。如果你考虑到日后可能需要恢复，请使用合并操作。

Q12:git容易混淆的两个概念

工作区(project就是一个工作区)

.gitignore(配置不想上传到版本库的文件)

Q13：一些常用git命令

git init(创建仓库)

git status(查看仓库的状态)

git diff 文件名 (这次相较上次修改了哪些内容)

git add 文件名 (将添加的文件放到本地暂存区中)

git commit (将栈存区内容提交到代码区中)

git clone git地址(将远程仓库的代码克隆到本地)

git branch 查看当前分支

git checkout 切换分支

git rm <file> # 从版本库中删除文件

git reset <file> # 从暂存区恢复到工作文件

git pull # 抓取远程仓库所有分支更新并合并到本地

Q14：git的两种工作流

fork/clone

clone

Q15：说明新建一个GIT功能分支的步骤，提供每个步骤的指令，并对指令进行说明。

答：Git branch name     创建名字为name的branch

Git checkout xxx_dev    切换到名字为xxx_dev的分支

Git pull    从远程分支拉取代码到本地分支

Git checkout -b main_furture_xxx    创建并切换到main_furture_xxx

Git push origin main_furture_xxx    执行推送的操作，完成本地分支向远程分支的同步

Q16：说明GIT合并的两种方法以及区别。

答：Git代码合并有两种：Git Merge 和 Git ReBase

Git Merge：这种合并方式是将两个分支的历史合并到一起，现在的分支不会被更改，它会比对双方不同的文件缓存下来，生成一个commit，去push。

Git ReBase：这种合并方法通常被称为“衍合”。他是提交修改历史，比对双方的commit，然后找出不同的去缓存，然后去push，修改commit历史。

Q17：如何查看文件的提交历史和分支的提交历史。

答：使用git log查看文件提交历史

Git log filename

使用git log查看分支提交历史

Git log branch file

Q18:我们在本地工程常会修改一些配置文件，这些文件不需要被提交，而我们又不想每次执行git status时都让这些文件显示出来，我们该如何操作？

答：在Git工作区的跟目录下创建一个特殊的.gitignore文件，然后把忽略的文件名编辑进去，Git就会自动忽略这些文件。

Q19：git提交代码时候写错commit信息后，如何重新设置commit信息？

答：可以通过Git commit --amend 来对本次commit进行修改。

Q20:当GIT出现如下情况时，该如何处理？

your-branch-is-ahead-of-origin-master-by-3-commits

答：

Git commit

Git pull

Git push

Q21:描述清楚冲突产生的原因？git跟其他版本控制器有啥区别？

答：很多命令都可能出现冲突。但冲突的直接来源是merge和patch（应用补丁）。其它的命令是执行这两个操作导致冲突。

rebase：重新设置基准，然后应用补丁。

pull：会自动merge

repo sync：会自动rebase

cherry-pick：会应用补丁

没有更新代码就进行提交，覆盖别人的代码。

区别：

Git比svn快，而且更加的流畅。

Git在本地就可以使用，可以随便保存各种历史记录，不用担心污染服务器。

Git在branch和branch之间切换非常简单。

Git没有被lock不能commit 的情。

Q22：SVN与Git优缺点比较

1．SVN优缺点

优点： 

1、 管理方便，逻辑明确，符合一般人思维习惯。 

2、 易于管理，集中式服务器更能保证安全性。 

3、 代码一致性非常高。 

4、 适合开发人数不多的项目开发。 

缺点： 

1、 服务器压力太大，数据库容量暴增。 

2、 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。 

3、 不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

 

2．Git优缺点

优点： 

1、适合分布式开发，强调个体。 

2、公共服务器压力和数据量都不会太大。 

3、速度快、灵活。 

4、任意两个开发者之间可以很容易的解决冲突。 

5、离线工作。 

缺点： 

1、学习周期相对而言比较长。 

2、不符合常规思维。 

3、代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

Q23：fetch和merge和pull的区别

 pull相当于git fetch 和 git merge，即更新远程仓库的代码到本地仓库，然后将内容合并到当前分支。

 git fetch：相当于是从远程获取最新版本到本地，不会自动merge

 git merge :  将内容合并到当前分支

 git pull：相当于是从远程获取最新版本并merge到本地

Q24：Git工作流程

1、在工作目录中修改某些文件

2、对修改后的文件进行快照，然后保存到暂存区域

3、提交更新，将保存在暂存区域的文件快照永久转储到Git目录中

作者备注：其实可以直接看本人关于git的博客很全面！谢谢，以上面试题是汇总的他人的。