Git的使用

1. Git概述

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

为什么选择 Git？

Git 是当前最流行的分布式版本控制系统，优势包括：

• ⚡️ 高效：本地操作速度快，支持离线工作。
• 🌳 强大的分支管理：创建、合并分支简单且安全。
• 🔄 灵活性：适合个人项目到超大规模团队协作，如 Linux 内核开发。

1.1 版本控制

版本控制Version Control是一种记录和管理文件变更的技术，主要用于追踪文件的历史修改、协作开发和回溯到任意历史版本。它就像文件的时光机，能让你清楚地知道：

• 谁修改了文件？
• 什么时候修改的？
• 修改了哪些内容？
• 为什么做这些修改？

版本控制的核心作用如下：

• 历史追踪：保存每一次变更记录，可随时回退到任意版本，比如修复 Bug 后发现问题，一键还原代码。
• 协作管理：多人同时修改同一文件时，自动合并变更或提示冲突，避免覆盖他人代码。
• 分支开发：支持创建独立分支，如新功能开发、Bug 修复，不影响主分支的稳定性。
• 责任追溯：记录每次修改的作者和原因，便于团队沟通和问题追踪。

版本控制解决了什么问题？

• ❌ 手动备份混乱：：无需手动保存 report_v1.doc、report_final.doc、report_final2.doc 这类混乱的副本。
• ❌ 代码丢失风险：误删或改错代码时，可快速恢复历史版本。
• ❌ 协作冲突：多人修改同一文件时，系统自动处理或提示冲突，避免代码覆盖。

1.2 版本控制的类型

版本控制主要分为【本地版本控制】、【集中式版本控制】和【分布式版本控制】三种类型，它们在存储方式、协作模式和适用场景上有显著区别。以下是详细对比：

• 本地版本控制：所有版本历史存储在本地计算机，无法多人协作。通过简单的文件快照或差异记录来管理变更。典型工具如RCS。
  • 优点：无需网络，操作简单，适合个人管理少量文件的版本，如论文、配置文档。
  • 缺点：无协作能力，数据丢失风险高。
• 集中式版本控制：所有版本历史存储在中央服务器，开发者通过客户端连接服务器操作。所有版本历史存储在中央服务器，开发者通过客户端连接服务器操作。典型工具如SVN。
  • 优点：支持多人协作，权限管理方便，支持多人协作，权限管理方便。
  • 缺点：服务器宕机时，开发者无法提交代码或查看历史；离线时无法提交或查看历史；创建和合并分支效率较低。
• 分布式版本控制：每个开发者本地都有完整的仓库副本，包括全部历史记录。开发者可离线工作，本地提交后再同步到远程仓库。典型工具如Git。
  • 优点：去中心化，无单点故障，本地仓库可独立运行；支持灵活的分支管理；提交、查看历史等操作无需联网。
  • 缺点：学习曲线较高，本地存储可能占用更多磁盘。

1.3 Git的工作机制

Git 的核心设计是分布式版本控制，所有操作围绕本地仓库展开，再与远程仓库同步。其工作机制可分为三个关键区域和核心流程：

• 三个核心区域

  区域	作用	操作示例
  工作区	本地直接编辑的代码目录	修改文件、新增代码
  暂存区	临时存储准备提交的变更【git add 后的内容】	git add file.txt
  本地仓库	存储所有提交历史的数据库【通过 git commit 永久保存】	git commit -m "message"

• 数据流动流程：工作区 → 暂存区 → 本地仓库 → 远程仓库

  • 工作区修改：编辑代码后，文件处于已修改状态，但未被 Git 跟踪。
  • 暂存变更：通过 git add 将变更添加到暂存区，即准备提交。
  • 提交到本地仓库：git commit 将暂存区的变更永久存储到本地仓库，生成一个唯一的提交记录，含作者、时间、变更内容。
  • 推送到远程仓库：git push 将本地仓库的提交同步到远程服务器，如 GitHub。

• 核心机制特点

  • 快照存储：每次提交保存文件的完整快照而非仅差异，便于快速回溯。
  • 分支本质：分支是指向某个提交的指针，创建分支只需新建一个指针，轻量且高效。
  • 离线操作：所有提交、分支操作均在本地完成，无需联网。

1.4 代码托管中心

代码托管中心是存储 Git 仓库的远程服务器，提供团队协作、备份和项目管理功能。以下是主流平台对比：

代码托管中心的核心作用如下：

