Git面试题手册

Git Submodule 有什么用？git submodule 是一个 Git 功能，它允许一个 Git 仓库中包含其他 Git 仓库作为子模块。这非常适用于以下场景：依赖管理：当项目依赖其他特定版本的外部库或项目时，可以使用子模块来管理这些依赖。这确保了每个使用该项目的人都将使用完全相同版本的外部库。分离大项目：对于大型项目，可以将项目拆分为多个逻辑上独立的部分或组件，每个部分作为一个单独的仓库开发和维护。这样可以提高代码的可维护性和可测试性。例如，假设您正在开发一个大型 Web 应用，该应用使用了一个自定义的用户认证系统。为了保持主项目的简洁，您可以将用户认证系统作为独立的仓库开发，并作为子模块包含在主项目中。如何更新它？更新 git 子模块包含以下步骤：初始化子模块： 如果是第一次检出包含子模块的仓库，需要使用 git submodule init 来初始化本地配置文件，并使子模块准备好被更新。更新子模块： 使用 git submodule update 命令可以将子模块更新到在父仓库中记录的特定提交。如果需要将子模块更新到最新的提交，可以进入子模块的目录，切换到需要的分支（通常是 master 或 main），然后执行 git pull。提交更改： 如果您更新了子模块到一个新的提交，并希望这个更新反映到主项目中，需要在主项目中提交这个更改。这通常包括对子模块的新提交进行 git add 和 git commit。一个实际的例子是，如果你有一个名为 ThirdPartyLibs 的子模块，并且需要更新它到最新可用的版本，你可以这样做：cd ThirdPartyLibsgit pull origin mastercd ..git add ThirdPartyLibsgit commit -m "Update ThirdPartyLibs to latest version"这个流程确保了你的主项目和子模块都被更新并记录了相应的改变。

Git worktree 是一个非常强大的 Git 功能，它允许用户在同一个仓库中同时检出多个工作树。这意味着你可以在不同的工作目录中处理同一个仓库的不同分支，而不需要进行常规的 git checkout 操作，这样可以避免工作目录中未提交的更改或者切换分支时的等待时间。用途和优势：并行处理多个分支：比如，你可以在一个工作树中处理新功能的开发（比如在 feature 分支），同时在另一个工作树中修复紧急bug（比如在 hotfix 分支）。这样可以轻松地在任务之间切换而不会相互影响。代码审查和测试：当你需要审查或测试同事的代码时，你可以使用一个单独的工作树来检出他们的分支，同时保持你的主工作树干净整洁。这样做可以避免混合不同分支的代码导致的混乱。持续集成/持续部署（CI/CD）：在自动化脚本中使用 worktree 可以同时在多个分支上触发构建和测试，这样做可以提高开发流程的效率和自动化水平。实际示例：假设你正在开发一个新功能，同时需要对生产环境中发现的一个严重错误进行快速修复。你可以这样操作：你已经在 master 分支的工作树中工作。使用命令 git worktree add ../hotfix-branch hotfix 创建一个新的工作树，专门用于修复bug。在 hotfix-branch 的工作树中，你可以修改代码并进行测试，而不会影响你在 master 分支的工作。一旦完成，你可以提交修复，并将更改合并回主分支或直接部署。这个功能在管理复杂的项目和多任务处理时显得非常有效，可以大幅提高开发效率和团队的协作能力。

Git中的分支，是指在项目开发过程中，为了不同目的和任务创建的独立工作流。每个分支都是从项目的当前状态（通常是主分支，即master或main）开始，以隔离开发工作，防止对主分支的直接影响。当一个分支的开发工作完成后，它可以通过合并（merge）操作被整合回主分支中，或者与其他分支整合。分支的使用场景举例：功能开发（Feature branches）：假设我们需要开发一个新的功能，比如说一个新的登录界面。为了不影响主分支上的现有代码，我们可以创建一个名为feature-login的分支。在这个分支上，开发人员可以自由实验和开发新功能，完成后通过代码审查和测试，再将其合并回主分支。修复错误（Bugfix branches）：当在产品中发现一个严重的错误时，我们可能需要立即解决这个问题。创建一个bugfix-error123分支可以让我们专注于解决这个问题，而不干扰到主分支上正在进行的其他开发工作。修复完成后，该分支会被合并回主分支。实验（Experimental branches）：如果开发人员想尝试一些高风险或不确定的新技术，他们可以创建一个实验性的分支，如experimental-new-tech。这样，他们可以在不影响主线产品稳定性的情况下自由探索和实验。通过这样的分支管理，Git帮助团队维持代码的清晰和组织结构，同时提高了处理各种开发任务的灵活性和效率。

