2019 DevOps 必备面试题——代码版本控制篇

原文地址：medium.com/edureka/dev…
原文做者：Saurabh Kulshrestha
翻译君：CODING 戴维奥普斯

Q1：什么是版本控制？

这多是你在面试中遇到的最简单的问题。个人建议是首先给出版本控制的定义：它是一个记录文件变化的系统，以便你之后能够调用特定版本的文件。版本控制系统由一个中央共享存储库组成，队友能够在其中提交文件的更改，接下来你能够提到版本控制的用途。版本控制容许你：

• 将文件还原为之前的状态。
• 将整个项目还原为之前的状态。
• 比较一段时间内的变化。
• 查看最后一次修改可能致使问题的内容。
• 什么时候引入了问题。

Q2：使用版本控制有什么好处？

版本控制的优势：

1. 使用版本控制系统（VCS），全部团队成员均可以随时在任何文件上自由工做。VCS 容许你将全部更改合并到一个通用版本中。
2. 全部过去的版本和变动都整齐地打包在 VCS 中。当你须要它时，你能够随时请求任何版本，你将得到完整项目的快照。
3. 每次保存项目的新版本时，VCS 都要求你提供更改内容的简短说明。此外，你还能够查看文件内容的确切更改内容。这可让你知道谁在项目中作了哪些更改。
4. 像 Git 这样的分布式 VCS 容许全部团队成员拥有项目的完整历史记录，所以若是中央服务器出现故障，你可使用任何团队成员的本地 Git 存储库来恢复代码库。

Q3：描述你使用的分支策略

这个问题用来测试你的分支经验，因此告诉他们你在之前的工做中如何使用分支以及它的用途是什么，你能够参考如下几点：

• 特性分支 特性分支模型保留分支内特定功能的全部更改。当经过新增特性的全面测试和验证时，该分支会被合并到 master 分支中。
• 任务分支 在此模型中，每一个任务都在本身的分支上实现，任务关键词包含在分支名称中。只需在分支名称中查找关键词，就能很容易看出哪一个代码实现了哪一个任务。
• 发布分支 一旦开发分支为发布得到了足够的特性时，你就能够克隆该分支以造成发布分支。建立此分支将启动下一个发布周期，所以在这以后不能添加任何新功能，只有错误修复、文档补齐和其它面向发布的任务可以包含在此分支中。一旦准备好发布，该版本将合并到 master 中并标记版本号。此外，尽管自发布以来开发分支可能已经有新的代码更新，但它依然应该被合并回开发分支。

最后告诉他们分支策略因组织而异，因此我知道基本的分支操做：如删除，合并，检出分支等。

Q4：你熟悉哪一种 VCS 工具？

你能够提到你曾经使用的 VCS 工具：“我使用过 Git，它对比 SVN 等其余 VCS 工具的一个主要优点在于，它是一个分布式版本控制系统。”

分布式 VCS 工具不必定依靠中央服务器来存储项目文件的全部版本。相反，每一个开发人员都“克隆”存储库的副本，并在本身的硬盘上拥有项目的完整历史记录。

Q5：什么是 Git？

我建议你经过解释 Git 的体系结构来解答这个问题，以下图所示。你能够参考下面给出的解释：

• Git 是一个分布式版本控制系统（DVCS），它能够跟踪文件的更改，并容许你恢复任何特定的更改。
• 与 SVN 等其它版本控制系统相比，它的分布式架构具备许多优点，一个主要优势是它不依赖于中央服务器来存储项目文件的全部版本。相反，每一个开发人员“克隆”我在下图中使用“本地存储库”显示的存储库副本，并在其硬盘驱动器上具备项目的完整历史记录，以便在出现服务器中断时，能从你的某位队友的本地 Git 存储库中恢复所需的所有内容。
• 还有一个中央云存储库，开发人员能够提交更改并与其余团队成员共享。如图所示，全部协做者都提交更改至“远程存储库”。

Q6：解释一些基本的 Git 命令？

如下是一些基本的 Git 命令：

Q7：在 Git 中，如何还原已经被推送并公开的提交？

此问题能够有两个答案，根据具体状况可使用如下任意选项：

• 在新提交中删除或修复错误文件，并将其推送到远程存储库。这是修复错误最天然的方式。对文件进行必要的更改后，将其提交到远程存储库，我将使用： git commit -m“commit message”
• 建立一个新的提交，撤消在错误提交中所作的全部更改，使用命令： git revert

Q8：如何将 N 次提交压缩成一次提交？

将 N 个提交压缩到单个提交中有两种选择。在你的答案中包括如下两个选项：

• 若是要从头开始编写新的提交消息，请使用如下命令： **git reset -soft HEAD~N && ** git commit
• 若是你想经过串接现有提交信息来编辑新的提交信息，那么你须要提取出这些消息并传递给 Git commit 。我会使用： **git reset -soft HEAD~N && ** git commit -edit -m “$（git log -format =％B -reverse .HEAD @ {N}）”

