11 个让你哭的 Git 面试难题

2025-05-24

11 个让你哭的 Git 面试难题

11 个让你哭的 Git 面试难题及答案
根据最新的 Stack Overflow 开发者调查，超过 70% 的开发者使用 Git，使其成为全球使用最广泛的版本控制系统 (VCS)。Git 广泛应用于开源和商业软件开发，为个人、团队和企业带来了显著的益处。

🔴 最初发表于FullStack.Cafe - Kill Your Tech & Coding Interview

Q1：什么是 Git fork？fork、branch 和 clone 之间有什么区别？

主题：Git
难度：⭐⭐

  • 分支(fork)是指远程服务器端对仓库的复制，与原始仓库不同。分支并非 Git 特有的概念，而更像是一种政治/社会概念。
  • 克隆并非分叉；克隆是某个远程仓库的本地副本。克隆实际上是复制整个源仓库，包括所有历史记录和分支。
  • 分支是一种处理单个代码库中变更的机制，以便最终将其与代码库的其余部分合并。分支是代码库中的一个部分。从概念上讲，它代表一个开发线程。

🔗来源： stackoverflow.com

Q2：“拉取请求”和“分支”有什么区别？

主题：Git
难度：⭐⭐

  • 分支只是代码的一个单独版本。

  • 拉取请求是指某人获取存储库，创建自己的分支，进行一些更改，然后尝试合并该分支（将他们的更改放入其他人的代码存储库中）。

🔗来源： stackoverflow.com

Q3：“git pull”和“git fetch”有什么区别？

主题：Git
难度：⭐⭐

用最简单的话来说，git pull就是 agit fetch后面跟着 a git merge。

  • 当您使用 时pull，Git 会尝试自动为您完成工作。它是上下文敏感的，因此 Git 会将所有拉取的提交合并到您当前正在处理的分支中。pull 会自动合并提交，而无需您先进行审核。如果您不仔细管理分支，可能会频繁遇到冲突。

  • 当你 时fetch，Git 会从目标分支收集当前分支中不存在的所有提交，并将它们存储在本地存储库中。但是，它不会将它们与当前分支合并。如果你需要保持存储库更新，但正在处理某些文件更新可能导致程序崩溃的情况，此功能尤其有用。要将提交集成到主分支，请使用merge。

🔗来源： stackoverflow.com

Q4：如何在 git 中恢复之前的提交？

主题：Git
难度：⭐⭐⭐

假设你有这个，其中 C 是你的 HEAD 而 (F) 是你的文件的状态。

   (F)
A-B-C
    ↑
  master
Enter fullscreen mode Exit fullscreen mode
  • 要删除提交中的更改：
git reset --hard HEAD~1
Enter fullscreen mode Exit fullscreen mode

现在 B 是 HEAD。因为你使用了 --hard，所以你的文件会被重置到提交 B 时的状态。

  • 要撤消提交但保留更改：
git reset HEAD~1
Enter fullscreen mode Exit fullscreen mode

现在我们告诉 Git 将 HEAD 指针向后移动一个提交（B），并保持文件原样，并git status显示已签入 C 的更改。

  • 撤消您的提交但保留您的文件和索引
git reset --soft HEAD~1
Enter fullscreen mode Exit fullscreen mode

当您这样做时git status，您会看到索引中的文件与以前相同。

🔗来源： stackoverflow.com

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

主题：Git
难度：⭐⭐⭐

git cherry-pick命令通常用于将仓库中某个分支的特定提交引入到另一个分支。一种常见的用法是将维护分支的提交向前移植或向后移植到开发分支。

这与其他方法（例如合并和变基）形成对比，这些方法通常将许多提交应用到另一个分支上。

考虑：

git cherry-pick <commit-hash>
Enter fullscreen mode Exit fullscreen mode

🔗来源： stackoverflow.com

Q6：解释一下 Forking Workflow 的优点

主题：Git
难度：⭐⭐⭐

Forking 工作流与其他流行的 Git 工作流有着根本的不同。它不再使用单个服务器端仓库作为“中央”代码库，而是为每个开发者提供专属的服务器端仓库。Forking 工作流在公共开源项目中最为常见。

Forking 工作流的主要优势在于，无需每个人都将代码推送到单一的中央仓库，即可整合所有贡献，从而保持项目历史记录的清晰。开发者可以推送到他们自己的服务器端仓库，而只有项目维护者可以推送到官方仓库。

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

🔗资料来源： atlassian.com

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

主题：Git
难度：⭐⭐⭐

  • 工作树/工作目录/工作区是您查看和编辑的（源）文件的目录树。
  • 索引/暂存区是 /.git/index 中的一个单独的、大型的二进制文件，其中列出了当前分支中的所有文件、它们的 sha1 校验和、时间戳和文件名 - 它不是包含文件副本的另一个目录。
  • HEAD是对当前签出分支中的最后一次提交的引用。

