【前端高频面试题--git篇】

🚀 作者：“码上有前”
🚀 文章简介：前端高频面试题
🚀 欢迎小伙伴们点赞👍、收藏⭐、留言💬

前端高频面试题--git篇

常用命令
git add 和 git stage 有什么区别
怎么使用git连接到远程仓库github/gitlab/gitee等
开发过程中使用git进行工作，需要哪些步骤，使用到了哪些命令？
git reset、git revert 和 git checkout 有什么区别
GitFlow 基本流程和你的理解
解释下 PR 和 MR 的区别
git merge 和git rebase的区别？

常用命令

在这里插入图片描述
以下是一些常用的 Git 命令：

创建和克隆仓库：
- git init: 在当前目录下创建一个新的 Git 仓库。
- git clone <仓库地址>: 克隆一个远程仓库到本地。
基本操作：
- git add <文件>: 将文件添加到暂存区。
- git commit -m "<提交信息>": 将暂存区的更改提交到本地仓库。
- git push <远程仓库> <分支>: 将本地分支的提交推送到远程仓库。
- git pull <远程仓库> <分支>: 从远程仓库拉取最新的提交到本地分支。
- git status: 查看当前仓库的状态。
- git log: 查看提交历史记录。
分支操作：
- git branch: 查看当前仓库的分支列表。
- git branch <分支名>: 创建一个新的分支。
- git checkout <分支名>: 切换到指定的分支。
- git merge <分支名>: 将指定分支的更改合并到当前分支。
- git branch -d <分支名>: 删除指定的分支。
远程仓库操作：
- git remote: 查看当前仓库配置的远程仓库。
- git remote -v: 查看当前仓库配置的远程仓库的详细信息。
- git remote add <远程仓库名> <远程仓库地址>: 添加一个新的远程仓库。
- git remote remove <远程仓库名>: 移除指定的远程仓库。
撤销和回滚：
- `git reset <提交>: 将 HEAD 指针和当前分支的引用重置到指定提交。
- git revert <提交>: 创建一个新的提交来撤销指定提交的更改。
- git checkout -- <文件>: 恢复指定文件到最近的提交状态。

这只是一小部分 Git 命令的示例。Git 命令非常丰富，可以根据实际需求和工作流程选择适合的命令来完成任务。

git add 和 git stage 有什么区别

在 Git 中，git add 和 git stage 实际上是同一个命令的两种形式，它们用于将文件添加到暂存区（也称为索引或缓存区），以准备进行提交。

git add 是 Git 的原始命令，用于将工作目录中的文件添加到暂存区。例如，要将名为 file.txt 的文件添加到暂存区，可以运行以下命令：

git add file.txt

此命令将 file.txt 文件的当前状态添加到暂存区，以便在下一次提交时包含该文件的更改。

而 git stage 是 git add 的一个别名，它们的功能完全相同。git stage 是一些 Git 命令行工具和 Git 用户界面工具提供的更友好和直观的别名。这样的别名可以使命令更易于记忆和使用。

因此，无论是使用 git add 还是 git stage，都是将文件添加到暂存区的操作。它们可以用来跟踪文件的更改，并将这些更改准备好以进行下一次提交。

怎么使用git连接到远程仓库github/gitlab/gitee等

要将本地 Git 仓库连接到远程仓库（如 GitHub、GitLab 或 Gitee），可以按照以下步骤进行操作：

创建远程仓库：在相应的代码托管平台（如 GitHub、GitLab 或 Gitee）上创建一个新的空白仓库。获取远程仓库的 URL，这将用于将本地仓库与远程仓库进行关联。
在本地仓库中添加远程仓库：打开命令行终端或 Git 客户端，并导航到本地仓库的根目录。运行以下命令来添加远程仓库：
```
git remote add origin <远程仓库的 URL>
```
这里，origin 是远程仓库的别名，你可以自定义别名。<远程仓库的 URL> 是远程仓库的 URL 地址。
验证远程仓库连接：运行以下命令来验证远程仓库是否成功连接：
```
git remote -v
```
这将显示你的远程仓库的别名和 URL，以确保连接正确。
将本地更改推送到远程仓库：如果你想将本地仓库中的更改推送到远程仓库，可以使用以下命令：
```
git push -u origin <分支名>
```
这将把当前分支的更改推送到远程仓库，并将其与远程仓库的对应分支进行关联。 -u 参数在首次推送时建立了本地分支与远程分支的关联。之后，你可以简单地使用 git push 命令来推送更改。

以上是一般的连接到远程仓库的步骤。具体的命令和操作可能会因使用的代码托管平台和个人设置而有所不同。在使用之前，建议查阅相关平台的文档和指南，以了解特定平台的详细步骤和要求。

开发过程中使用git进行工作，需要哪些步骤，使用到了哪些命令？

在开发过程中使用 Git 进行工作，通常涉及以下几个步骤和常用命令：

克隆仓库：在开始工作之前，你可以使用 git clone 命令将远程仓库克隆到本地：
```
git clone <远程仓库的 URL>
```
这将在当前目录下创建一个与远程仓库相同的本地仓库副本。
创建和切换分支：对于新功能的开发或 bug 修复，你可以创建一个新的分支。使用 git branch 命令创建分支，然后使用 git checkout 命令切换到该分支：
```
git branch <分支名>
git checkout <分支名>
```
或者使用 git checkout -b 命令同时创建并切换到新分支：
```
git checkout -b <分支名>
```
开发和提交更改：在所选分支上进行代码修改和开发。使用 git add 命令将更改的文件添加到暂存区，然后使用 git commit 命令提交更改：
```
git add <文件名>
git commit -m "提交信息"
```
这将把文件的更改从工作目录添加到暂存区，并创建一个新的提交记录。
推送更改：当你准备好将本地分支的更改推送到远程仓库时，可以使用 git push 命令：
```
git push origin <分支名>
```
这将把本地分支的更改推送到远程仓库的对应分支。
合并分支：在完成功能或修复 bug 后，你可能需要将所做的更改合并回主分支。可以使用 git merge 命令将一个分支的更改合并到当前分支：
```
git merge <分支名>
```
这将把指定分支的更改合并到当前分支。
解决冲突：如果在合并分支时遇到冲突，需要手动解决冲突。打开冲突文件，在文件中标记和编辑冲突的部分，然后使用 git add 命令将解决的文件标记为已解决，最后使用 git commit 命令进行提交。

这些是使用 Git 进行工作时的一些常见步骤和命令。除了上述命令外，还有其他许多命令可用于处理分支、查看提交历史、撤销更改等。详细的 Git 命令和操作可以在 Git 的官方文档或其他教程中找到。

git reset、git revert 和 git checkout 有什么区别

git reset、git revert 和 git checkout 是 Git 中用于处理提交和分支的三个不同命令，它们有以下区别：

git reset: git reset 用于将当前分支的 HEAD 指针和分支引用重置到指定的提交，并可以选择性地更改暂存区和工作目录的状态。主要有三种模式：
- git reset --soft：仅重置分支引用和 HEAD 指针，不修改暂存区和工作目录。这意味着当前更改仍然在暂存区中，并且可以重新提交。
- git reset --mixed（默认模式）：重置分支引用和 HEAD 指针，并重置暂存区以匹配指定提交。这将取消暂存区中的更改，但保留更改的文件内容，以便可以重新暂存或修改后重新提交。
- git reset --hard：将分支引用、HEAD 指针和暂存区都重置到指定提交。这将完全丢弃暂存区和工作目录中的更改，慎用，可能会导致永久性数据丢失。
git revert: git revert 用于创建一个新的提交来撤销指定提交的更改。它会在撤销提交时保留提交历史，因此适合在共享仓库中撤销公共历史的更改。git revert 将创建一个新的提交，该提交的更改是指定提交的相反操作。这意味着它不会直接修改原始提交，而是创建一个新的提交来撤销之前的更改。
git checkout: git checkout 用于切换分支、恢复文件状态或创建新分支。它的功能有以下几个方面：
- 切换分支：使用 git checkout <分支名> 可以切换到指定的分支。
- 恢复文件状态：使用 git checkout -- <文件名> 可以撤销对指定文件的更改，将其恢复为最近的提交状态。
- 创建新分支：使用 git checkout -b <新分支名> 可以创建并切换到一个新的分支。

总结一下，git reset 用于重置分支引用和 HEAD 指针，可以修改暂存区和工作目录状态；git revert 用于创建一个新的提交来撤销指定提交的更改，保留提交历史；git checkout 用于切换分支、恢复文件状态或创建新分支。

GitFlow 基本流程和你的理解

GitFlow 是一种流行的 Git 分支管理工作流，它定义了一套用于协作开发的分支模型和规范。下面是 GitFlow 的基本流程和我的理解：

主要分支：
- master 分支：代表生产环境的稳定代码。只包含已经发布的正式版本的代码。
- develop 分支：代表下一个发布版本的开发代码。新功能和 bug 修复通常从这个分支开始。
辅助分支：
- 功能分支（Feature branches）：用于开发新功能。从 develop 分支派生，完成后合并回 develop 分支。
- 发布分支（Release branches）：用于准备发布版本。从 develop 分支派生，包含最终要发布的代码和准备发布的工作（如版本号更新、构建等）。完成后合并回 develop 分支和 master 分支，并打上发布版本的标签。
- 热修复分支（Hotfix branches）：用于紧急修复生产环境中的 bug。从 master 分支派生，完成后合并回 develop 分支和 master 分支，并打上修复版本的标签。
工作流程：
- 开发新功能：从 develop 分支创建一个新的功能分支，进行功能开发和测试。完成后将功能分支合并回 develop 分支。
- 准备发布版本：从 develop 分支创建一个新的发布分支，进行版本准备和测试。包括修复 bug、更新版本号等。完成后将发布分支合并回 develop 分支和 master 分支，并打上发布版本的标签。
- 修复生产环境中的 bug：从 master 分支创建一个新的热修复分支，进行紧急 bug 修复。完成后将热修复分支合并回 develop 分支和 master 分支，并打上修复版本的标签。

GitFlow 的优势在于将开发、发布和修复过程分离，并提供了清晰的分支结构和规范，使团队能够进行并行开发和持续交付。它也有助于保持不同环境之间的代码同步，并为版本控制提供可追溯性。

然而，GitFlow 也可能导致分支较多和复杂的合并操作。在团队规模较小或项目较简单的情况下，可以根据实际需求选择更简化的分支管理方式。

解释下 PR 和 MR 的区别

PR（Pull Request）和 MR（Merge Request）是代码托管平台（如GitHub和GitLab）上用于代码审查和合并的术语，它们有以下区别：

PR（Pull Request）：PR 是 GitHub 上的术语，表示从一个分支（通常是开发分支）请求将代码合并到目标分支（通常是主分支）中。PR 允许团队成员对代码进行讨论、审查和提供修改建议。创建 PR 后，其他开发者可以查看代码更改、提交评论、提出问题或请求更改，这有助于团队合作和代码质量的提高。
MR（Merge Request）：MR 是 GitLab 上的术语，与 PR 的概念相似。它也是请求将代码从一个分支合并到另一个分支中，通常是从开发分支合并到主分支。MR 具有类似的功能，包括团队成员的审查、讨论和交流。使用 MR，团队可以共同审查和验证代码，确保它符合质量标准，并且可以顺利合并到目标分支中。

虽然 PR 和 MR 在术语上有所不同，但它们的目标和功能基本相同：促进团队成员之间的代码审查和合作。无论是在 GitHub 还是 GitLab，PR 和 MR 都提供了一种结构化和协作的方式，使团队能够审查、讨论和决定是否接受某个代码更改。

git merge 和git rebase的区别？

git merge 和 git rebase 是用于将一个分支的更改合并到另一个分支的 Git 命令，它们有以下区别：

历史记录的整洁性：
- git merge：将源分支的更改合并到目标分支，并创建一个新的合并提交。这会在目标分支的历史记录中保留源分支的完整提交历史，形成一个合并的提交记录。
- git rebase：将源分支的更改应用到目标分支上，并将目标分支的提交应用在源分支的顶部。这会使提交历史线性化，看起来像是源分支的更改直接在目标分支上进行的。
分支图的清晰性：
- git merge：在分支图中创建一个新的合并提交节点，显示源分支和目标分支的合并关系。
- git rebase：将源分支的提交复制到目标分支的顶部，使分支图保持简单的线性结构，不会有合并提交节点。
修改历史记录：
- git merge：不会修改源分支和目标分支的提交历史记录。
- git rebase：将源分支的提交应用到目标分支上，可以修改源分支的提交历史记录。
协作和共享：
- git merge：适用于多人协作和共享代码库，因为合并提交保留了每个分支的完整历史记录。
- git rebase：更适合个人工作流，可以使提交历史保持线性和整洁。

综上所述，git merge 用于将分支的更改合并到目标分支并创建合并提交，保留完整的提交历史记录。而 git rebase 则是将分支的更改应用到目标分支上，并将目标分支的提交应用在源分支的顶部，使提交历史线性化和整洁。选择使用哪个命令取决于项目的需求、团队的合作方式以及个人偏好。
都看到这啦，嘿嘿，点个赞吧🚀