文章目录
- 一、获取本地仓库
- 二、基础操作命令
-
- [1.git add / git commit](#1.git add / git commit)
- [2.查看修改的状态 git status](#2.查看修改的状态 git status)
- [3.查看提交日志 git log](#3.查看提交日志 git log)
- [4.版本切换 git reset / git reflog](#4.版本切换 git reset / git reflog)
- [5.添加文件至忽略列表 .gitignore](#5.添加文件至忽略列表 .gitignore)
- 三、分支
- 四、开发中分支使用原则与流程
- 五、远程仓库
一、获取本地仓库
使用Git对代码进行版本控制,首先要获得本地仓库
- 1)在电脑的任意位置创建一个空目录作为本地Git仓库
- 2)进入这个目录,打开Git bash窗口
- 3)执行命令 git init
- 4)创建成功后可以在文件夹下看到隐藏的.git目录
示例


二、基础操作命令
1.git add / git commit

Git工作目录下,对文件的修改(增加、删除、更新)会存在几个状态,这些修改的状态会随着执行Git的命令而发生变化
git add添加工作区到暂存区 (工作区 --> 暂存区)git commit提交暂存区到本地仓库(暂存区 --> 本地仓库)
典型流转路径
| 操作 / 状态 | 工作区 | 暂存区 | 仓库 |
|---|---|---|---|
| 新建文件(从未跟踪开始) | 未跟踪 (untracked) | --- | --- |
| 修改已有文件(文件已跟踪) | 未暂存 (unstaged) | --- | --- |
git add |
修改/新文件进入暂存区 | 已暂存 (staged) | --- |
git commit |
--- | --- | 生成一次提交记录 (commit 01, 02, 03...) |
Git 的核心逻辑就是三个区域的流转:
-
工作区 (你写代码的地方):新文件是未跟踪 ,修改已有文件是未暂存。
-
暂存区 (提交前的缓存):执行
git add后,改动进入这里,变为已暂存。 -
仓库 (永久历史记录):执行
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

补充说明--合并的快进模式
什么是快进合并?
要理解快进合并,先看一个场景:
-
你从 master 分支拉了一个 feature 分支开始开发。
-
在你开发期间,master 分支没有任何新的提交。
-
当你完成开发,要把 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 派生 |
master、develop、test |
| 测试分支 | 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 分支名