git项目管理工具教程

Git分布式版本控制工具

目录

〇、Git的安装

一、概述

1.1 版本控制方式

1.2 SVN

1.3 Git

1.4 *Git工作流程图

二、Git环境配置与常用指令

2.1 基本配置

2.2 为常用指令配置别名(可选)

2.3 基础操作指令

2.3.1 *查看修改的状态(status)

2.3.2 *添加工作区到暂存区（add）

2.3.3 *提交暂存区到本地仓库（commit）

2.3.4 *查看提交日志（log）

2.3.5 版本回退

2.3.6 添加文件至忽略列表

基础练习

2.4 分支

2.4.1 查看本地分支

2.4.2 创建本地分支

2.4.4 *切换分支（checkout）

2.4.5 *合并分支（merege）

2.4.6 删除分支

2.4.7 解决冲突

2.3.8 开发中分支使用原则与流程

2.3.9 快进模式

练习

三、Git远程仓库

3.1常用的托管服务[远程仓库]

3.2 注册码云

3.3 创建远程仓库

3.4 配置SSH公钥

3.5 操作远程仓库

3.5.1 添加远程仓库

3.5.2 查看远程仓库

3.5.3 推送到远程仓库

3.5.4 本地分支与远程分支的关联关系

3.5.5 从远程仓库克隆

3.5.6 从远程仓库中抓取和拉取

3.5.7 远程解决冲突

练习：远端仓库操作

四、在Visual Studio中使用Git

---

以下是 Git 项目管理中从建立本地库、远程库，到日常版本控制、分支管理等常见操作的基本流程。

建立本地 Git 仓库

1. 创建项目目录：在本地磁盘合适位置，通过命令行或图形界面创建用于存放项目代码的文件夹，比如my_project。以命令行（Linux/macOS 系统）为例：

mkdir my_project
cd my_project

1. 初始化 Git 仓库：进入项目目录后，使用git init命令将当前目录初始化为 Git 仓库，这会在该目录下生成一个隐藏的.git文件夹，用于存储 Git 仓库的配置、版本记录等信息。

git init

连接远程 Git 仓库

常用的远程仓库托管平台有 GitHub、GitLab、Gitee 等，以下以在 Gitee 上创建远程仓库，并连接本地仓库为例：

1. 在远程平台创建仓库：

   • 登录 Gitee 账号，点击右上角的 “+” 号，选择 “新建仓库”。

   • 填写仓库名称（如my_project）、仓库描述等信息，按需设置仓库的公开 / 私有属性，然后点击 “创建”。

2. 获取远程仓库地址：仓库创建成功后，在仓库页面可以看到仓库的克隆地址，一般有 HTTPS 和 SSH 两种形式。

3. 本地仓库关联远程仓库：在本地项目目录（已经初始化 Git 仓库）下，使用git remote add命令将本地仓库与远程仓库关联起来，命令格式为git remote add <远程仓库别名> <远程仓库地址> ，通常将远程仓库别名设置为origin。比如使用 HTTPS 地址关联：

git remote add origin https://gitee.com/your_username/my_project.git

如果使用 SSH 地址，需要先在本地配置好 SSH 密钥并添加到 Gitee 账号中，再执行关联操作。

基本的版本控制操作

1. 添加文件到暂存区：将项目中的文件添加到 Git 暂存区，使用git add命令。可以指定单个文件，也可以使用. 一次性添加当前目录下所有文件。例如，添加main.py文件：

git add main.py

添加所有文件：

git add.

1. 提交到本地仓库：将暂存区的文件提交到本地仓库，并附上有意义的提交信息，使用git commit命令，格式为git commit -m "提交信息" 。

git commit -m "初始化项目，添加main.py文件"

1. 推送到远程仓库：将本地仓库中的提交推送到远程仓库，使用git push命令。如果是首次推送，对于 HTTPS 方式，可能需要输入 Gitee 账号的用户名和密码；对于 SSH 方式，需要确保 SSH 密钥配置正确。命令格式为git push <远程仓库别名> <本地分支>，通常默认推送master或main分支：

git push origin main

分支管理操作

1. 创建分支：使用git branch命令创建新分支，例如创建名为feature-1的分支：

git branch feature-1

1. 切换分支：使用git checkout命令切换到其他分支，例如切换到feature-1分支：

git checkout feature-1

也可以使用更简洁的方式创建并切换分支：

git checkout -b feature-1

1. 合并分支：在某个分支（如main分支）上，使用git merge命令合并其他分支（如feature-1分支）的内容，例如：

git checkout main
git merge feature-1

1. 删除分支：使用git branch -d命令删除不再需要的分支，例如删除feature-1分支：

git branch -d feature-1

拉取远程仓库更新

当远程仓库有其他成员提交了新代码时，本地仓库需要拉取这些更新，使用git pull命令，格式为git pull <远程仓库别名> <远程分支>，例如从远程仓库origin的main分支拉取更新：

git pull origin main

〇、Git的安装

1、下载地址

Redirecting…

2、安装教程

Git安装详解（写吐了，看完不后悔）-CSDN博客

一、概述

1.1 版本控制方式

