前端面试题手册

Git pull request 是一个非常重要的功能，它允许开发者将自己的代码变更合并到主仓库中。这个过程中涉及到几个关键步骤：分支： 开发者首先在本地仓库创建一个新的分支，用于开发新功能或修复bug。这样做的好处是可以保持主分支的稳定性，所有新的开发都在分支上进行。提交： 在新分支上开发完成后，开发者会在本地仓库进行提交，保存改动。推送： 将本地分支推送到远程仓库。这样其他开发者才能看到最新的变更。创建 Pull Request： 开发者在GitHub或其他支持Git的平台上，从自己的分支向主分支发起一个Pull Request(PR)。这是一个请求，希望项目维护者审查代码，并将其合并到主分支。代码审查： 项目维护者或其他团队成员可以查看变更，提出建议或要求修改。这个过程可以保证代码的质量，避免引入bug。合并： 一旦Pull Request得到批准，它就可以被合并到主分支。这样，新的代码就会成为项目的一部分。例如，在我之前的项目中，我们团队使用Git和GitHub来管理源代码。我负责一个新功能的开发，我在本地创建了一个名为feature-x的分支，并在这个分支上完成了开发。之后，我将这个分支推送到GitHub，并对主分支发起了一个Pull Request。我的团队成员对我的代码进行了审查，并提出了一些优化建议。我根据这些建议修改了代码，并更新了Pull Request。最终，我的代码通过审查并成功合并到了主分支。这个过程不仅确保了代码的质量，也促进了团队之间的沟通和协作。

.gitignore 文件是一个文本文件，它告诉 Git 哪些文件或目录是可以被忽略的，不需要添加到版本控制系统中。当我们在使用 Git 进行项目管理时，通常会有一些文件或目录不需要或不应该被提交到远程仓库中，例如用户的敏感信息、编译生成的文件或者特定的配置文件等。在 .gitignore 文件中，我们可以定义一系列规则来匹配需要忽略的文件或目录。这些规则可以使用通配符等方式来指定，比如：*.log 表示忽略所有扩展名为 .log 的文件。build/ 表示忽略整个 build 目录。!important.log 表示不忽略 important.log 文件，即使它满足之前定义的忽略规则。举个具体的例子，假设我在开发一个 Java 项目，通常会有编译生成的 .class 文件，这些文件没必要加入版本控制，因为它们可以从源代码重新编译生成。此时，我可以在 .gitignore 文件中添加如下规则：*.class这样，所有的 .class 文件都会被 Git 忽略，不会被误加入到版本库中，从而保持仓库的干净和管理的有效性。

git checkout --track <remote/branch> 命令的作用是创建一个新的本地分支，该分支跟踪指定的远程分支。这意味着您可以在本地对这个分支进行修改和更新，同时保持与远程分支的同步。当您使用这个命令时，Git 会自动将本地分支设置为跟踪远程分支。这样做的好处包括：自动同步远程分支的变化：当远程分支更新时，您可以通过 git pull 命令轻松地将这些更新拉取到本地分支。简化推送操作：由于本地分支已设置为跟踪远程分支，因此在使用 git push 命令时无需指定远程仓库和分支名称。示例：假设您在团队中工作，团队使用名为 origin 的远程仓库，并在其中有一个名为 feature-x 的分支。您想在本地创建一个新分支来跟踪这个远程分支，并开始向该特性贡献代码。您可以执行以下命令：git checkout --track origin/feature-x执行此命令后，Git 会创建一个名为 feature-x 的本地分支，并自动设置为跟踪 origin/feature-x。这样，您就可以在本地工作并保持与远程分支的同步了。

git rm 命令主要用于从工作目录和索引中删除文件。这意味着文件不再被 Git 跟踪。当文件从索引中移除后，它也会在下一次提交时从仓库中删除。使用场景示例：假设在一个项目中我们不再需要一个名为 old_version.py 的文件。为了从 Git 仓库中删除这个文件，我们可以使用以下命令：git rm old_version.py执行此命令后，old_version.py 会从工作目录中删除，并且此更改会被添加到暂存区，准备下一次提交。完成此操作后，我们需要进行提交，以使更改生效并更新仓库状态：git commit -m "Remove old_version.py as it is no longer needed"除了删除文件，git rm 还可以用于删除目录（使用 -r 参数来递归删除目录），或者用 --cached 选项从 Git 索引中删除文件而保留在工作目录中，这在处理误加入跟踪的文件时非常有用。

