Git工具使用指南

文章目录

一、获取本地仓库

使用Git对代码进行版本控制,首先要获得本地仓库

  • 1)在电脑的任意位置创建一个空目录作为本地Git仓库
  • 2)进入这个目录,打开Git bash窗口
  • 3)执行命令 git init
  • 4)创建成功后可以在文件夹下看到隐藏的.git目录

示例

二、基础操作命令

1.git add / git commit

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

  1. git add 添加工作区到暂存区 (工作区 --> 暂存区)
  2. git commit 提交暂存区到本地仓库(暂存区 --> 本地仓库)

典型流转路径

操作 / 状态 工作区 暂存区 仓库
新建文件(从未跟踪开始) 未跟踪 (untracked) --- ---
修改已有文件(文件已跟踪) 未暂存 (unstaged) --- ---
git add 修改/新文件进入暂存区 已暂存 (staged) ---
git commit --- --- 生成一次提交记录 (commit 01, 02, 03...)

Git 的核心逻辑就是三个区域的流转:

  1. 工作区 (你写代码的地方):新文件是未跟踪 ,修改已有文件是未暂存

  2. 暂存区 (提交前的缓存):执行 git add 后,改动进入这里,变为已暂存

  3. 仓库 (永久历史记录):执行 git commit 后,暂存区内容生成一次提交记录(Commit 01/02/03...)

2.查看修改的状态 git status

3.查看提交日志 git log

4.版本切换 git reset / git reflog

命令形式:git reset --hard commitID,回退到指定版本,之后的修改将被清空

  • commitID 可以使用 git log 指令查看


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

    git reset --hard commitID搭配可以回到之前的版本(这里为第二次提交)

5.添加文件至忽略列表 .gitignore

.gitignore 是一个纯文本文件,用来告诉 Git 哪些文件/文件夹不要提交(即文件无需纳入Git 的管理,也不希望它们总出现在未跟踪文件列表),通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等

基本语法

  • *.log → 忽略所有 .log 结尾的日志文件。
  • temp/ → 忽略根目录下的 temp 文件夹(加 / 表示只匹配根目录)。

加在末尾的 / (如 temp/)表示"这是一个目录 ",而加在开头的 / (如 /temp)才表示"只匹配根目录"。
temp/ 忽略任何位置的 temp 目录 temp/ build/temp/ src/utils/temp/

/temp/ # 仅忽略根目录下的 temp 文件夹,不递归匹配子目录

  • ! 取反:比如想忽略所有 .env,但保留 .env.example,可以这样写:

    复制代码
     *.env
     !.env.example

前后对比

创建.gitignore前

创建.gitignore后,并在.gitignore中编辑了a.txt

三、分支

1.查看本地分支

  • 命令: git branch

2.创建本地分支

  • 命令:git branch 分支名

3.切换分支

  • 命令:git checkout 分支名

还可以直接切换到一个不存在的分支(创建并切换)

  • 命令:git checkout -b 分支名

4.合并分支

将其他分支合并到当前分支

  • 命令: git merge 分支名称

一般是将其他分支合并到master

补充说明--合并的快进模式

什么是快进合并?

要理解快进合并,先看一个场景:

  1. 你从 master 分支拉了一个 feature 分支开始开发。

  2. 在你开发期间,master 分支没有任何新的提交。

  3. 当你完成开发,要把 feature 合并回 master 时,由于 master 自你拉分支后就"原地没动",而 feature 已经"向前走"了很远。

这种情况下,feature 分支的提交历史直接包含master的所有历史,是 master 的"直系后裔"。Git 不需要做任何"合并"工作,只需要 master 的指针直接"快进"到 feature 分支的最新提交上就行了。这就好比把指针往前拨了一下,所以叫"快进"

快进合并的特点

  • 优点:速度快,历史记录干净、线性。因为不产生额外的合并提交,所以提交历史会是一条清晰的直线,没有多余的分叉。
  • 缺点:无法体现分支的合并痕迹。你无法从历史中看出,这个提交是来自一个独立的功能分支,因为所有提交都"平铺"在主分支上。

5.删除分支

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

  • git branch -d <分支名> 删除分支时,需要做各种检查
  • git branch -D <分支名> 不做任何检查,强制删除

6.解决冲突

在 Git 中解决冲突是协作开发必备的技能。冲突本质上是指两个分支对同一文件的同一行代码做了不同的修改,Git 无法自动判断该保留哪一个,于是把决策权交给你

解决冲突步骤如下:

1.处理文件中冲突的地方

  • 方式一:手动编辑

务必将 <<<<<<<、=======、>>>>>>> 这些标记行全部删除,只留下最终想要的代码。

  • 方式二:仅保留某一方(命令行快速方案)

如果你确定完全舍弃某一方,可以使用:

复制代码
# 保留当前分支的版本 (ours)
git checkout --ours <文件路径>

# 保留合并进来的分支版本 (theirs)
git checkout --theirs <文件路径>

注:在 git rebase 过程中,--ours 和 --theirs 所指对象是互换的,容易混淆,因此普通用户更推荐用方式一。

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

3.提交到仓库(commit)

示例

假设我们在master分支上修改了1.txt为hello world!,同时也在test分支上修改了1.txt为hello everyone!,当我们把test分支合并到master分支,就会出现冲突 ,我们保存master的修改

解决冲突

  • 按方式一,手动编辑,打开 1.txt,将 <<<<<<<、=======、>>>>>>> 这些标记行全部删除,只留下最终想要的代码。

    最终如下
  • 使用方式二解决冲突,也可以实现方式一的效果,如下

最后add 、提交

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