a、集中式版本控制工具 集中式版本控制工具，版本库是集中存放在中央服务器的，team 里每个人 work 时从中央服务器下载代码，是必须联网才能工作，局域网或互联网。个人修改然后提交到中央版本库。 举例：SVN 和 CVS b、分布式版本控制工具 分布式版本控制系统没有 “中央服务器”，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了。 举例：Git

1.2 SVN

SVN（Subversion ）是一个开源的集中式版本控制系统，由 CollabNet 公司在 2000 年开发，旨在替代 CVS（Concurrent Versions System） ，解决了 CVS 在某些方面的不足，提供了更强大、更稳定的版本控制功能。

基本架构

采用客户端 - 服务器（C/S）模型，分为三部分：

• 仓库（Repository）：是 SVN 的核心存储单元，就像一个巨大的数据库，存储着项目的所有文件和版本历史，包括文件的创建、修改、删除等操作记录。存储结构上，使用全局递增的整数版本号标记每次提交；基于 BDB（Berkeley DB）或 FSFS（文件系统存储）存储版本差异。访问方式分为本地访问（直接操作文件系统，通过file://<> 协议 ）和远程访问（通过 HTTP/HTTPS（借助 Apache 模块）或 SVN 协议svn://<> 访问）。

• 客户端（Client）：常见的有图形化工具，如 TortoiseSVN、SmartSVN 等，用于与仓库交互，执行提交、更新、合并等操作，同时也负责本地工作副本（Working Copy）的管理。

• 服务器（Server）：有 svnserve 轻量级 SVN 协议服务（默认端口 3690 ），还有 Apache + mod_dav_svn，通过 HTTP/HTTPS 提供 WebDAV 服务，后者支持更复杂的权限控制，它们主要负责处理客户端的请求，如提交、更新等。

主要功能

• 管理文件历史版本

• 支持团队协作

• 基于版本的操作记录

• 自由的版本化元数据操作

• 混合追踪

• 支持多种模式

使用情况

在 2006 年时，Subversion 的使用族群远少于传统的 CVS ，但之后许多开放源码团体决定将 CVS 转换为 Subversion，如 FreeBSD、Apache Software Foundation、KDE、GNOME、GCC、Python、Samba、Mono 等。Trac、SourceForge、CollabNet、CodeBeamer 等专案协同作业软件，以及 Eclipse、NetBeans 等 IDE 提供 Subversion 的资源整合，推动了开发团队换用 Subversion。此外，SourceForge.net除提供 CVS 外，也提供 Subversion ；JavaForge、Google Code 以及 BountySource 则以 Subversion 作为官方的源码管理系统。到 2009 年，绝大多数 CVS 服务已经改用 SVN，CVS 停止维护。

客户端和服务器

• 客户端：一类是如 WebSVN 等基于 Web 的客户端，需要 Web 服务器的支持；另一种是以 TortoiseSVN 为代表的客户端软件，需要用户在本地安装。

• 服务器：支持 Linux 和 Windows 系统，更多安装在 Linux 下，有独立服务器和借助 Apache 两种运行方式；存储版本数据有 Berkeley DB 和 FSFS 两种方式，FSFS 方式更安全，因为 Berkeley DB 方式在服务器中断时，有可能锁住数据。

1.3 Git

Git 是分布式的，Git 不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用 Git 并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的 PC 是一样的。我们可以把它当做一个开发者的 pc 就可以视为了大家的代码容易交流不用关机的，可以有效、高速地处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 git 是一个开源的分布式版本控制系统，没有它大家一样可以工作，只不过 “交换” 修改不方便而已。 同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002 年间）。到 2002 年，整个项目开始启用一个专有分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。这就迫使 Linux 内核开源社区（特别是 Linux Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。他们对新的系统制订了若干目标： 速度 简单的设计 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 完全分布式 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

Git 是一个开源的分布式版本控制系统，由 Linux 内核创始人 Linus Torvalds 于 2005 年开发，最初旨在解决 Linux 内核开发中的版本管理问题，如今已成为全球最流行的版本控制工具之一。以下是其核心特点和关键信息：

核心特性

• 分布式架构：与 SVN 等集中式工具不同，Git 没有严格依赖的 “中央服务器”，每个用户的本地设备都包含完整的版本库（包括所有文件历史和分支信息）。这意味着开发者可离线工作，仅在需要同步时与远程仓库交互。

• 高效性能：采用独特的 “快照” 式存储（而非差异对比），对大型项目的操作（如提交、分支、合并）速度极快，且占用存储空间小。

• 强大的分支管理：分支操作轻量高效（仅创建指针），支持非线性开发，可轻松创建、切换、合并分支，非常适合多人并行开发和功能迭代。

• 完整性保障：通过 SHA-1 哈希算法对数据进行校验，确保文件内容和历史记录不被篡改，保证版本库的完整性。

• 非线性开发支持：天然支持成千上万的并行分支，能高效处理复杂的开发流程（如 feature 分支、release 分支、hotfix 分支等）。

核心概念

• 工作区（Working Directory）：本地可见的项目文件目录，即当前正在编辑的文件。