• 备份与同步：防止本地数据丢失，多设备间同步代码。
• 协作开发：多人通过 git push/git pull 共享代码。
• 权限管理：控制成员对仓库的访问权限，如只读、可写。
• 项目管理：通过 Issue、Pull Request、Wiki 等功能跟踪任务和文档。

1.5 Git安装

首先从官网上下载Git，然后进行傻瓜式安装，安装之后在桌面鼠标右键打开Open Git Bash Here，即Git的命令行客户端，执行git --version，出现版本信息即安装成功。Git的客户端能够使用所有的Linux命令。

2. Git常用命令

2.1 配置相关

在初次使用 Git 时必须设置用户名和邮箱，Git 需要这些信息来标识代码提交的作者，用于追踪代码变更的责任人。修改的配置文件即用户目录下的.gitconfig文件。

除了全局设置，还可以单仓库设置，如下：

# 进入项目目录
cd /path/to/your-project

# 设置当前仓库的用户名和邮箱
git config user.name "公司用户名"
git config user.email "company@example.com"

# 查看所有配置项【包括全局和当前仓库】
git config --list

# 仅查看全局配置
git config --global --list

# 查看当前仓库的配置
git config --local --list

# 修改全局用户名
git config --global --replace-all user.name "NewName"

# 修改全局邮箱
git config --global --replace-all user.email "new@example.com"

对于配置相关，有以下注意点：

• 邮箱是否需要真实：如果是开源项目如GitHub，建议使用 GitHub 账号绑定的邮箱，否则提交记录不会关联到你的账号。如果是私有仓库，可以自由设置，但需符合团队规范。
• Git读取配置的顺序：仓库配置 > 全局配置

2.2 仓库与基础操作

2.2.1 git init

git init会在指定目录下创建一个新的 Git 仓库，且在该目录下创建一个名为 .git 的隐藏文件夹。这个文件夹包含了 Git 仓库的所有元数据和对象数据库，是 Git 管理项目版本的核心。一旦 git init 命令执行成功，该目录就成为了一个 Git 仓库，你可以开始使用 Git 的各种功能，如添加文件到暂存区、提交文件到本地仓库、创建分支等。

# 进入项目目录
cd /path/to/your/project

# 初始化 Git 仓库
git init

# 输出
86182@tao MINGW64 /e/Git-Space/demo-project
$ git init
Initialized empty Git repository in E:/Git-Space/demo-project/.git/

86182@tao MINGW64 /e/Git-Space/demo-project (master)

2.2.2 git status

git status 命令能够展示当前仓库中文件的状态，这些状态主要涉及工作目录、暂存区和本地仓库之间文件的差异。通过运行该命令，你可以知道哪些文件是新创建的、哪些文件被修改过、哪些文件被删除了，以及这些文件是否已经被添加到暂存区或者提交到本地仓库。在 git status 命令后面跟上指定文件，其作用是查看该特定文件在 Git 仓库中的状态，而不是显示整个仓库所有文件的状态。

$ git status
On branch master

No commits yet

# 未被追踪的文件，可以使用 git add new_file.txt 命令将其添加到暂存区
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hello.txt

nothing added to commit but untracked files present (use "git add" to track)

2.2.3 git add

git add 的核心作用就是把工作目录里发生变更的文件添加到暂存区，为后续的提交操作做准备。具体使用如下：

• 追踪新文件：当你在工作目录中创建了新文件，这些文件最初处于未被 Git 追踪的状态。使用 git add 可以让 Git 开始追踪这些新文件。执行以下命令后，new_file.txt 就被添加到了暂存区，后续可以通过 git commit 提交到本地仓库。

  # 创建一个新文件
  touch new_file.txt
  # 将新文件添加到暂存区
  git add new_file.txt
  

• 暂存已修改的文件：如果你对已经被 Git 追踪的文件进行了修改，使用 git add 可以将这些修改添加到暂存区。

  # 修改 existing_file.txt 文件
  # 将修改添加到暂存区
  git add existing_file.txt
  

• 暂存删除操作：当你删除了工作目录中的文件，使用 git add 可以将删除操作记录到暂存区。

  # 删除文件
  rm deleted_file.txt
  # 将删除操作添加到暂存区
  git add deleted_file.txt
  

• 批量添加文件：git add 支持使用通配符来批量添加文件。

  # 添加当前目录下所有以 .txt 结尾的文件
  git add *.txt
  # 添加当前目录下所有文件
  git add .
  

2.2.4 git commit

