Git

基础

Git 是一个分布式版本控制系统，用于跟踪和管理代码的变化，广泛应用于软件开发中。一般用于多人开发，或者是版本管理的

组成部分：

工作区（Working Directory）：你本地修改代码的目录。

暂存区（Staging Area/Index）：用于暂存准备提交的更改。

本地仓库（Local Repository）：存储提交的代码版本。

远程仓库（Remote Repository）：托管在远程服务器（如 GitHub、GitLab）的代码仓库。

流程：修改代码 → 暂存更改（git add） → 提交到本地仓库（git commit） → 推送到远程仓库（git push）。

从远程仓库拉取更新（git pull）或克隆仓库（git clone）。

命令

git init 初始化仓库，建立一个.git文件夹

git clone ssh/http克隆仓库

git status 查看工作区的状态

git add 添加文件。git add .添加所有

git commit -m “”提交

git log 查看提交历史

git log —oneline # 简洁显示

git log —graph # 显示分支图形

git branch 列出本地分支

git branch -r 远程分支

git branch -a 列出所有分支

git branch < name>新建分支

git checkout < name>切换分支

git checkout -b < name>切换并创建分支

git merge < name>合并分支，可能要处理分支冲突

git branch -d < name>删除已经合并的分支

git branch -D < name> 强制删除

git remote add origin 添加远程仓库

git remote -v 查看远程仓库

git push origin main 推送本地到某某分支

git pull origin main 拉起分支，相当于 git fetch + git merge。

git restore < file>撤销工作区修改

这些都是需要某次提交的hash值的

git restore —staged 撤销暂存区修改

git reset —soft 撤销提交，但修改还在

git reset —hard 撤销提交，修改也不要

git revert 回滚到某次提交

git fetch 只获取更新的内容，不合并

git diff 工作区和暂存区的差异

git diff —staged 暂存区和上次提交的差异

将当前分支的提交应用到另一分支上

git rebase

解决冲突后继续：git rebase —continue

中止变基：git rebase —abort

gitignore：

  • 创建 .gitignore 文件，忽略不需要跟踪的文件（如 node_modules/、.env）。

扩展命令：

  • git checkout — files 把文件从暂存区域复制到工作目录，用来丢弃本地修改。
  • git reset — files 用来撤销最后一次git add files，你也可以用git reset 撤销所有暂存区域文件。
  • git checkout HEAD — files 回滚到复制最后一次提交。

问题解决

合并冲突

合并或拉取时可能发生冲突，Git 会标记冲突文件。

当发生冲突时，Git 会提示您文件中的冲突部分。您可以使用以下命令查看所有冲突文件的状态。

1
git status
  1. 打开包含冲突的文件，您会看到类似以下的标记：
1
2
3
4
5
<<<<<<< HEAD
// 代码来自目标分支
=======
// 代码来自要合并的分支
>>>>>>> branchName

您需要手动编辑这些文件，决定保留哪些变更或者如何整合这些变更。

完成冲突解决后，对已解决的文件使用以下命令标记为已解决。

1
2
git add <file> 
git commit

误提交

修改最后一次提交：git commit —amend

回滚到之前版本：git reset 或 git revert

远程推送被拒绝

通常是远程仓库有更新，先拉取：git pull —rebase，然后再推送。

面试题目

1.git rebase和merge的区别

  • Rebase（变基）是将一个分支上的提交逐个地应用到另一个分支上，使得提交历史变得更加线性。当执行rebase时，Git会将目标分支与源分支的共同祖先以来的所有提交挪到目标分支的最新位置。这个过程可以看作是将源分支上的每个提交复制到目标分支上。简而言之，rebase可以将提交按照时间顺序线性排列。

常用来更新的时候

  • Merge（合并）是将两个分支上的代码提交历史合并为一个新的提交。在执行merge时，Git会创建一个新的合并提交，将两个分支的提交历史连接在一起。这样，两个分支的修改都会包含在一个合并提交中。合并后的历史会保留每个分支的提交记录。

2.解释“git pull”和“git fetch”之间有什么区别？

在Git中，git fetch和git pull都是用于从远程仓库获取更新的命令，但它们的工作方式有所不同。