• 暂存区（Stage/Index）：用于临时存放待提交的修改，是工作区与版本库之间的缓冲。

• 版本库（Repository）：存储所有版本信息的核心区域，包含提交历史、分支等数据，分为本地仓库（.git 目录）和远程仓库（如 GitHub、GitLab 等）。

• 提交（Commit）：将暂存区的修改永久保存到本地仓库，每个提交生成唯一的哈希值，作为版本标识。

• 分支（Branch）：本质是指向提交的指针，默认主分支为 main（或 master），可通过分支独立开发功能，避免影响主代码。

• 远程仓库（Remote）：用于多人协作的共享仓库，开发者通过 push（推送）和 pull（拉取）同步本地与远程的修改。

常用操作

• 初始化仓库：git init

• 克隆远程仓库：git clone <url>

• 跟踪文件并提交：git add <file> → git commit -m "提交说明"

• 分支操作：git branch <name>（创建）、git checkout <name>（切换）、git merge <name>（合并）

• 同步远程：git pull（拉取远程更新）、git push（推送本地修改）

• 查看历史：git log

优缺点

• 优点：

  • 分布式架构，不依赖中央服务器，离线可用，安全性高（本地有完整备份）。

  • 分支管理高效，支持复杂开发流程。

  • 速度快，对大型项目友好。

  • 开源免费，社区活跃，生态丰富（与 GitHub、GitLab 等平台深度集成）。

• 缺点：

  • 学习曲线较陡，部分概念（如暂存区、分支原理）对新手较复杂。

  • 命令较多，初期需记忆常用操作。

应用场景

广泛用于软件开发中的代码版本管理，支持从小型个人项目到大型企业级项目（如 Linux 内核、Android 系统）。配合 GitHub、GitLab、Gitee 等平台，可实现代码托管、协作开发、代码审查等功能，是现代软件开发流程中不可或缺的工具。

1.4 *Git工作流程图

1.clone（克隆）: 从远程仓库中克隆代码到本地仓库 2.checkout（检出）: 从本地仓库中检出一个仓库分支然后进行修订 3.add（添加）: 在提交前先将代码提交到暂存区 4.commit（提交）: 提交到本地仓库。本地仓库中保存修改的各个历史版本 5.fetch (抓取)：从远程库，抓取到本地仓库，不进行任何的合并动作，一般操作比较少。 6.pull (拉取) ：从远程库拉到本地库，自动进行合并 (merge)，然后放到到工作区，相当于 fetch+merge 7.push（推送）: 修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库

二、Git环境配置与常用指令

GIt GUI：Git提供的图形界面工具

Git Bash：Git提供的命令行工具

当安装Git后首先要做的事情就是设置用户名称和Email地址，这非常重要，因为每次Git提交都会使用该用户信息。

2.1 基本配置

1. 打开Git Bash(桌面右击鼠标)

1. 设置用户信息

git config -global user.name."用户名"

git config -global user.email "邮箱地址"

查看配置信息

git config -global user.name

git config -global user.email

2.2 为常用指令配置别名(可选)

有些常用的指令参数非常多，每次都要输入好多参数，因此我们可以使用别名

1. 打开用户目录，创建 .bashrc 文件

touch ~/.bashrc

1. 添加别名配置

在文件末尾添加别名定义，语法为：alias 新别名='原始命令' 。 比如，将ll定义为ls -al的别名，以及将git-log定义为输出简洁 git 提交日志的命令：

#用于输出 git 提交日志
alias git-log='git log --pretty=oneline --all --graph --abbrev-commit'
# 用于输出当前目录所有文件及基本信息
alias ll='ls -al'

如果原始命令包含多个参数，需要使用单引号将整个命令括起来，以确保参数正确解析。

1. 使配置生效

source ~/.bashrc

2.3 解决GitBash乱码问题

1. 打开GitBash执行下面命令

git config --global core.quotepath false

1. ${git_home}/etc/bash.bashrc文件最后加入下面两行

export LANG="zh_CN.UTF-8"
export LC_ALL="zh_CN.UTF-8"

{git_home}指的是Git的安装地址

2.3 获得本地仓库

需要使用GIt对我们的代码进行版本控制，首先需要获得本地仓库

1. 在电脑的任意位置创建一个空目录作为我们本地Git仓库

2. 进入这个目录中，点击右键打开GitBash窗口

3. 执行命令 git init

4. 如果创建成功后可在文件夹下看到隐藏的git目录

2.3 基础操作指令

Git工作目录下对文件的修改（增加、删除、更新）会存在几个状态，这些修改的状态会随着我们执行Git的命令而发生变化。

1. 工作区（workspace）

• 未暂存（unstaged）：修改已跟踪文件（如改内容），但没执行 git add，变更在工作区，未进暂存区。

• 未跟踪（untracked）：新增文件，Git 还没开始跟踪，需 git add 纳入管理。

2. 暂存区（index）

执行 git add 后，工作区变更（不管是改旧文件、加新文件）会到已暂存（staged），是提交仓库前的 “临时缓存”，可理解为 “待提交准备区”。

3. 仓库（repository）