git commit 命令将暂存区的修改提交到本地仓库。每一次提交都会生成一个唯一的哈希值commit hash，用于标识该提交，并且会记录提交的作者、提交时间和提交信息等元数据。

# 提交暂存区的修改，并直接输入提交信息
git commit -m "修复登录Bug"

# 直接将工作目录中的修改提交到本地仓库，跳过暂存区
git commit -a -m "修复登录Bug"

86182@tao MINGW64 /e/Git-Space/demo-project (master)
$ git commit -m "first commit" hello.txt
warning: in the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it
[master (root-commit) db13ef1] first commit
 1 file changed, 23 insertions(+)
 create mode 100644 hello.txt

# 指向Second commit
86182@tao MINGW64 /e/Git-Space/demo-project (master)
$ git reflog
eda1f57 (HEAD -> master) HEAD@{0}: commit: Second commit
db13ef1 HEAD@{1}: commit (initial): first commit

86182@tao MINGW64 /e/Git-Space/demo-project (master)

2.2.5 git reset

git reset 命令的主要作用是重置当前分支的 HEAD 指针，而 --hard 选项则表示不仅要重置 HEAD 指针，还要将暂存区和工作目录都恢复到指定提交的状态。也就是说，它会丢弃自指定提交之后的所有本地修改，包括未提交的修改和已暂存但未提交的修改。使用方式有以下几种：

• 提交哈希值

  # 查看提交历史
  git log
  # 重置到指定提交
  git reset --hard 123456789abcdef
  

• 分支名：可以将分支重置到某个分支的最新提交状态。

  git reset --hard main
  

该命令的使用场景如下：

• 撤销本地修改：当你在本地进行了一些修改，但发现这些修改是错误的，或者想要放弃这些修改，回到之前的某个提交状态时，可以使用 git reset --hard 命令。

• 同步远程分支：如果远程分支有新的提交，而你本地的修改不再需要，想要直接将本地分支重置到远程分支的最新状态，可以先拉取远程分支，然后使用 git reset --hard 命令。例如：

  git fetch origin
  git reset --hard origin/main
  

该命令的功能是很强大的，使用时应该慎用，使用不当可能会导致数据丢失，因此需要注意以下事项：

• 数据丢失风险：git reset --hard 会永久丢弃自指定提交之后的所有本地修改，这些修改无法通过常规的 Git 操作恢复。因此，在使用该命令之前，一定要确保你真的想要丢弃这些修改。

• 多人协作问题：在多人协作的项目中，如果使用 git reset --hard 命令将本地分支重置到某个旧的提交，然后再推送到远程仓库，可能会覆盖其他开发者的提交，导致冲突和数据丢失。因此，在多人协作的环境中，要谨慎使用该命令，最好先与团队成员沟通。

• 备份重要修改：如果不确定是否要丢弃某些修改，可以先将这些修改保存到一个新的分支或者使用 git stash 命令将其暂存起来，然后再使用 git reset --hard 命令。如下：

  # 暂存当前修改
  git stash
  # 重置到指定提交
  git reset --hard <commit>
  # 恢复暂存的修改
  git stash pop
  

2.3 分支管理

在 Git 中，分支Branch 是一个非常重要的概念，它允许开发者在不影响主代码的情况下，并行地开发新功能、修复 bug 或进行实验性修改。分支的常用命令如下：

分支的本质如下：

• 轻量级指针：分支本质上是一个指向提交commit的指针，它记录了某个特定版本的代码状态。
• 并行开发：多个分支可以同时存在，每个分支代表不同的开发方向，开发者可以在不同分支上独立工作。

分支的作用如下：

• 隔离开发：避免在主分支如 main 或 master上直接修改代码，防止未完成的功能或错误影响稳定版本。
• 并行工作：团队成员可以在不同分支上同时开发不同的功能，互不干扰。
• 版本管理：通过分支管理不同的版本，如测试版、发布版。
• 灵活回溯：可以基于某个历史提交创建分支，修复旧版本的问题。

分支的工作原理如下：

• 默认分支：初始化 Git 仓库时，会自动创建一个主分支，通常命名为 main 或 master。
• 分支创建：使用 git branch 命令创建新分支，新分支会复制当前分支的代码状态。
• 分支切换：通过 git checkout 或 git switch 命令切换分支，工作目录会更新为目标分支的代码。
• 分支合并：使用 git merge 或 git rebase 命令将分支的修改合并到其他分支。

常见的分支类型如下：