Q9：什么是 Git bisect？如何用它来肯定 bug 的来源？

我建议你先给出一个 Git bisect 的小定义——Git bisect 用于经过二进制搜索算法来查找引入 bug 的提交。Git bisect 的命令是：
git bisect <子命令>

接下来须要解释一下这个命令能够作什么，这个命令使用二进制搜索算法来查找项目历史中哪一个提交引入了一个 bug。首先你须要告诉它一个已知的包含了该 bug 的提交和在一个已知的引入 bug 以前的提交。而后 Git bisect 在这两个时间点之间选择一个提交，并询问你所选的提交是“好”仍是“坏”，以后它继续缩小范围，直到找到引入 bug 的确切提交。

Q10：什么是 Git rebase？它如何在合并以前解决特性分支中的冲突？

你应该首先说 Git rebase 是一个命令，它将另外一个分支合并到当前你正在工做的分支中，并将全部位于另外一分支以前的本地提交，移到该当前工做分支历史记录顶部。

接下来你须要经过一个示例定义 Git rebase 时间窗，以显示如何在合并以前使用它来解决特性分支中的冲突。若是从 master 建立了一个特性分支，那么 master 已经收到了新的提交，Git rebase 可用于将特性分支移动到 master 分支的顶部。

该命令有效地在 master 的顶部重放特性分支中所作的更改，并容许在该过程当中解决冲突。完成后，特性分支会相对容易地合并到 master 中，有时会被做为简单的快进操做。

Q11：如何配置 Git 存储库，以在提交以前运行代码健康性检查工具，并在测试失败时阻止提交？

我建议你先简要介绍一下合理性检查。合理性或冒烟测试能够用来肯定是否进行后续测试的合理性和必要性。

接下来解释如何实现这一点，这能够经过与存储库的预提交钩子相关的简单脚原本完成。即便在你须要输入提交消息以前，也会在提交以前触发预提交挂钩。在此脚本中，能够运行其它工具，例如 linters，并对提交到存储库中的更改执行完整性检查。

最后给出一个例子，你能够参考下面的脚本：

#!/bin/sh
files=$(git diff -cached -name-only -diff-filter=ACM | grep '.go$')
if [ -z files ]; then
exit 0
fi
unfmtd=$(gofmt -l $files)
if [ -z unfmtd ]; then
exit 0
fi
echo "Some .go files are not fmt'd"
exit 1
复制代码

此脚本会检查即将提交的全部 .go 文件是否经过标准 Go 源码格式化工具 —— gofmt 的检验。当检查未经过时，经过以非零状态退出，脚本能有效地阻止该提交应用于存储库。

Q12：如何找到特定提交中已更改的文件列表？

对于这个问题，不该该仅仅只解释这个命令是什么，而应该解释这个命令究竟会作什么。因此你能够这么说，为了得到在特定提交中更改的文件列表使用命令：
git diff-tree -r {hash}

给定提交哈希值，这个命令将列出在该提交中更改或添加的全部文件。-r 标志会让命令列出各个文件，而不是仅将它们折叠到根目录名称中。

你的回答也能够包含如下内容，虽然它是彻底可选的，但有助于给面试官留下深入的印象： 输出还将包含一些额外信息，能够经过如下两个标志轻松去掉：
git diff-tree -no-commit-id -name-only -r {hash}

这里 -no-commit-id 将禁止提交哈希值出如今输出中，而 -name-only 只会打印文件名而不是它们的路径。

Q13：每次存储库接收到新推送的提交时，如何设置某些特定脚本运行？

每次存储库接收到开发者 push 的新提交时，有三种方法能够配置脚本运行，须要根据触发脚本的时间来定义 pre-receive、update、或者 post-receive 脚本。

• 当有新提交被 push 到目标存储库时，将调用目标存储库中的 pre-receive 钩子脚本。绑定到此挂钩的任何脚本都将在更新任何引用以前执行。这是一个颇有用的钩子，能够用于运行有助于实施开发策略的脚本。
• update 钩子以相似 pre-receive 钩子的方式工做，而且在实际进行任何更新以前也会触发。可是对于已推送到目标存储库的每一个提交，都会调用一次 update 钩子。
• 最后，在将更新接受到目标存储库后，将调用存储库中的 post-receive 钩子。这是配置简单部署脚本、调用持续集成系统、向存储库维护人员发送通知电子邮件等事务的理想场所。

钩子是每一个 Git 存储库的本地存储，而且没有版本化。脚本能够在“.git”目录内的 hooks 目录中建立，也能够在别处建立，而且能够在目录中放置这些脚本的连接。

Q14：如何知道分支是否已经合并入主分支？

我建议你提到如下命令： git branch -merged 列出已合并到当前分支的分支。 git branch -no-merged 列出了还没有合并的分支。