🔗来源： stackoverflow.com

Q8：您能解释一下 Gitflow 工作流程吗？

主题：Git
难度：⭐⭐⭐

Gitflow 工作流采用两个并行的长期运行分支来记录项目的历史记录，master并且develop：

  • Master - 随时准备在 LIVE 上发布，所有内容都经过了全面测试和批准（已准备好投入生产）。

    • 热修复分支- 维护分支或“热修复”分支用于快速修补生产版本。热修复分支与发布分支和功能分支非常相似，只是它们基于master而不是develop。

  • 开发分支- 所有功能分支都会合并到这个分支，所有测试都会在此进行。只有彻底检查并修复所有问题后，才能将其合并到master.

    • 功能- 每个新功能都应位于其自己的分支中，并且可以将其推送到develop作为其父分支的分支。

Gitflow 工作流程

🔗资料来源： atlassian.com

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

主题：Git
难度：⭐⭐⭐

该git stash命令将获取您未提交的更改（暂存和未暂存的更改），将其保存以供日后使用，然后从您的工作副本中恢复它们。

考虑：

$ git status
On branch master
Changes to be committed:
new file: style.css
Changes not staged for commit:
modified: index.html
$ git stash
Saved working directory and index state WIP on master: 5002d47 our new homepage
HEAD is now at 5002d47 our new homepage
$ git status
On branch master
nothing to commit, working tree clean
Enter fullscreen mode Exit fullscreen mode

我们可以使用存储的一个地方是，如果我们发现我们在上次提交中忘记了某些内容，并且已经开始在同一分支中处理下一个提交：

# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something

# stash away the current mess I made
$ git stash save

# some changes in the working dir

# and now add them to the last commit:
$ git add -u
$ git commit --ammend

# back to work!
$ git stash pop
Enter fullscreen mode Exit fullscreen mode

🔗资料来源： atlassian.com

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

主题：Git
难度：⭐⭐⭐⭐

如果您在 过程中不小心git add，可能会添加一些您不想提交的文件。然而，git rm会将其从您的暂存区（索引）和文件系统（工作树）中移除，这可能并非您想要的结果。

而是使用git reset：

git reset filename          # or
echo filename >> .gitingore # add it to .gitignore to avoid re-adding it
Enter fullscreen mode Exit fullscreen mode

这意味着git reset <paths>与相反git add <paths>。

🔗来源： codementor.io

Q11：什么时候使用“git rebase”而不是“git merge”？

主题：Git
难度：⭐⭐⭐⭐⭐

这两个命令都旨在将一个分支的更改集成到另一个分支 - 它们只是以非常不同的方式执行。

合并/重新定基之前请考虑：

A <- B <- C    [master]
^
 \
  D <- E       [branch]
Enter fullscreen mode Exit fullscreen mode

后git merge master：

A <- B <- C
^         ^
 \         \
  D <- E <- F
Enter fullscreen mode Exit fullscreen mode

后git rebase master：

A <- B <- C <- D <- E
Enter fullscreen mode Exit fullscreen mode

使用 rebase 你说要使用另一个分支作为你工作的新基础。

何时使用：

  1. 如果您有任何疑问，请使用合并。
  2. 根据您希望的历史记录的样子来选择重新定基或合并。

更多需要考虑的因素：

  1. 您要从中获取更改的分支是否与团队外部的其他开发人员共享（例如开源、公共）？如果是，请勿进行变基。变基会破坏该分支，除非这些开发人员使用 ，否则他们的代码库将损坏/不一致git pull --rebase。
  2. 你的开发团队技术水平如何？ Rebase 是一种破坏性操作。这意味着，如果你没有正确应用它，你可能会丢失已提交的工作，并且/或者破坏其他开发者代码库的一致性。
  3. 分支本身是否包含有用的信息？有些团队使用“每个功能分支”模型，每个分支代表一个功能（或错误修复、子功能等）。在这种模型中，分支有助于识别相关提交集。如果是“每个开发人员分支”模型，分支本身不会传达任何额外信息（提交已经有作者信息）。因此，进行 rebase 操作也无妨。
  4. 您是否出于任何原因想要恢复合并？与恢复合并相比，恢复（即撤销）变基操作相当困难，甚至不可能（如果变基操作存在冲突）。如果您认为有可能想要恢复，请使用合并。

🔗来源： stackoverflow.com

感谢🙌的阅读，祝你面试顺利！
更多 FullStack 面试问答，请访问👉 www.fullstack.cafe

文章来源：https://dev.to/fullstackcafe/11-painful-git-interview-questions-you-will-cry-on-1n2g
Devto 翻译
PREV
2020 年每个开发人员都应该知道的 22 个 PWA 面试问题
NEXT
JavaScript forEach 你应该知道的 10 个 JavaScript 数组方法