• 主分支（Main Branch）：通常用于存放稳定的生产代码，如 main。
• 功能分支（Feature Branch）：用于开发新功能，完成后合并到主分支。
• 修复分支（Hotfix Branch）：用于紧急修复线上 bug，直接基于主分支创建。
• 实验分支（Experiment Branch）：用于尝试高风险或不确定的修改，失败后可删除。

分支是Git中的核心之一，有以下注意点：

• 避免长期未合并的分支：长期不合并可能导致冲突难以解决。
• 分支命名规范：使用清晰的命名（如 fix/login-bug、feature/payment），便于识别。
• 保护主分支：通过权限控制避免直接提交到主分支，推荐通过合并请求（Pull Request）管理。

分支冲突：分支冲突是指在合并分支的过程中，Git 无法自动决定如何将不同分支上的修改整合到一起，从而需要用户手动介入解决的情况。**当出现分支冲突时，Git 会在合并过程中暂停，并在终端输出相应的冲突信息。同时，冲突的文件会包含特殊的标记，用于指示冲突的位置和内容。**此时可以使用vim进入冲突文件进行手动修改，一般格式如下：

未修改内容
<<<<<<< HEAD
当前分支的修改内容
=======
合并进来的分支的修改内容
>>>>>>> branch-name

对于发生冲突的情况，有以下两种解决办法：

• 手动解决冲突
  • 编辑冲突文件：打开包含冲突标记的文件，根据实际需求选择保留哪个分支的修改，或者将两个分支的修改进行合并。例如，对于上述冲突标记的内容，你可以根据需要选择保留其中一段，或者将两段内容进行整合。
  • 移除冲突标记：在解决冲突后，删除文件中的 <<<<<<<、======= 和 >>>>>>> 等冲突标记。
  • 添加并提交修改：使用 git add 命令将解决冲突后的文件添加到暂存区，然后使用 git commit 命令提交修改。
• 放弃合并：如果冲突过于复杂，无法解决，或者你不想继续合并操作，可以使用 git merge --abort 命令放弃当前的合并操作，回到合并前的状态。

2.4 查看历史与差异

2.5 远程仓库操作

git remote add <name> <url> 是 Git 里的一个常用命令，其用途是在本地仓库和远程仓库之间建立关联。

• <name>：这是你为远程仓库所设定的别名。一般情况下，默认使用 origin 作为主远程仓库的别名，建议仓库名和项目名一致。

• <url>：这指的是远程仓库的地址，该地址可以是 HTTPS 地址（例如 https://github.com/user/repo.git），也可以是 SSH 地址（例如 git@github.com:user/repo.git）。

  86182@tao MINGW64 /e/Git-Space/demo-project (master)
  $ git remote add git-demo https://github.com/2781196094/git-demo.git
  
  86182@tao MINGW64 /e/Git-Space/demo-project (master)
  $ git remote -v
  git-demo        https://github.com/2781196094/git-demo.git (fetch)
  git-demo        https://github.com/2781196094/git-demo.git (push)
  

git push 是 Git 中一个极为重要的命令，它的主要功能是将本地仓库中的提交推送到远程仓库。其基本语法为git push <远程仓库名> <本地分支名>:<远程分支名>。***在执行 git push 之前，建议先使用 git pull 命令将远程仓库的最新更改拉取到本地，以避免冲突。***若没有足够的权限向远程仓库推送更改，会收到权限错误提示。此时，你需要确认自己的权限或者联系仓库管理员。

git push origin main

git push origin local-branch:remote-branch

// 删除远程分支
git push origin --delete remote-branch

2.6 SSH免密登录

SSH 免密登录是一种允许用户在不输入密码的情况下通过 SSH（Secure Shell）协议登录到远程服务器或主机的技术。以下是其原理、配置方法和优缺点的介绍：

• 原理：SSH 免密登录基于公钥加密技术。用户在本地生成一对密钥，包括公钥和私钥。将公钥复制到远程服务器上，当用户尝试登录远程服务器时，服务器会使用用户的公钥对一个随机数据进行加密，然后发送给用户。用户的本地 SSH 客户端使用私钥对这个加密数据进行解密，并将解密结果返回给服务器。服务器通过验证解密结果来确认用户的身份，如果验证成功，则允许用户登录，无需输入密码。
• 配置方法
  • 生成密钥对：在本地主机上使用 ssh -keygen 命令生成公钥和私钥，通常会在用户目录下的 .ssh 文件夹中生成 id_rsa（私钥）和 id_rsa.pub（公钥）文件。
  • 上传公钥：将公钥内容添加到远程服务器的 authorized_keys 文件中。可以使用 ssh-copy-id 命令将本地公钥复制到远程服务器，也可以手动将公钥内容追加到远程服务器的 ~/.ssh/authorized_keys 文件中。