执行 git commit，暂存区的 “已暂存” 内容会生成提交记录（commit），永久存入仓库，成为版本历史的一部分，每个 commit 是独立版本快照 。

那么如何使用命令来控制这些状态之间的转换：

1. git add （工作区 -> 暂存区）

2. git commit （暂存区 -> 本地仓库）

除了.git文件，其他都是工作区

2.3.1 *查看修改的状态(status)

• 作用：查看修改的状态（暂存区、工作区）

• 命令形式git status

2.3.2 *添加工作区到暂存区（add）

• 作用：添加工作区一个或多个文件的修改到暂存区

• 命令形式：git add单个文件名|通配符

  • 将所有修改加入暂存区git add

2.3.3 *提交暂存区到本地仓库（commit）

• 作用：提交暂存区内容到本地仓库的当前分支

• 命令形式：git commit -m '注释内容'

2.3.4 *查看提交日志（log）

• 作用：查看提交记录

• 命令形式：git log [option]

  • options:

    • --all 显示所有分支

    • --pretty=oneline将提交信息显示为一行

    • --abbrev-commit使得输出的commitld更简短

    • --graph 以图形的形式显示

2.3.5 版本回退

• 作用：版本切换

• 命令形式：git reset --hard commitID

  • commitID(唯一标识)可以使用git-log或git log指令查看

  • Git Bash中框选住文字即为复制，鼠标中键为粘贴

• 如何查看已经删除的记录

  • git reflog

  • 这个指令可以看到已经删除的提交记录

2.3.6 添加文件至忽略列表

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件模式。下面是一个示例：

# no .a files	忽略所有 .a 后缀的文件
*.a
# but do track lib.a, even though you're ignoring .a files above	但例外情况：跟踪 lib.a 文件，即使上面设置了忽略所有 .a 文件
!lib.a
# only ignore the TODO file in the current directory, not subdir/TODO	只忽略当前目录下的 TODO 文件，不忽略子目录中的 TODO 文件
/TODO
# ignore all files in the build/ directory	忽略 build/ 目录下的所有文件
build/
# ignore doc/notes.txt, but not doc/server/arch.txt	忽略 doc/notes.txt 文件，但不忽略 doc/server/arch.txt 文件
doc/*.txt
# ignore all .pdf files in the doc/ directory 忽略 doc/ 目录下（包括所有子目录）的所有 .pdf 文件
doc/**/*.pdf

基础练习

##########################仓库初始化##########################
# 1. 创建目录（git_test01）并在目录下打开 Git Bash  
略（实际操作：可通过资源管理器新建文件夹，或用 `mkdir git_test01 && cd git_test01` 命令在 Git Bash 直接创建并进入 ）  

# 2. 初始化 Git 仓库  
git init  


##########################创建文件并提交##########################
# 1. 目录下创建文件 file01.txt  
略（实际操作：可手动新建文件，或用 `touch file01.txt` 命令在 Git Bash 创建 ）  

# 2. 将修改加入暂存区（`.` 表示当前目录所有变更）  
git add .  

# 3. 将修改提交到本地仓库，提交记录备注为 “commit 001”  
git commit -m 'commit 001'  

# 4. 查看提交日志（查看历史版本记录）  
git log  


##########################修改文件并提交##########################
# 1. 修改 file01.txt 的内容为：count=1  
略（实际操作：用文本编辑器打开 file01.txt 修改内容并保存 ）  

# 2. 将修改加入暂存区  
git add .  

# 3. 将修改提交到本地仓库，提交记录备注为 “update file01”  
git commit -m 'update file01'  

# 4. 查看提交日志  
git log  

# 5. 以精简的方式显示提交记录（更简洁的日志格式）  
git log --oneline  


##########################将最后一次修改还原##########################
# 1. 查看提交记录（确认要回退到的版本）  
git log  

# 2. 找到倒数第 2 次提交的 commitID  
略（实际操作：从 `git log` 输出里，复制目标版本的 commitID ，通常是一串哈希值 ）  

# 3. 版本回退（根据 commitID 回退到指定版本）  
git reset --hard [commitID]  
# 说明：替换 [commitID] 为实际复制的哈希值，执行后代码会回退到对应版本状态  

如果执行 git reset 时，想更灵活操作（比如回退暂存区、保留工作区修改），可根据需求调整 reset 的参数（如 --soft --mixed ），具体可结合实际场景选择

2.4 分支

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。

在 Git 中，分支（Branch） 是用于隔离代码开发、并行管理不同功能或版本的核心机制。它允许开发者在不干扰主代码的前提下，独立开发新功能、修复 bug 或进行实验性修改，是团队协作和复杂项目管理的必备工具。

分支的核心作用

1. 隔离开发环境 不同功能或任务在各自分支中开发，避免代码混乱。例如：主分支保持稳定，新功能在独立分支开发，完成后再合并回主分支。

2. 支持并行开发 多人可同时在不同分支工作，互不干扰（如 A 开发支付功能，B 修复登录 bug）。

3. 版本控制灵活性 可基于历史版本创建分支，用于维护旧版本（如v1.0分支修复旧版本 bug），或尝试激进的功能开发（失败可直接删除分支，不影响主代码）。

