Git 专题 - 技术栈

全局配置

bash 复制代码

git config --global user.name "admin"
git config --global user.email "405015@qq.com"
git config --list

工作区：包含.git文件夹的目录就是工作区，也称为工作目录或工作空间，主要用于存放开发的代码
版本库：.git隐藏文件夹就是版本库，版本库中存储了很多配置信息、日志信息和文件版本信息等
暂存区：.git文件夹中有很多文件，其中有一个index文件就是暂存区，也可以叫做stage。暂存区是一个临时保存修改文件的地方

流程

初始化项目

bash 复制代码

git init

添加一个文件，并查看当前git状态

添加了 1.txt，输入命令 git status，可以看到提示未添加的文件

txt 复制代码

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        1.txt

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

将 1.txt 添加到暂存区

bash 复制代码

git add 1.txt

此时再输入 git status，可以看到有一个需要提交的修改。

txt 复制代码

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   1.txt

此外暂存区有文件的情况下，.git 目录的index会出现

提交到本地仓库

bash 复制代码

git commit -m '第一次提交'

可以看到一个文件已经提交

txt 复制代码

[master (root-commit) 310cc1d] 第一次提交
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 1.txt

查看装填，可以看到 working tree clean，非常干净

txt 复制代码

$ git status
On branch master
nothing to commit, working tree clean

查看提交日志

bash 复制代码

git log

可以看到提交日志

txt 复制代码

$ git log
commit 310cc1d6a65e773e63e5d86459733c9cd8f9c6ec (HEAD -> master)
Author: GKUN <405015@qq.com>
Date:   Fri Jan 9 11:52:37 2026 +0800

简介的信息 reflog

txt 复制代码

$ git reflog
310cc1d (HEAD -> master) HEAD@{0}: commit (initial): 第一次提交

修改文件后提交

修改文件后，重新查看状态，可以看到 modified: 1.txt

txt 复制代码

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   2.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   1.txt

恢复到指定版本

bash 复制代码

git reset --hard 5767f7f87fa39cdf77ecad84597e7e272125836e

取消 / 暂存区

取消暂存区，返回命令

bash 复制代码

git reset

忽略文件

忽略文件列表被存放在项目根目录中一个被称之为 .gitignore 的文件中。

忽略文件的规则