在 Git 中，要列出与本地仓库关联的所有远程连接，可以使用 git remote 命令。这个命令不仅可以显示所有远程连接的简短名称，还可以通过添加 -v 选项来显示关联的 URL，提供更详细的信息。例如，假设你正在管理一个项目，并已经添加了两个远程仓库，一个是 origin，另一个是 upstream。你可以这样列出所有远程连接：git remote -v这个命令将输出类似于以下内容：origin https://github.com/yourusername/yourproject.git (fetch)origin https://github.com/yourusername/yourproject.git (push)upstream https://github.com/otheruser/project.git (fetch)upstream https://github.com/otheruser/project.git (push)在这个输出中，每个远程存储库都列出了两次，一次用于 fetch（拉取操作），一次用于 push（推送操作），因为这些操作可以关联到不同的 URL。在大多数情况下，fetch 和 push 的 URL 是相同的，除非你手动配置它们以使用不同的 URL。这个命令非常有用，尤其是在加入新团队或接手现有项目时，可以快速了解配置的远程仓库及其角色。通过了解所有远程连接，可以有效地协调源代码的推送、拉取和合并操作，确保源代码管理的流畅性和一致性。

在GitHub上更改pull request的基本分支是一个相对简单的操作，这可以在以下情况中非常有用：比如你创建了一个pull request，但是不慎将其指向了错误的分支，或者在代码审查过程中，团队决定将更改合并至另一个分支。步骤如下：打开GitHub：首先，登录到GitHub，并导航到相应的仓库(Repository)页面。找到Pull Request：在仓库的主页上找到并点击“Pull requests”标签，然后选择你想要修改的pull request。编辑Pull Request：在pull request页面，你会看到一个“Edit”按钮，位于标题右侧。点击这个按钮。更改基本分支：在编辑模式下，你会看到一个名为“base”分支的下拉菜单。这就是当前pull request的目标分支。点击这个下拉菜单，选择一个新的基本分支。这个下拉菜单会列出所有可用的分支。保存更改：选择好新的基本分支后，页面会自动刷新，并显示新基本分支与当前pull request中的更改之间的差异。确认这些更改是你所期望的，然后点击页面上的“Change base”按钮提交你的选择。注意事项：确保兼容性：在更改基本分支之前，确保你的pull request的更改与新基本分支兼容，避免合并冲突。通知团队成员：如果这个变更影响到其他团队成员，确保及时通知他们。实例：假设我最初错误地将一个pull request指向了master分支，但后来意识到这些更改应该合并进develop分支。我将按照上述步骤更改基本分支，并且在操作前，我会检查develop分支的最新状态，确认没有冲突。操作完成后，我还会在团队的沟通渠道（如Slack或邮件）中告知相关同事。通过这样的操作，我们可以确保代码整合的准确性和团队协作的有效性。

在Git中，别名（alias）可以帮助简化命令，使得复杂的命令序列更容易记忆和执行。要列出Git中设置的所有别名，您可以使用Git的配置系统。具体命令如下：git config --get-regexp alias这条命令会检索Git配置文件（通常是.gitconfig或者位于仓库.git/config中的文件），查找所有以“alias”开头的配置项，并将它们显示出来。每个别名都会按照alias.<name> <command>的格式列出，其中<name>是别名的名称，<command>是与之对应的Git命令。例如，如果您之前设置了以下别名：将 git cm 设为 git commit -m将 git st 设为 git status将 git lg 设为 git log --graph --oneline执行 git config --get-regexp alias 后的输出将类似于：alias.cm commit -malias.st statusalias.lg log --graph --oneline这样您就可以快速查看所有已设置的别名及其对应的Git命令。

