这可能是您在面试中最容易遇到的问题。我的建议是首先给出版本控制的定义。它是一个记录一段时间内对一个文件或一组文件的更改的系统,以便您以后可以调用特定版本。版本控制系统由一个中央共享存储库组成,同事可以在其中对文件或文件集进行更改。然后,您可以提及版本控制的用途。
版本控制可让您:
我建议您包括以下版本控制优点:
询问这个问题是为了测试您的分支经验,因此请告诉他们您在上一份工作中使用分支的方式以及该分支的目的是什么,您可以参考以下几点:
最后告诉面试官,分支策略在一个组织之间会有所不同,所以我知道基本的分支操作,例如删除,合并,签出分支等。
您可以仅提到您曾经使用过的VCS工具:“我从事过Git,与SVN等其他VCS工具相比,它具有一个主要优势是它是一个分布式版本控制系统。” 分布式VCS工具不一定依赖中央服务器来存储项目文件的所有版本。相反,每个开发人员都“克隆”存储库的副本,并在其自己的硬盘上拥有项目的完整历史记录。
我建议您先解释一下git的体系结构,以尝试这个问题,如下图所示。您可以参考以下说明:
以下是一些基本的Git命令:
这个问题可能有两个答案,因此请确保同时包括这两个原因,因为根据情况,可以使用以下任一选项:
有两种方法可以将最后的N个提交压缩为一个提交。在答案中包括以下两个选项:
我建议您首先给Git bisect一个小的定义,Git bisect用于通过二进制搜索来查找引入了bug的提交。Git bisect的命令是 **git bisect
**现在,既然您已经提到了上面的命令,请解释该命令的作用。该命令使用二进制搜索算法来查找项目历史记录中的哪个提交引入了错误。您通过首先告诉它包含臭虫的“坏”提交和引入臭虫之前的“好”提交来使用它。然后,Git bisect在这两个端点之间选择一个提交,并询问您所选择的提交是“好”还是“坏”。它会继续缩小范围,直到找到引入更改的确切提交为止。
据我说,您应该首先说git rebase是一个命令,它将把另一个分支合并到您当前正在工作的分支中,然后将所有在rebased分支之前的本地提交移动到该历史的顶部科。 现在,您已经为示例定义了Git变基时间,以展示如何在合并之前使用它解决特征分支中的冲突(如果从master创建了一个功能分支,并且从那时起master分支已收到新的提交,Git变基)可用于将要素分支移至母版的顶端。 该命令将有效地重放主节点顶端的功能分支中所做的更改,从而使冲突得以解决。谨慎完成后,这将使功能分支可以相对轻松地合并到master中,有时甚至可以作为简单的快进操作。
我建议您先简要介绍一下健全性检查。健全性测试或冒烟测试确定了继续测试是否可行和合理。 现在说明如何实现此目的,这可以通过与存储库的预提交挂钩相关的简单脚本来完成。在提交之前,甚至在要求您输入提交消息之前,都会触发预提交挂钩。在此脚本中,可以运行其他工具,例如linters,并对提交到存储库中的更改执行完整性检查。
对于此答案,而不仅仅是告诉命令,请解释此命令的确切作用,这样可以说:要获取在特定提交中已更改的列表文件,请使用命令 git diff-tree -r {hash} 给定提交哈希,这将列出该提交中已更改或添加的所有文件。-r标志使命令列出单个文件,而不是仅将它们折叠为根目录名称。 您还可以包括以下提及的要点,尽管它是完全可选的,但将有助于打动面试官。 输出还将包含一些额外的信息,可以通过包含两个标志来轻松抑制它们: git diff-tree –no-commit-id –name-only -r {hash} 在这里,–no-commit-id将禁止在输出中显示提交哈希,并且–name-only将仅显示文件名,而不是其路径。
可以通过三种方式配置脚本,以便每次存储库通过推送接收到新的提交时都运行该脚本,一种方法是根据确切何时需要触发脚本来定义预接收,更新或后接收钩子。
挂钩对于每个Git存储库都是本地的,并且没有版本化。脚本可以在“ .git”目录下的hooks目录中创建,也可以在其他位置创建,并且可以将指向这些脚本的链接放在目录中。
我建议您同时包括以下两个命令: git branch –merged列出已合并到当前分支中的分支。 git branch –no-merged列出尚未合并的分支。
本文由 Java架构师必看 作者:javajgs_com 发表,其版权均为 Java架构师必看 所有,文章内容系作者个人观点,不代表 Java架构师必看 对观点赞同或支持。如需转载,请注明文章来源。