2.4.1 查看本地分支

• 命令：git branch

2.4.2 创建本地分支

• 命令：git branch 分支名

2.4.4 *切换分支（checkout）

• 命令：git checkout 分支名

我们可以直接切换到一个不存在的分支（创建并切换）

• 命令：git checkout -b 分支名

2.4.5 *合并分支（merege）

一个分支上的提交可以合并到另一个分支

• 命令：git merge 分支名称

2.4.6 删除分支

不能删除当前分支，只能删除其他分支

git brach -d b1删除分支时，需要做各种检查

git branch -D b1不做任何检查，强制删除

1. 分支未被合并到主分支且确认不再需要 当分支 b1 有未合并的修改，使用普通的 git branch -d b1 会失败（Git 会提示分支未合并以防止数据丢失）。此时如果确认该分支的内容确实无用，可以用 -D 强制删除。

2. 清理废弃分支 对于已经过时、不再维护的分支（例如实验性分支、已被放弃的功能开发分支），即使未合并，也可以用 -D 强制删除以保持仓库整洁。

3. 紧急修正错误分支 若分支 b1 存在严重错误，且不需要保留其历史，可强制删除后重新创建正确的分支。

⚠️ 注意： -D 是强制删除，操作不可逆！删除前务必确认分支内容已备份或确实无用，避免误删重要代码。如果需要删除远程分支，应使用 git push origin --delete b1。

2.4.7 解决冲突

当两个分支上对文件的修改可能会存在冲突，例如同时修改同一个文件的同一行，这就需要解决冲突，解决冲突步骤如下：

• 处理文件中冲突的地方

• 将解决冲突的文件加入暂存区（add）

• 提交到仓库（commit）

冲突部分的内容做如下处理：

1. 处理文件冲突的地方

2. 将解决完冲突的文件加入暂存区（add）

3. 提交到仓库（commit）

冲突部分的内容处理如下所示：

2.3.8 开发中分支使用原则与流程

几乎所有的版本控制系统都已某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。

常见分支类型与命名规范

实际开发中，分支通常按功能划分，以下是主流的分支模型（如 Git Flow 规范）：

分支类型	作用	命名示例
主分支	存放正式发布的稳定代码，不可直接修改	main（或master）
开发分支	集成各功能分支的开发代码，作为开发主线	develop
功能分支	开发新功能，从develop分支创建	feature/payment-module
bug 修复分支	修复开发中的 bug，从develop分支创建	bugfix/login-error
发布分支	准备版本发布，从develop分支创建	release/v1.2.0
热修复分支	修复生产环境紧急 bug，从main分支创建	hotfix/critical-crash

在开发中，一般有如下分支使用原则与流程：

• master（生产）分支 线上分支，主分支，中小规模项目作为线上运行的应用对应的分支；

• develop（开发）分支 是从 master 创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要合并到 master 分支，准备上线。

• feature/xxxxx 分支 从 develop 创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到 develop 分支。

• hotfix/xxxxx 分支， 从 master 派生的分支，一般作为线上 bug 修复使用，修复完成后需要合并到 master、test、develop 分支。

• 还有一些其他分支，在此不再详述，例如 test 分支（用于代码测试）、pre 分支（预上线分支）等等。

一、分支类型与提交节点（颜色含义）

• 灰色（master 分支）：生产环境分支，代表线上已发布的稳定版本。

• 黄色（develop 分支）：开发主分支，集成所有功能开发完成的代码，是团队日常开发的 “集成分支”。

• 绿色（feature 分支）：功能分支，从 develop 拆分，专门开发单个功能（如 feature/xxx1）。

• 红色（hotfix 分支）：紧急修复分支，从 master 拆分，专门修复线上 bug（如 hotfix/bug_xxx）。

• 蓝色（release 分支）：预发布分支，从 develop 拆分，用于准备发版前的最后测试、修复（如 release/xxx1）。

二、核心流程拆解

1. 功能开发（feature 分支）

• 创建：从 develop 分支新建 feature/xxx 分支（如 feature/xxx1、feature/xxx2 ），专注开发单个功能。

• 合并：功能开发、测试完成后，合并回 develop 分支 → 合并后可删除 feature 分支（完成使命）。

• 图示逻辑：

  • 绿色节点（feature/xxx1）开发完 → merge（合并）到黄色节点（develop）→ 多个 feature 分支依次合并到 develop，保证开发分支干净。

2. 预发布（release 分支）

• 创建：当 develop 集成了足够多的功能，从 develop 拆分 release/xxx 分支（如 release/xxx1、release/xxx2 ）。

• 作用：最后一轮测试、修复（如改小 bug、配置），不新增大功能，只为发版做准备。

• 合并：测试通过后，合并到 master（生产分支）和 develop（保持开发分支同步）→ 合并后可删除 release 分支，或用 tag 标记版本。

• 图示逻辑：

  • release/xxx1 从 develop 拆分 → 修复 / 验证后 → merge 到 master 和 develop → 灰色节点（master）和黄色节点（develop）同步更新。

3. 线上 Bug 修复（hotfix 分支）