忽略一个特定的文件：path/file.ext
忽略项目下所有这个名字的文件：filename.ext
忽略项目下所有这个类型的文件：*.class
忽略一个特定目录下的所有文件：target/*

远程推送 / 远程拉取

bash 复制代码

# 添加关联的远程仓库
$ git remote add origin https://gitee.com/casw222/td1.git

# 查看关联的仓库
$ git remote
origin

$ git remote -v
origin  https://gitee.com/casw222/td1.git (fetch)
origin  https://gitee.com/casw222/td1.git (push)

# 移除关联的远程仓库
git remote remove origin

推送到远程分支主，会弹出来登录

bash 复制代码

# 推送到远程分支主
$ git push origin master

远程拉取

bash 复制代码

git clone https://gitee.com/casw222/td1.git

拉取最新的代码

bash 复制代码

git pull origin master

注意：如果当前本地仓库不是从远程仓库克隆的，而是本地创建的仓库，并且仓库中存在新文件，此时再从远程仓库拉取文件的时候会报错（fatal: refusing to merge unrelated histories）

解决此问题可以在 git pull命令后加入参数--allow-unrelated-histories

分支

分支是Git中的一个非常重要的概念。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线
同一个仓库可以有多个分支，各个分支相互独立，互不干扰。
通过 git init 命令创建本地仓库时默认会创建一个 master 分支。

HEAD是一个特殊的引用（reference），它指向当前分支的最新提交（commit）。HEAD标识了当前分支中工作的基础点，即你最近一次提交的地方关键步骤流程如下：

创建分支：从主分支（如master）出发，创建一个新的分支（如v1）。这允许开发者在新的分支上自由地进行代码修改，而不必担心这些修改会立即影响到主分支或其他团队成员的工作。
独立开发：在v1分支上，开发者可以自由地编写代码、测试功能，甚至进行多次提交，所有这些操作都独立于主分支。
合并分支：当v1分支上的开发完成后，开发者可以选择将v1分支的更改合并回主分支。这确保了主分支能够包含所有最新的功能和修复，同时保持了代码的整洁和一致性。
灵活管理：Git的分支机制还允许开发者在需要时轻松地切换分支，比如从v1分支切换到master分支查看或处理其他事务，然后再切换回v1分支继续工作（HEAD的作用）

bash 复制代码

# 列出所有本地分支
git branch
# 列出所有远程分支
git branch -r
# 列出所有本地分支和远程分支
git branch -a

# 创建分支
git branch 分支名称
# 切换分支
git checkout 分支名称
# 将分支推送至远程仓库
git push 远程仓库简称 分支名称

合并分支

操作步骤：

在b1分支中创建一个新的文件b1.txt文件
使用git add 添加到暂存区
使用git commit 命令提交到本地仓库
使用git checkout 命令切换到master分支
使用git merge 命令来合并两个分支

分支创建规则

在项目开发中，遵守Git分支的创建规则通常是为了提高团队协作效率、代码质量以及版本管理的清晰度。以下是一些常见的Git分支创建规则：

主分支（master）

主分支是项目的稳定版本，用于发布和部署，只有经过严格测试和代码审核的代码才能被合并到主分支，通常命名为master，master分支以 tag 标记一个版本，因此在 master 分支上看到的每一个 tag 都应该对应一个线上版本。

开发分支（develop/dev）

开发分支是团队进行日常开发的主要分支，包含了项目中最新的功能和代码，通常命名为develop或dev，每个新功能或任务通常从该分支创建独立的特性分支进行开发。

特性分支（feature）

特性分支用于开发特定的功能，每个新功能或任务都应在从develop分支创建的feature/xxx形式的特性分支上进行开发和测试，开发完成后合并回 develop 分支并且删除该 feature/xxx 分支。

预发布分支（release）

预发布分支用于准备发布新版本，进行最后的测试和调整，从 develop 分支创建以确保代码稳定，命名格式为release/xxx，其中xxx是具体的版本号，创建好 release 分支后需要对要发布的功能进行最后的测试，如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。测试完成之后，将 release 分支合并到 master 和 develop 分支，此时 master 为最新代码，用作上线。

修复分支（hotfix/bugfix）

修复分支用于解决线上紧急bug或修复已知问题，从 master 分支创建以确保修复代码直接应用于稳定版本，命名格式为hotfix/xxx或bugfix/xxx ，完成bug修复后将代码合并到master分支和develop分支，合并完成后可以删除该分支。

以上就是在项目中应该出现的分支以及每个分支功能的说明，其中长期稳定存在的分支只有 master 和 develop 分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。简单总结如下：

master 分支: 线上稳定版本分支

develop 分支: 开发分支，衍生出 feature 分支和 release 分支

feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除

release 分支: 预发布分支，准备待发布版本的分支，存在多个，版本发布之后删除

hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除

冲突解决

多人同时修改同一文件：一个项目是由一个团队开发，如果多个开发人员同时对同一个文件的相同部分进行修改，并尝试提交这些修改时，Git无法自动合并这些更改，从而导致冲突。
合并分支时：当尝试将两个不同的分支合并到一个公共分支（如主分支）或者尝试将其他分支的代码合并到当前分支时，如果这些分支对同一个文件进行了不同的修改，Git在合并这些更改时可能会产生冲突。
重命名或移动文件：如果在一个分支中重命名或移动了文件，而在另一个分支中对原始文件进行了修改，那么在合并这些分支时可能会产生冲突。
删除文件：如果一个分支删除了某个文件，而另一个分支对该文件进行了修改，合并时也会发生冲突。

查看冲突：

使用git status命令查看哪些文件存在冲突。
使用git diff命令查看冲突文件的差异。

手动解决冲突：
手动解决冲突

打开冲突文件，找到被Git标记的冲突部分。通常，Git会用<<<<<<<、=======和>>>>>>>这样的标记来指示冲突的开始、当前分支的更改、另一个分支的更改和冲突的结束。
手动编辑冲突部分，根据需要保留或合并不同的更改。
删除Git的冲突标记（<<<<<<<、=======、>>>>>>>）。

提交更改：

使用git commit命令提交解决冲突后的更改。在提交信息中，可以简要描述解决冲突的过程。
git commit -a -m '解决冲突' 全部提交
git commit abc.txt -i -m "解决冲突" 提交部分文件

（可选）继续合并或推送：

如果是在合并分支时产生的冲突，解决冲突后可以继续合并其他分支。
如果需要，将更改推送到远程仓库。