git fetch

  • 功能: 只从远程仓库获取更新，不会将这些更新合并到当前分支。
  • 用途: 它会下载所有的提交、分支和标签，更新本地的远程跟踪分支（如origin/master），但不会改变你的工作目录或当前分支的内容。
  • 场景: 适合在想要查看远程变化但不希望立即合并的情况下使用。你可以先审查更新，决定接下来是否要合并。

git pull

  • 功能: 是git fetch和git merge的组合命令。它首先会执行git fetch，然后会将获取的更新合并到当前分支。
  • 用途: 直接将远程分支的变化合并到你当前的工作分支，适合希望快速同步远程更改并工作于最新状态的场景。
  • 场景: 适用于当你确信需要立即合并远程更新时，方便快速将最新的更改合并到本地。

3.简述Git和SVN有什么区别？

Git和SVN（Subversion）都是版本控制系统，但它们在设计理念、工作流程和功能等方面有显著的区别。以下是一些主要区别：

  1. 版本控制模型：
    • SVN：基于集中式版本控制系统（CVCS），所有版本历史记录保存在中央服务器上，工作副本直接与中央库交互。
    • Git：基于分布式版本控制系统（DVCS），每个开发者的工作副本都包含整个代码库的历史记录，操作可以在本地完成。
  2. 性能：
    • SVN：对于大文件的处理和网络操作可能比较慢，因为每次提交或更新都需要与中央服务器交互。
    • Git：大部分操作（如提交、分支、合并等）都在本地进行，速度更快，尤其是在离线时。
  3. 分支和合并：
    • SVN：分支和标签是从中央库创建的，相对较重，使用上不够灵活。
    • Git：分支操作轻量且快速，鼓励频繁创建和使用分支，合并操作也相对简单。
  4. 数据完整性：
    • SVN：依赖中央服务器的数据完整性，尽管有一定的安全措施，但主要依靠服务器来维护数据。
    • Git：通过SHA-1哈希值来确保每次提交的完整性，每个提交都是整个历史的一部分，易于追踪和验证。
  5. 工作流：
    • SVN：通常采用拉/推的工作流，开发者需要从中央库更新，提交时也要推送到中央库。
    • Git：支持多种工作流（如Forking、Feature Branch等），开发者可以在本地进行完全隔离的开发，之后再选择何时将更改推送到中央库。
  6. 使用场景：
    • SVN：适合小团队和需要严格控制版本访问的项目。
    • Git：更适合开源项目和需要频繁更新的团队，灵活性和效率较高。

总的来说，Git更适合现代软件开发的分布式协作需求，而SVN则在一些传统环境中仍然被广泛使用。

4.简述Github和Gitlab的区别？

GitHub和GitLab是两个流行的Git代码托管平台，虽然它们有许多相似之处，但在一些关键方面有所不同：

  1. 主机定位：
    • GitHub：主要是一个基于云的服务，提供代码托管和协作工具。
    • GitLab：可以选择使用云服务，也可以自行托管在本地服务器上，适合更注重私有化和自定义的团队。
  2. 访问控制：
    • GitHub：较为简单的权限管理，主要依赖于组织和仓库的级别设置。
    • GitLab：提供更细粒度的权限管理，允许用户为不同的项目或分支设置不同的访问权限。
  3. 集成功能：
    • GitHub：虽然有GitHub Actions等CI/CD功能，但整体上集成和扩展的选择相对少。
    • GitLab：内置了非常强大的CI/CD功能，几乎所有的DevOps流程都可以在一个平台上完成。
  4. issue追踪与项目管理：
    • GitHub：提供基础的issue追踪功能，涉及的问题管理相对简单。
    • GitLab：提供更全面的项目管理工具，包含时间线、里程碑和更复杂的看板等功能。
  5. 开源与闭源：
    • GitHub：主要为闭源平台，但有一些开源项目。
    • GitLab：提供开源版本，用户可以自由修改和使用。
  6. 社区和生态：
    • GitHub：有着庞大的开发者社区和丰富的开源项目资源。
    • GitLab：社区相对较小，但也在快速增长中，尤其是在DevOps领域。
  7. 费用结构：
    • GitHub：基本的公共仓库免费，但某些高级功能需要付费。
    • GitLab：提供更全面的免费计划，收费方案也根据功能不同而不同。

这些差异使得GitHub和GitLab在满足不同团队和项目需求时，具有各自的优缺点。选择哪个平台主要取决于团队的具体需求和工作流程。

5.