• 创建：线上（master 分支）发现紧急 bug，从 master 拆分 hotfix/bug_xxx 分支。

• 作用：快速修复 bug，不影响其他开发流程。

• 合并：修复完成后，合并回 master（更新线上版本）和 develop（保证开发分支包含该修复）→ 合并后可删除 hotfix 分支。

• 图示逻辑：

  • 红色节点（hotfix/bug_xxx）从 master 拆分 → 修复后 → merge 到 master 和 develop → 灰色、黄色节点同步更新。

4. 生产分支（master 分支）

• 角色：唯一代表线上运行的代码分支，所有合并到 master 的代码，理论上都可直接部署到生产环境。

• 更新方式：只能通过 release 分支合并（正常发版）或 hotfix 分支合并（紧急修复）更新。

5. 初始化与迭代（init project）

• 起点：init project 是仓库初始化的第一个提交，作为所有分支的 “根节点”。

• 迭代：从 init project 开始，develop 分支不断合并 feature、release、hotfix 的更新，持续迭代。

三、核心协作逻辑

1. 分支隔离： 不同分支各司其职（功能开发、预发布、紧急修复、生产），避免代码混乱。

   • 开发新功能 → 用 feature 分支；

   • 准备发版 → 用 release 分支；

   • 修线上 bug → 用 hotfix 分支。

2. 合并后清理： feature、hotfix、release 分支完成使命（合并到 develop/master）后，可删除，让仓库分支列表更简洁。

3. 版本可追溯： 每个分支的合并记录、提交节点，清晰标记了 “功能何时开发完成”“bug 何时修复”“版本何时发布”，方便追溯问题。

2.3.9 快进模式

在 Git 中，"快进模式"（Fast-forward）是合并分支时的一种特殊情况，也是 Git 默认的合并行为之一。

什么是快进模式？

当你合并两个分支时，如果被合并的分支（通常是 feature 分支）是基于当前分支（通常是 main 或 master 分支）直接创建的，并且当前分支在创建后没有任何新的提交，Git 会执行 "快进合并"。

这种情况下，Git 不会创建新的合并提交，而是直接将当前分支的指针向前移动（"快进"）到被合并分支的最新提交，使两个分支指向同一个位置。

快进模式的特点：

1. 不会产生新的合并提交，保持提交历史线性

2. 操作简单快速，只是移动分支指针

3. 只适用于被合并分支是当前分支的直接延伸的情况

示例场景：

A---B---C  (main)
         \
          D---E  (feature)

当在 main 分支上合并 feature 分支时，由于 main 分支在 C 之后没有新提交，Git 会执行快进合并，结果如下：

A---B---C---D---E  (main, feature)

如何禁用快进模式？

如果你希望始终创建合并提交（即使可以快进），可以使用 --no-ff 参数：

git merge --no-ff feature

这会强制创建一个新的合并提交，保留分支的历史结构，适合需要清晰展示分支合并记录的场景。

选择快进还是非快进合并，取决于你对项目提交历史的管理策略。快进合并保持历史简洁，而非快进合并则更完整地保留了开发过程。

练习

##########################创建并操作dev01分支##########################
# 1. 从master分支创建dev01分支
git branch dev01

# 2. 切换到dev01分支
git checkout dev01

# 3. 在dev01分支创建file02.txt
略（实际操作：可手动新建文件，或用 `touch file02.txt` 命令在Git Bash创建）

# 4. 将修改加入暂存区
git add .

# 5. 将修改提交到本地仓库，提交记录备注为 "add file02 on dev"
git commit -m 'add file02 on dev'

# 6. 以精简的方式显示提交记录
git log --oneline


##########################合并dev01到master分支##########################
# 1. 切换回master分支
git checkout master

# 2. 将dev01分支的修改合并到master分支
git merge dev01

# 3. 以精简的方式显示提交记录（查看合并后的记录）
git log --oneline

# 4. 验证master分支下是否有file02.txt
略
##########################删除dev01分支##########################
#[master]删除dev01分支
git branch -d dev01
#[master]以精简的方式显示提交记录
git-log

三、Git远程仓库

3.1常用的托管服务[远程仓库]

Git 远程仓库的搭建方式，可借助代码托管服务实现，常用的有：

• GitHub：地址为https://github.com/ ，面向开源及私有软件项目的托管平台，因仅支持 Git 作为唯一版本库格式托管得名，是全球开发者常用的代码托管平台 。

• 码云（Gitee）：地址是Gitee - 基于 Git 的代码托管和研发协作平台 ，国内代码托管平台，服务器在国内，相比 GitHub 访问速度更快 。

• GitLab：地址为https://about.gitlab.com/ ，用于仓库管理系统的开源项目，以 Git 为代码管理工具搭建的 web 服务，常为企业、学校等搭建内部 Git 私服

3.2 注册码云

注册 - Gitee.com

3.3 创建远程仓库

右上角+号点击新建仓库

3.4 配置SSH公钥

• 生成SSH公钥

  • ssh-keygen -t rsa

  • 不断回车

    • 如果公钥已经存在，则会自动覆盖

• Gitee设置账户公钥

  • ·cat ~/.ssh/id_rsa.pub·

