Q1。什么是版本控制？

这可能是您在面试中最容易遇到的问题。我的建议是首先给出版本控制的定义。它是一个记录一段时间内对一个文件或一组文件的更改的系统，以便您以后可以调用特定版本。版本控制系统由一个中央共享存储库组成，同事可以在其中对文件或文件集进行更改。然后，您可以提及版本控制的用途。

版本控制可让您：

• 将文件还原到以前的状态。
• 将整个项目还原到以前的状态。
• 比较随时间的变化。
• 查看谁最后修改了可能导致问题的内容。
• 谁修改了问题，何时修改了。

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

我建议您包括以下版本控制优点：

1. 使用版本控制系统（VCS），允许所有团队成员随时自由处理任何文件。VCS稍后将允许您将所有更改合并到一个通用版本中。
2. 所有过去的版本和变体都整齐地包装在VCS中。在需要时，您可以随时获取任何版本，并且手边将有完整项目的快照。
3. 每次保存项目的新版本时，VCS都要求您提供更改内容的简短描述。此外，您可以看到文件内容中的确切更改。这使您可以知道谁在项目中进行了哪些更改。
4. 像Git这样的分布式VCS允许所有团队成员拥有完整的项目历史记录，因此，如果中央服务器出现故障，则可以使用任何队友的本地Git存储库。

Q3。在团队中分支是怎么用的。

询问这个问题是为了测试您的分支经验，因此请告诉他们您在上一份工作中使用分支的方式以及该分支的目的是什么，您可以参考以下几点：

• 特征分支
  特征分支模型将特定特征的所有更改保留在分支内。对功能进行全面测试并通过自动测试验证后，该分支将合并到主服务器中。
• 任务分支
  在此模型中，每个任务都是在自己的分支上实现的，任务名称包含在分支名称中。很容易看到哪个代码实现了哪个任务，只需在分支名称中查找任务键即可。
• 发布分支
  一旦开发分支获得了足够的发布功能，就可以克隆该分支以形成发布分支。创建此分支将开始下一个发行周期，因此此刻之后不能添加任何新功能，该分支中仅应包含错误修复，文档生成以及其他面向发行版的任务。一旦准备好发布，该发行版将合并到主版本中并标记一个版本号。此外，应该将其合并回developer分支，该分支可能从发行版开始就已经进行了。

最后告诉面试官，分支策略在一个组织之间会有所不同，所以我知道基本的分支操作，例如删除，合并，签出分支等。

Q4。您喜欢哪种VCS工具？

您可以仅提到您曾经使用过的VCS工具：“我从事过Git，与SVN等其他VCS工具相比，它具有一个主要优势是它是一个分布式版本控制系统。”
分布式VCS工具不一定依赖中央服务器来存储项目文件的所有版本。相反，每个开发人员都“克隆”存储库的副本，并在其自己的硬盘上拥有项目的完整历史记录。

Q5。什么是Git？

我建议您先解释一下git的体系结构，以尝试这个问题，如下图所示。您可以参考以下说明：

• Git是一个分布式版本控制系统（DVCS）。它可以跟踪对文件的更改，并允许您还原到任何特定的更改。
• 它的分布式体系结构提供了优于其他版本控制系统（VCS）的优势，例如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提交，为此我将使用
  git reset –soft HEAD〜N &&
  git commit –edit -m ” $（git log –format =％B –reverse .HEAD @ {N}）”

Q9。什么是Git bisect？您如何使用它来确定（回归）错误的来源？

我建议您首先给Git bisect一个小的定义，Git bisect用于通过二进制搜索来查找引入了bug的提交。Git bisect的命令是
**git bisect

**现在，既然您已经提到了上面的命令，请解释该命令的作用。该命令使用二进制搜索算法来查找项目历史记录中的哪个提交引入了错误。您通过首先告诉它包含臭虫的“坏”提交和引入臭虫之前的“好”提交来使用它。然后，Git bisect在这两个端点之间选择一个提交，并询问您所选择的提交是“好”还是“坏”。它会继续缩小范围，直到找到引入更改的确切提交为止。

Q10。什么是Git rebase？如何在合并之前将其用于解决功能分支中的冲突？

据我说，您应该首先说git rebase是一个命令，它将把另一个分支合并到您当前正在工作的分支中，然后将所有在rebased分支之前的本地提交移动到该历史的顶部科。
现在，您已经为示例定义了Git变基时间，以展示如何在合并之前使用它解决特征分支中的冲突（如果从master创建了一个功能分支，并且从那时起master分支已收到新的提交，Git变基）可用于将要素分支移至母版的顶端。
该命令将有效地重放主节点顶端的功能分支中所做的更改，从而使冲突得以解决。谨慎完成后，这将使功能分支可以相对轻松地合并到master中，有时甚至可以作为简单的快进操作。

Q11。您如何配置Git存储库以在提交之前运行代码完整性检查工具，并在测试失败后阻止它们？

我建议您先简要介绍一下健全性检查。健全性测试或冒烟测试确定了继续测试是否可行和合理。
现在说明如何实现此目的，这可以通过与存储库的预提交挂钩相关的简单脚本来完成。在提交之前，甚至在要求您输入提交消息之前，都会触发预提交挂钩。在此脚本中，可以运行其他工具，例如linters，并对提交到存储库中的更改执行完整性检查。

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

对于此答案，而不仅仅是告诉命令，请解释此命令的确切作用，这样可以说：要获取在特定提交中已更改的列表文件，请使用命令
git diff-tree -r {hash}
给定提交哈希，这将列出该提交中已更改或添加的所有文件。-r标志使命令列出单个文件，而不是仅将它们折叠为根目录名称。
您还可以包括以下提及的要点，尽管它是完全可选的，但将有助于打动面试官。
输出还将包含一些额外的信息，可以通过包含两个标志来轻松抑制它们：
git diff-tree –no-commit-id –name-only -r {hash}
在这里，–no-commit-id将禁止在输出中显示提交哈希，并且–name-only将仅显示文件名，而不是其路径。

Q13。您如何设置一个脚本，以便每次存储库通过推送接收到新的提交时运行？

可以通过三种方式配置脚本，以便每次存储库通过推送接收到新的提交时都运行该脚本，一种方法是根据确切何时需要触发脚本来定义预接收，更新或后接收钩子。

• 将提交推送到目标存储库中时，将调用预接收钩子。绑定到此钩子的任何脚本将在更新任何引用之前执行。这是运行有助于执行开发策略的脚本的有用钩子。
• 更新挂钩的工作方式与预接收挂钩类似，并且在实际进行任何更新之前也会被触发。但是，对于每次推送到目标存储库的提交，都会调用一次更新挂钩。
• 最后，在将更新接受到目标存储库之后，将调用存储库中的接收后挂钩。这是配置简单部署脚本，调用某些持续集成系统，将通知电子邮件发送到存储库维护者等的理想场所。

挂钩对于每个Git存储库都是本地的，并且没有版本化。脚本可以在“ .git”目录下的hooks目录中创建，也可以在其他位置创建，并且可以将指向这些脚本的链接放在目录中。

Q14。您如何在Git中知道分支是否已合并到master中？

我建议您同时包括以下两个命令：
git branch –merged列出已合并到当前分支中的分支。
git branch –no-merged列出尚未合并的分支。