git stash drop 是 Git 版本控制系统中的一个命令，它用于删除存储堆栈中的一个存储项。Git 的存储（stash）功能允许开发者临时保存他们未完成的工作，以便可以在不提交不完整变更的情况下，切换分支或执行其他版本控制操作。当使用 git stash 命令时，所有当前的更改（包括暂存的和非暂存的更改）都会被保存起来，这个过程称为“stashing”。这样做可以让开发者得到一个干净的工作目录，从而可以自由地切换到其他任务上。在默认情况下，每次使用 git stash 时，都会在 stash 列表中创建一个新的条目。有时候，开发者可能决定某个已经保存的 stash 项不再需要了，这时候就可以使用 git stash drop 命令来删除它。如果不指定具体的 stash 项，默认情况下 git stash drop 会删除最新的 stash 项，也就是说 stash@{0}。如果想要删除特定的 stash 项，可以在命令后面指定它的编号，比如 git stash drop stash@{2}。例子假设一个开发者正在修复一个bug，但突然需要切换到另一个分支处理一个紧急问题。他可以使用以下命令保存当前的工作进度：git stash处理完紧急问题并切换回原来的分支后，他可能决定不再需要先前保存的那些更改，此时可以使用：git stash drop这样，最近一次保存的更改就会被从存储堆栈中移除。如果他有多个 stash 项，并且想要删除特定的一个，他可以查看所有存储的列表：git stash list然后根据需要删除特定编号的stash项：git stash drop stash@{2}这将删除在存储堆栈中编号为2的stash项。

Git Archive 是一个 Git 命令，它的主要功能是创建一个项目历史中特定的版本或者说快照的压缩包。这个命令对于将项目的特定快照导出为归档文件非常有用，特别是在需要部署或共享代码但不包含.git目录时。例如，如果您想要生成当前分支最新提交的归档文件，可以使用以下命令：git archive --format=zip --output=/path/to/output.zip HEAD这个命令会创建一个zip格式的归档文件，包含HEAD（即当前分支最新提交）的内容，存储在指定的输出路径。git archive 命令非常灵活，支持多种输出格式（如 tar, tar.gz, zip 等），同时也允许用户指定要导出的文件或目录，使其更加符合用户的具体需求。一个常见的场景是在部署代码到生产环境时，可能不希望包含版本控制目录 .git，这时就可以使用 git archive 来生成一个干净的代码包。这样做既可以减少部署的文件大小，也增加了部署过程的安全性。

Git Pull vs Git Fetchgit pull 和 git fetch 都是 Git 命令，用于从远端仓库更新本地仓库的代码，但它们在功能上有明显的区别。git fetch功能: git fetch 仅仅下载远程仓库的最新数据到本地，但不会自动合并到当前工作分支。用途: 这个命令用于获取远程仓库的数据，了解变更，但不立即影响你的本地工作环境。这样做的好处是可以先审查这些变更，在合并前有选择性地检查或测试这些变更。行为: 它会将远端的分支状态更新到本地仓库的对应远端分支（通常是 origin/master），但不影响你的本地分支，保持你的当前工作不变。git pull功能: git pull 事实上是 git fetch 后面跟了一个 git merge。这意味着，当执行 git pull 时，Git 不仅会下载远程仓库的最新数据，还会将这些新数据合并到当前分支中。用途: 这个命令用于将远程仓库的变更直接下载并合并到你的本地分支，自动更新你的工作目录。行为: 如果合并是必要的，即本地分支落后于对应的远端分支，它会自动进行合并。如果合并顺利，本地分支将更新至最新状态。使用场景和例子假设你在开发一个功能，在 feature 分支上工作。你的同事刚刚更新了 master 分支并推送到了 GitHub。使用 git fetch: 你可以执行 git fetch origin master 来查看他们的改动，而你当前的开发不会受到影响。之后，你可以用 git diff origin/master 来比较本地 master 分支和远端 master 分支的差异，决定是否合并这些改动到你的 feature 分支。使用 git pull: 如果你直接在 feature 分支上执行 git pull origin master，那么远程的 master 分支的更新将被直接合并到你的 feature 分支中。如果你确定这些改动不会破坏你当前的工作或者你需要这些改动来继续开发，这会是一个快速的方式来更新你的分支。通过以上解释和例子，你可以看到 git fetch 和 git pull 在实际使用上的差异，以及根据不同的需求选择使用哪一个命令。

git blame -L 命令在 Git 版本控制系统中用于显示特定文件的每一行的最后修改内容和修改者的信息，而 -L 参数允许用户指定显示文件中特定行号范围的更改信息。例如，如果您想要查看一个名为 example.txt 的文件中第10行到第20行的修改记录，您可以使用以下命令：git blame -L 10,20 example.txt这个命令会列出 example.txt 文件中第10行到第20行每一行的最后修改者、最后修改的 commit ID 和行内容。这个功能对于代码审查和理解特定代码段历史变更的背景非常有用。它可以帮助开发者快速识别谁最后修改了代码，以及相关的修改是在什么背景下进行的。