git checkout、git reset 和 git revert 是 Git 中用于管理代码版本和历史的三个关键命令，它们各自有不同的用途和影响。git checkoutgit checkout 主要用于切换分支或恢复工作目录中的文件。例如，如果我想切换到一个名为 feature-x 的分支，我会执行：git checkout feature-x此命令也可以用来检出某个特定的文件到一个指定的版本，比如我想将 index.html 文件恢复到上一个版本，可以使用：git checkout HEAD^ index.htmlgit resetgit reset 主要用于撤销过去的提交。它可以根据需要调整 HEAD（当前分支的指针），索引（暂存区），和工作目录的状态。使用 --soft 参数，git reset 将 HEAD 移动到指定的提交，但不改变索引文件或工作目录。这常用于撤销一个还未推送的 commit，而保留所有文件的改动，以便重新提交。 git reset --soft HEAD^使用 --mixed 参数（默认选项），git reset 会将 HEAD 和索引都重置到指定的提交，但不改变工作目录。这对于撤销已暂存的文件很有用。 git reset HEAD^使用 --hard 参数，git reset 会将 HEAD、索引和工作目录都重置到指定的提交。这是一个危险的操作，因为它会丢失所有未提交的更改。 git reset --hard HEAD^git revertgit revert 用于撤销一个特定的提交，但与 git reset 不同的是，它通过创建一个新的提交来实现这一点，这个新提交是旧提交的逆操作。这使得它成为一个在多人协作项目中更安全的选择，因为它不会改变项目的历史。例如，如果我想撤销一个错误的提交（commit id 为 a1b2c3d），我可以使用：git revert a1b2c3d这会创建一个新的提交，其中包含了撤销 a1b2c3d 提交所做的所有更改。总结git checkout 主要用于切换分支或恢复文件。git reset 主要用于撤销提交，并可以根据参数选择性地调整索引或工作目录。git revert 用于通过创建逆向提交来撤销过去的提交，这在多人协作环境中尤为重要。这些命令的选择取决于你想要达成的目标和你的具体需求。

Git fsck 的作用是用来检查并验证 Git 文件系统中的内部完整性。它全称是 "File System Consistency Check"，即“文件系统一致性检查”。这个命令会遍历所有的对象（包括提交、树、标签和blob对象）并检查它们的连接关系是否正常，以及内容的哈希值是否与存储时的哈希值相符，从而确保 Git 仓库的数据未被损坏或篡改。如何使用 git fsck?基本的使用方法是在命令行中输入：git fsck这条命令会检查仓库中所有的对象，列出存在的任何问题，比如悬空引用或损坏的对象等。可选参数：--verbose 或 -v：显示所有被处理的对象，即使它们没有问题。--full：进行一次完全检查，这会花费更多的时间，但是检查更为彻底。--dangling：只报告悬挂对象（即在任何分支、标签或其他引用中没有引用的对象）。--unreachable：报告无法从任何引用到达的对象。--no-reflogs：在检查过程中忽略 reflog 中的引用。示例：假设你的 Git 仓库中可能因为某些操作错误或者其他原因导致了数据错误，你可以使用以下命令来检查：进行基本检查： git fsck使用详细模式，查看更多信息： git fsck --verbose查找悬空或未连接的对象： git fsck --dangling这个命令在日常使用中比较少见，但在数据疑似被损坏或者进行系统迁移等情况下非常有用。例如，如果你从一个老旧的硬盘迁移到一个新硬盘，可以在迁移后使用 git fsck 来确保所有数据都被正确迁移无误。

Git Stash 是 Git 版本控制系统中的一个功能，主要用于临时保存还没有准备好提交的修改，从而让开发者可以干净地切换到别的分支进行工作。当你在一个分支上进行工作时，如果需要临时切换到另一个分支处理一些事情，而你当前的修改又不足以做一个完整的提交，这时你就可以使用 git stash 命令来保存当前工作进度。git stash 会把你的工作区的和暂存区的改动保存起来，让工作目录回到最近一次的 commit 状态，从而可以切换分支而不影响当前分支。使用场景示例：假设我正在 feature 分支上开发一个新功能，此时需要紧急修复 master 分支上的一个 bug。我的当前工作还不完整，无法提交。这时，我可以使用以下命令：git stash此命令会保存我在 feature 分支上的改动，并将工作目录恢复到最近的 commit 状态。接下来，我可以安心切换到 master 分支进行 bug 修复。修复完成后，我可以切换回 feature 分支，并使用以下命令恢复之前的工作状态：git stash pop这个命令会应用之前存储的 stash，并尝试将其从 stash 列表中移除。总结来说，git stash 是处理多任务间切换的非常有用的工具，它确保你的工作目录和暂存区状态可以被保存和恢复，使得跨分支的工作变得更加灵活和安全。

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帮助团队维持代码的清晰和组织结构，同时提高了处理各种开发任务的灵活性和效率。