• 验证是否配置成功

  • ssh -T git@gitee.com

3.5 操作远程仓库

3.5.1 添加远程仓库

此操作是先初始化本地仓库，然后与已经创建的远程仓库进行对接

• 命令：git remote add <远端名称><仓库路径>

  • 远端名称，默认是origin，取决于远端服务器设置

  • 仓库路径，从远端服务器获取此URL

  • 例如：git remote add origin git@gitee.com:sgll/git_test.git

3.5.2 查看远程仓库

• 命令：git remote

3.5.3 推送到远程仓库

• 命令：git push [-f] [--set-upstream] [远端名称[本地分支名][:远端分支名]]

  • 如果远端分支名和本地分支名称相同，则可以致谢本地分支

    • git push origin master

    • -f表示强制覆盖

  • --set-upstream推送到远端的同时并且建立起和远端分支的关联关系

    • git push --set-upstream origin master

  • 如果当前分支已经和远端分支关联，则可以省略分支名和远端名

    • git push将master分支推送到已关联的远端分支

3.5.4 本地分支与远程分支的关联关系

• 查看关联关系我们可以使用git branch -vv命令

3.5.5 从远程仓库克隆

如果已经有一个远端仓库，我们可以直接clone到本地

• 命令：git clone <仓库路径>[本地目录]

  • 本地目录可以省略，会自动生成一个目录

3.5.6 从远程仓库中抓取和拉取

远程分支和本地分支一样，我们可以进行merge操作，只是需要先把远端仓库里的更新都下载到本地，再进行操作。

• 抓取命令：git fetch [remote name（一般是origin）] [branch name]

  • 抓取命令就将仓库里的更新都抓取到本地，不会进行合并

  • 如果不指定远端名称和分支名，则抓取所有分支

• 拉取命令：git pull [remote name（一般是origin）] [branch name]

  • 拉取指令就是将远端仓库的修改拉到本地并自动进行合并，等同于fetch+merge

  • 如果不指定远端名称和分支名，则拉取所有并更新当前分支

3.5.7 远程解决冲突

在一段时间，A、B用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突。

A用户在本地修改代码后优先推到远程仓库，此时B用户在本地修订代码，提交到本地仓库后也需要推送到远程仓库，此时B用户晚于A用户，故需要先拉区远程仓库的提交，经过合并后才能推送到远端分支，如图所示：

这张图清晰地展示了 git pull 和 git push 在 Git 版本控制流程中对本地仓库（master）和远程仓库（origin/master）分支状态的影响，以下是详细分步解读：

初始状态（左侧图）

• (head->master)：本地 master 分支的当前指针位置（head 指向本地分支最新提交），代表本地仓库的代码状态（B 提交的修改）。

• (origin/master)：远程仓库 master 分支在本地的 “镜像” 指针（记录远程仓库的代码状态），代表远程仓库的代码状态（A 提交的修改）。

• 此时本地和远程分支存在差异：本地是 B 的修改，远程是 A 的修改。

步骤 1：git pull（中间图）

• git pull 的本质：等价于git fetch + git merge，做了两件事：

  1. git fetch：从远程仓库拉取最新代码到本地，但不合并到当前分支（更新 origin/master 指针到远程最新提交）。

  2. git merge：将远程更新（origin/master）合并到本地 master 分支，生成新的合并提交（图中带 merge from origin/master 的节点）。

• 结果：

  • 本地 master 分支指针（head->master）“快进 + 合并”，同时包含本地 B 的修改和远程 A 的修改。

  • origin/master 指针暂时未变（后续 git push 才会同步）。

步骤 2：git push（右侧图）

• git push 的作用：将本地 master 分支的最新提交推送到远程仓库，让远程仓库与本地同步。

• 结果：

  • 远程仓库的 master 分支指针被更新，与本地 master 分支一致（origin/master 指针移动到最新提交）。

  • 此时本地 (head->master) 和远程 (origin/master) 指针重合，本地与远程仓库代码状态完全同步。

关键概念总结

1. git pull：

   • 合并远程变更到本地，解决本地与远程的差异（等价于 fetch + merge）。

   • 会生成合并提交（如果有冲突则需手动解决）。

2. git push：

   • 将本地分支的最新状态推送到远程仓库，更新远程仓库的分支指针。

3. 分支指针：

   • head：本地当前分支的 “指针”，标记你正在工作的分支最新提交。

   • origin/master：远程仓库 master 分支在本地的 “镜像”，记录远程仓库的状态，git fetch/push 会更新它。

这张图核心想表达：git pull 负责拉取远程更新并合并到本地，git push 负责将本地更新推送到远程，最终让本地和远程仓库的分支状态保持一致 。

在B用户拉取代码时，因为A、B用户同一段时间修改了同一个文件的相同位置代码，故而会发生合并冲突。

远程分支也是分支，所以合并时冲突的解决方式也和解决本地分支冲突相同。

练习：远端仓库操作

# 1. 本地仓库推送到远程仓库# 关联远程仓库
git remote add origin git@gitee.com:用户名/仓库名.git

# 首次推送并绑定分支：将master分支推送到远程仓库，并与远程仓库的master分支绑定关联关系
git push --set-upstream origin master