• 优点
  • 提高效率：无需每次登录时输入密码，节省了时间，尤其在需要频繁登录远程服务器进行操作时，能显著提高工作效率。
  • 便于自动化：适合用于自动化脚本和批量操作，例如在进行服务器集群管理、自动化部署等任务时，无需为每个登录操作提供密码，方便脚本的编写和执行。
• 缺点
  • 安全性风险：如果私钥泄露，他人就可以利用该私钥登录到配置了相应公钥的远程服务器，因此需要妥善保管私钥，设置严格的访问权限。
  • 管理复杂度：在多用户或多服务器环境中，管理公钥和私钥对可能会增加一定的复杂度，需要确保公钥与正确的用户和服务器进行关联，并且及时更新和撤销不再使用的公钥。

如果 Git 要实现ssh免密登录，可以按照如下步骤进行：

• 在用户家目录打开git终端，生成SSH密钥对。执行下面命令后，会在用户家目录中生成.ssh文件，里面存放公钥和私钥。

  $ ssh-keygen -t ed25519 -C "aaa@qq.com"
  Generating public/private ed25519 key pair.
  Enter file in which to save the key (/c/Users/86182/.ssh/id_ed25519):
  Enter passphrase for "/c/Users/86182/.ssh/id_ed25519" (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in /c/Users/86182/.ssh/id_ed25519
  Your public key has been saved in /c/Users/86182/.ssh/id_ed25519.pub
  The key fingerprint is:
  SHA256:7l4Cymw+R25MH3ZeY3PDcB8PL82J+q/daIVDvVErCT4 2781196094@qq.com
  The key's randomart image is:
  +--[ED25519 256]--+
  |                 |
  |           .    .|
  |          . . ..o|
  |           E.o++.|
  |      . S   .=oB*|
  |   o .ooo . =.BoB|
  |    == oo+.o.+ = |
  |   o. =..o..  o..|
  |    .+ .o   .++o.|
  +----[SHA256]-----+
  

  86182@tao MINGW64 ~/.ssh
  $ ll
  total 3
  -rw-r--r-- 1 86182 197609 411 Mar 20 17:29 id_ed25519 // 私钥
  -rw-r--r-- 1 86182 197609  99 Mar 20 17:29 id_ed25519.pub // 公钥
  -rw-r--r-- 1 86182 197609  92 Mar 20 09:37 known_hosts
  

• 添加公钥到代码托管平台，如github。

• 连接成功后即可正常拉取、提交代码。

  $ git pull git@github.com:aaa/git-demo.git
  remote: Enumerating objects: 5, done.
  remote: Counting objects: 100% (5/5), done.
  remote: Compressing objects: 100% (2/2), done.
  remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
  Unpacking objects: 100% (3/3), 927 bytes | 231.00 KiB/s, done.
  From github.com:2781196094/git-demo
   * branch            HEAD       -> FETCH_HEAD
  Updating c95cab6..81fa07b
  Fast-forward
   new.txt | 1 +
   1 file changed, 1 insertion(+)
  

SSH免密登录与Https拉取的核心区别如下：

3. IDE集成Git

3.1 git忽略文件

为什么需要配置git忽略文件？在使用 IntelliJ IDEA 集成 Git 时配置忽略文件【.gitignore】的目的是避免将不必要的、自动生成的文件提交到版本控制中，如java的out/、node.js的node_modules/。其主要作用如下：

• 保护用户、环境特定的配置：IDEA 生成的 .idea 目录、.iml 文件等包含开发者本地 IDE 的个性化配置，如代码风格、运行配置等，又或是一些系统生成的文件，这些文件通常与项目本身无关。
• 避免提交冗余文件
  • 编译输出文件：如 Java 的 target/（Maven）、out/（IDEA 默认编译目录）、build/（Gradle）等。这些文件可以通过重新编译生成，无需版本控制。
  • 依赖文件：如 node_modules/（Node.js）、.venv/（Python 虚拟环境）等。这些文件体积庞大且可通过包管理器恢复，提交它们会浪费存储空间。
• 提高协作效率和仓库清洁度
  • 减少仓库体积：自动生成的文件（如日志、缓存）会占用不必要的存储空间，拖慢克隆和拉取操作。
  • 防止历史记录污染：避免将临时文件（如 *.log、*.tmp）提交到仓库，保持提交历史的清晰。
  • 统一团队规范：通过 .gitignore 确保所有开发者忽略相同的文件，避免误提交。

在IDE中，要创建忽略文件，可以在项目根目录右键创建文件.gitignore，然后找到选项Add to .gitignore应用忽略规则即可，如果修改了.gitignore文件本身则需要重新提交修改。git忽略文件的模板如下：

# IDE 文件
.idea/
*.iml
*.ipr
*.iws

# 编译输出
target/
build/
out/

# 系统文件
.DS_Store
Thumbs.db

# 依赖目录
node_modules/
.vendor/
.venv/

# 日志和缓存
*.log
*.tmp

3.2 Pycharm集成Git

首先打开设置File -> Settings，导航到 Version Control → Git，在Path to Git executable*中输入 Git 可执行文件路径，点击Test，如果输出版本号则配置成功，如下：

配置上git后，就可以初始化Git仓库了：

• 新项目：在导航栏的VCS中找到Create Git Repository，选择项目目录作为仓库根目录。
• 已有项目：如果存在.git目录，则会自动识别；如果不存在同新项目。

在 PyCharm或其他 JetBrains IDE如 IntelliJ IDEA中初始化 Git 仓库后，文件会通过不同颜色标识其版本控制状态。以下是常见颜色及其含义的详细说明：

3.3 文件颜色与状态对照

在 PyCharm或其他 JetBrains IDE如 IntelliJ IDEA中初始化 Git 仓库后，文件会通过不同颜色标识其版本控制状态。以下是常见颜色及其含义的详细说明：

• 红色文件Untracked：如新创建的脚本文件、临时日志文件

  • 若需跟踪：右键文件 → Git → Add【或直接提交时勾选】。

  • 若需忽略：右键文件 → Git → Add to .gitignore【需插件支持，或手动编辑 .gitignore】。

• 蓝色文件Modified：如已修改的源代码文件、更新的配置文件

  • 提交更改：右键文件 → Git → Commit File → 填写提交信息。

  • 撤销修改：右键文件 → Git → Rollback（谨慎操作，会丢失本地更改）。

• 绿色文件Staged：通过 git add 添加的待提交文件

  • 提交到仓库：使用 Commit 按钮提交暂存区内容。

  • 取消暂存：右键文件 → Git → Unstage（或通过提交界面取消勾选）。

• 灰色文件Ignored：如虚拟环境目录（venv/）、编译输出文件（__pycache__/）

  • 检查 .gitignore 规则是否合理，必要时调整忽略规则。

  • 若需恢复跟踪：删除 .gitignore 中的相关规则 → 右键文件 → Git → Add。

• 黄色文件Conflict：如多人协作时同时修改同一文件的同一区域

  • 打开冲突文件 → 使用 IDE 的三窗格合并工具解决冲突 → 标记为已解决（Mark as Resolved）→ 提交合并结果。

  • 若需中止合并：Git → Reset HEAD 回退到合并前状态。

3.4 切换版本

如果需要查看提交信息，则可以点击Git，如下：

如果需要切换版本则可以右键要切换的版本，点击Checkout Revision即可，如下：

3.5 分支相关操作

在根目录右键找到new Branch即可创建新的分支，如下：

当然切换分支也很简单，如下：

对于分支的合并，分为正常合并和合并冲突，下面为正常合并，选择需要合并的分支即可：

上面情况是理想情况，在实际开发中，经常遇到合并冲突的问题，这种情况则需要手动修改，总共有三种修改方案，如下：

4. Git hub远程仓库

4.1 添加git hub账号

• 通过账号添加

  

• 通过Token添加：首先在自己的git hub账号上生成token，在IDE上配置该token即可。

  

4.2 分享项目到git hub

4.3 推送、拉取、克隆

推送和拉取可以直接通过鼠标右键选择，如下：

如果需要克隆远程仓库的代码，需要配置远程仓库的地址，如下：

5. Gitee码云

Gitee是开源中国OSChina推出的代码托管与协作平台，专注于为开发者提供稳定高效的Git服务，尤其适合中国用户，具备本土化优势和高速访问体验。支持个人、企业及开源项目的代码管理、协作开发和DevOps流程。其使用方式与Git hub类似。

如果IDE需要集成Gitee，需要下载Gitee插件。