1.核心思想

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

2.分支类型与定义

系统共分为以下几类核心分支,各自承担不同职责:

分支类型 分支名称示例 定义与职责 派生来源(从谁创建) 合并目标(合给谁)
生产分支 master(或 main 线上运行应用的主分支,对应正式生产环境。中小规模项目以此作为线上运行的稳定代码。 --- (基线) ---
开发分支 develop 主要开发分支。如果没有并行开发但不同期上线的要求,团队日常开发都在此进行。阶段开发完成后,合并到 master 准备上线。 master 创建 master
功能分支 feature/xxxx 用于同期并行开发但不同期上线的功能模块。研发任务完成后合并回 develop,任务结束后可删除。 develop 创建 develop
紧急修复分支 hotfix/xxxx 用于线上紧急 Bug 修复。修复完成后需同时合并到 master(保障线上)、develop(保障下次发版不丢失)以及 test(保障测试环境验证)。 master 派生 masterdeveloptest
测试分支 test (补充说明)用于代码测试的环境分支。 --- ---
预上线分支 pre (补充说明)用于上线前最后验证的环境分支。 --- ---

五、远程仓库

1.添加远程仓库

此操作是初始化本地库与已创建的远程库进行对接,即在本地刚 git init,还没有任何远程关联

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

    • 远端名称,默认是origin,取决于远端服务器设置
    • 仓库路径,从远端服务器获取此URL

示例

bash 复制代码
# 添加远程仓库(origin 是默认名称,可自定义)
git remote add origin <远程仓库URL>

# 例如添加 GitHub 仓库
git remote add origin https://github.com/用户名/仓库名.git

2.查看远程仓库

  • 命令:git remote (查看所有远程仓库名称)
  • 命令:git remote -v (查看详细地址)

3.推送到远程仓库

  • 命令:git push -f --set-upstream 远端名称 \[本地分支名:远端分支名 ]
  • 远程分支名和本地分支名一样时,冒号和远端分支名可以省略。
    • git push origin master(等于 git push origin master:master)
  • -f 表示强制覆盖
  • --set-upstream 推送到远端的同时并且建立起和远端分支的关联关系。
    • git push --set-upstream origin master
  • 如果当前分支已经和远端分支关联成功后,git push 将当前分支推送到已关联的远端分支(当前分支再推送,远端名和分支名都可以省略)

4.查看本地分支与远程分支的关联

  • 命令:git branch -vv

用这个命令查看,本地分支后面[]里如果有内容,就是已关联:

输出示例

  • master 123abc origin/master → 有关联(搭档是 origin/master)

  • master 123abc → 无关联(孤儿分支,不知道跟谁配对)

5.从远程仓库克隆

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

  • 命令: git clone <仓库路径> 本地目录

    • 本地目录可以省略,会在本地新建一个和远程同名的目录

6.从远程仓库中抓取和拉取

  • 抓取 命令:git fetch <远端名> <分支名>

    • 抓取指令就是将仓库里的更新都抓取到本地,不会进行合并
  • 拉取 命令:git pull <远端名> <分支名>

    • 拉取指令就是将远端仓库的修改拉到本地并自动进行合并,等同于fetch+merge
命令格式 拉取哪个远端? 拉取哪个分支? 合并到哪个本地分支?
git pull 关联的远端仓库 所有分支 当前分支
git pull origin origin 所有分支 当前分支
git pull origin master origin master 当前分支
命令 行为差异
git fetch 拉取关联的远程仓库,所有分支的更新
git fetch remote name 拉取该远程仓库,所有分支的更新
git fetch remote name branch name 只拉取指定分支的更新

7.解决合并冲突

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

A用户在本地修改代码后优先推送到远程仓库,此时B用户在本地修订代码,提交到本地仓库后,也需要推送到远程仓库,此时B用户晚于A用户,需要先拉取远程仓库的提交,经过合并后才能推送到远端分支,原因如下

核心原因(为什么)

  • 不能直接 push:B 本地缺 A 的提交,直接 Push 会覆盖 A 的代码,所以 Git 强制拒绝push,所以需要先拉取远程仓库的提交

拉取时冲突:git pull = 拉取 + 合并。因为改了同一行,Git 不知谁对谁错,需解决冲突(同前做法)

B 用户标准操作(怎么做)

  • 拉取:git pull origin 分支名(报冲突)
  • 解决冲突:打开文件,删掉 <<<<<<< 等标记,保留最终代码。(此处为手动编辑)
  • 提交:git add . → git commit -m "xxxx"
  • 推送:git push origin 分支名
相关推荐
醉城夜风~7 小时前
MyBatis 基础CRUD全套实战学习笔记
笔记·学习·mybatis
hj2862518 小时前
Shell 脚本完整学习笔记
chrome·笔记·学习
智者知已应修善业8 小时前
【proteus交通灯故障检测的完善方案】2025-4-29
经验分享·笔记·单片机·嵌入式硬件·proteus
码片向量8 小时前
状态空间模型SSM学习笔记
笔记·学习·ssm·语音增强·状态空间
笑鸿的学习笔记9 小时前
C++笔记之内存映射、零拷贝与共享内存(学习三)-操作系统术语概念图
笔记·学习
既然如此,那就开摆9 小时前
ULIP总结
笔记·学习
xin(n_n)b10 小时前
科研小白的进阶笔记(一)
人工智能·笔记
酷可达拉斯10 小时前
Linux操作系统-简单内核优化
linux·git·php
杨浦老苏10 小时前
实测2.8MB的Rust笔记服务:MinimaMemosa部署教程
笔记·docker·群晖