原文地址：https://medium.com/edureka/devops-interview-questions-e91a4e6ecbf3
原文作者：Saurabh Kulshrestha
翻译君：CODING 戴维奥普斯
Q1：什么是版本控制？
这可能是你在面试中遇到的最简单的问题。我的建议是首先给出版本控制的定义：它是一个记录文件变化的系统，以便你以后可以调用特定版本的文件。版本控制系统由一个中央共享存储库组成，队友可以在其中提交文件的更改，接下来你可以提到版本控制的用途。版本控制允许你：
- 将文件还原为以前的状态。
- 将整个项目还原为以前的状态。
- 比较一段时间内的变化。
- 查看最后一次修改可能导致问题的内容。
- 何时引入了问题。
Q2：使用版本控制有什么好处？
版本控制的优点：
- 使用版本控制系统（VCS），所有团队成员都可以随时在任何文件上自由工作。VCS 允许你将所有更改合并到一个通用版本中。
- 所有过去的版本和变更都整齐地打包在 VCS 中。当你需要它时，你可以随时请求任何版本，你将获得完整项目的快照。
- 每次保存项目的新版本时，VCS 都要求你提供更改内容的简短说明。此外，你还可以查看文件内容的确切更改内容。这可以让你知道谁在项目中做了哪些更改。
- 像 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 列出了尚未合并的分支。