# 2. 远程仓库克隆到本地# 克隆远程仓库到指定目录
git clone git@gitee.com:用户名/仓库名.git git_test02

# 查看提交历史（精简模式）
git log --oneline

# 3. 本地修改推送到远程仓库
# 新建文件
touch file03.txt

# 添加到暂存区
git add file03.txt

# 提交到本地仓库
git commit -m "新增 file03.txt 文件"

# 推送到远程仓库
git push

# 4. 将远程仓库的修改更新到本地
# [git_test02]将远程仓库修改再拉取到本地
git pull
# 以精简的方式显示提交记录
git-log

四、在Visual Studio中使用Git

在 Visual Studio（以下简称 VS）中配置 Git 主要包括关联 Git 工具、初始化仓库、连接远程仓库等步骤，以下是详细操作流程：

1. 确保已安装 Git

首先需要在电脑上安装 Git：

• 从 Git 官网 下载对应系统的安装包，按默认选项安装（建议勾选 “Add Git to PATH”，方便 VS 自动识别）。

• 安装完成后，可在命令提示符（CMD）或 PowerShell 中输入 git --version 验证是否安装成功。

2. 在 Visual Studio 中启用 Git 支持

VS 2019 及以上版本默认集成了 Git 功能，无需额外安装插件：

• 打开 Visual Studio，进入主界面。

• 若已打开项目，可通过顶部菜单 “工具”→“选项” 打开设置窗口。

• 在左侧导航栏中找到 “源代码管理”→“插件选择”，确保 “当前源代码管理插件” 选择 “Git”（默认已选）。

• 点击 “确定” 保存设置。

3. 为项目配置 Git 仓库

情况 1：新建项目并初始化本地仓库

• 新建项目：在 VS 中点击 “创建新项目”，选择项目模板并设置保存路径，创建完成后进入项目界面。

• 初始化 Git 仓库：

  • 点击顶部菜单 “Git”→“创建 Git 仓库”。

  • 在弹出的窗口中，选择项目所在的本地文件夹作为仓库路径（默认与项目路径一致）。

  • 取消勾选 “创建远程仓库”（如需先创建本地仓库，后续再关联远程），点击 “创建”。

  • 此时项目会被初始化为 Git 仓库，VS 右侧会显示 “团队资源管理器” 面板，可看到 Git 相关操作选项。

情况 2：将已有项目纳入 Git 管理

• 打开已有项目：通过 “文件”→“打开”→“项目 / 解决方案” 打开项目。

• 初始化仓库：同上，点击 “Git”→“创建 Git 仓库”，选择项目路径完成初始化。

4. 配置 Git 用户信息

提交代码时需要设置用户名和邮箱（与远程仓库账号一致，如 GitHub/Gitee 账号）：

• 方法 1：通过 VS 界面设置

  • 在 “团队资源管理器” 面板中，点击 “设置”→“Git 全局设置”。

  • 填写 “用户名” 和 “电子邮件”，点击 “更新”。

• 方法 2：通过命令行设置

  • 在 VS 中打开 “开发者命令提示符”（“工具”→“命令行”→“开发者命令提示符”）。

  • 输入以下命令：

    git config --global user.name "你的用户名"
    git config --global user.email "你的邮箱"

5. 连接远程仓库（如 GitHub/Gitee）

步骤 1：在远程平台创建仓库

• 登录 GitHub/Gitee，创建一个新的远程仓库（获取仓库地址，如 https://gitee.com/yourname/yourrepo.git 或 SSH 地址 git@gitee.com:yourname/yourrepo.git）。

步骤 2：在 VS 中关联远程仓库

• 在 “团队资源管理器” 面板中，点击 “主页”→“同步”。

• 在 “远程” 区域点击 “添加”，输入远程仓库名称（通常为 origin）和仓库地址，点击 “保存”。

6. 基本 Git 操作（在 VS 中）

• 提交代码到本地仓库：

  • 修改项目文件后，VS 会自动检测变更，在 “团队资源管理器” 的 “更改” 面板中可看到修改的文件。

  • 勾选需要提交的文件，在 “提交消息” 框中输入描述（如 “初始化项目”），点击 “提交”。

• 推送到远程仓库：

  • 提交后，在 “同步” 面板中点击 “推送”，将本地提交推送到远程仓库（首次推送可能需要输入远程平台的账号密码或验证 SSH 密钥）。

• 拉取远程更新：

  • 若远程仓库有其他人的提交，在 “同步” 面板中点击 “拉取”，获取最新代码。

• 分支管理：

  • 在 “团队资源管理器” 的 “分支” 面板中，可创建、切换、合并分支（点击 “新建分支” 输入名称，或右键现有分支选择 “切换到”）。

7. 常见问题

• VS 找不到 Git：检查 Git 是否安装，或在 “工具”→“选项”→“源代码管理”→“Git 全局设置” 中手动指定 Git 安装路径（如 C:\Program Files\Git\bin\git.exe）。

• 推送失败：检查远程仓库地址是否正确、是否有推送权限，或先拉取远程更新解决冲突。