GitLab 企业级实操手册：从基础命令到生产环境安全回退（revert 完整流程）

这是工作后自己整的gitlab使用笔记，大概涵盖我工作两个月正常使用的全部操作，感兴趣可以看下

📌 本文适用场景：GitLab/GitHub 多人协作开发、企业级生产分支维护，覆盖日常开发全流程命令 + 公共分支安全回退标准作业流程。面向开发、运维工程师，所有命令均可直接复制执行，附高频踩坑避坑指南。

写在前面

很多新人在多人协作场景下，经常会遇到：公共分支写错代码不敢回退、合并冲突处理混乱、强制推送覆盖同事代码、stash 时机不对导致代码丢失等问题。本文整理了从仓库初始化、分支管理、远程连接，到生产级公共分支安全回退（git revert） 的完整标准流程，修正了大量网上常见的错误用法，可直接作为团队内部操作规范使用。

一、Git 本地仓库基础操作

1. 初始化本地仓库

进入项目工作目录后执行，将普通目录初始化为 Git 仓库：

复制代码

git init

2. 查看仓库当前状态

输出当前分支、文件追踪状态、暂存区状态：

已加入暂存区的文件显示绿色
未追踪/未暂存的修改显示红色

git status

3. 文件加入暂存区

提交全部修改文件到暂存区：

复制代码

git add .

4. 生成本地版本快照

将暂存区内容提交为本地永久提交记录：

复制代码

git commit -m "提交日志描述"

5. 查看提交历史

查看当前分支完整提交历史：

复制代码

git log

查看所有分支的精简提交历史（带分叉图形）：

复制代码

git log --graph --oneline --all

6. 查看所有操作记录（含回退记录）

包含 HEAD 所有跳转历史，回退错了可以靠它找回哈希值：

复制代码

git reflog

7. 版本强制回退（仅限本地）

⚠️ 高危警告 ：--hard 会直接丢弃工作区和暂存区所有未提交改动；已经推送到远程的公共分支，绝对禁止使用 reset 回退，会破坏他人提交历史。

复制代码

git reset --hard <commit哈希值>

二、分支管理与合并冲突处理

1. 查看分支

查看所有本地分支及最新提交：

复制代码

git branch -v

2. 创建分支

创建名为 tz-dev 的开发分支：

复制代码

git branch tz-dev

3. 切换分支

两种命令等效，switch 是新版 Git 推荐用法：

复制代码

git checkout tz-dev
git switch tz-dev

4. 工作区未提交时切换分支

代码写到一半需要切分支，直接切换会报错，用 stash 暂存：

复制代码

git stash          # 暂存当前工作区修改
git switch tz-dev  # 切换目标分支

# 切回原分支，恢复之前暂存的改动
git switch main
git stash pop

5. 分支合并

当前在 master 分支，将 tz-dev 的改动合并进来：

复制代码

git merge tz-dev

合并后 tz-dev 分支本身不会消失，只是把改动合并到当前分支。

6. 合并冲突处理

6.1 少量冲突：手动修改

冲突文件会出现如下标记：

复制代码

<<<<<<< HEAD    # 当前分支（master）的代码
=======         # 要合并过来的分支（tz-dev）的代码
>>>>>>> tz-dev

手动删除冲突标记，保留最终需要的代码，保存后执行：

复制代码

git add 冲突文件
git commit -m "解决合并冲突"

6.2 大量冲突：策略合并 / 图形工具

方案1：图形化工具解决（适合几十上百个文件冲突）

复制代码

git mergetool

Windows 推荐安装 TortoiseGit，右键菜单可直接可视化解决冲突。

方案2：策略合并，直接指定冲突保留哪一方

复制代码

# 当前在 master，合并 tz-dev，冲突全部保留当前 master 代码（我方）
git merge -X ours tz-dev

# 当前在 master，合并 tz-dev，冲突全部采用 tz-dev 代码（对方）
git merge -X theirs tz-dev

三、远程仓库（GitLab）连接管理

1. 查看远程仓库配置

仅查看别名：

复制代码

git remote

查看别名 + 完整地址：

复制代码

git remote -v

2. 新增远程仓库连接

本地新项目第一次关联 GitLab 仓库：

复制代码

git remote add origin git@gitlab.com:用户名/仓库名.git

3. 修改远程仓库地址

仓库迁移、HTTPS 切换 SSH 时使用：

复制代码

git remote set-url origin https://gitlab.com/用户名/仓库名.git

4. 删除本地远程连接

仅删除本地保存的地址配置，不会影响 GitLab 远端仓库本身：

复制代码

git remote remove origin

四、代码推送与拉取的正确姿势

1. 分支第一次推送远程（绑定上游）

复制代码

# main 分支首次推送
git push -u origin main

# 新建 tz-dev 分支首次推送
git switch tz-dev
git push -u origin tz-dev

-u 绑定上游后，后续直接 git pull / git push 即可，不用每次写分支名。

2. 日常推送（已绑定上游）

复制代码

git add .
git commit -m "修复登录bug"
git push

3. 本地与远程分支名不一致

本地分支名 dev，推送到远程 test 分支：

复制代码

git push origin dev:test

4. 删除远程分支

复制代码

git push origin --delete old-branch

本地远程一起删除：

复制代码

git push origin --delete old-branch
git branch -d old-branch

5. 拉取远程最新代码

普通合并模式（会生成 merge 提交，历史分叉）：

复制代码

git pull origin tz-dev

变基模式（推荐，无额外合并提交，历史一条直线）：

复制代码

git pull origin tz-dev --rebase

✅ 多人协作开发分支，优先使用 --rebase 模式，保持提交历史干净线性。

五、【重点】生产分支安全回退：git revert 完整流程

适用场景：多人共用的开发/生产分支，代码已经推送到远程，需要回退某一笔提交，且该提交之后已经有新的提交。 ❌ 禁止用 reset：会删除历史，强制推送会覆盖同事代码，属于生产事故。 ✅ 标准方案：用 git revert 生成一条新的提交，反向抵消目标提交，不删除任何历史记录。

1. 定位需要回退的提交

复制代码

# 查看精简提交记录，获取目标哈希
git log --oneline

# 确认该提交改动了哪些文件
git show <commit哈希> --stat

2. revert 前安全检查

复制代码

# 查看目标目录下的提交记录，确认影响范围
git log --oneline -- <目录路径>

# 检查新增组件/文件是否被其他模块引用，避免回退引发连锁报错
git grep -E "新增的组件名|关键字" -- "src/**"

3. 前置准备：工作区干净检查

执行 revert 前工作区不能有未提交改动，否则会状态混乱。如果有未提交代码，仅执行暂存，不要在这里 pull 和 pop：

复制代码

git stash   # 暂存工作区修改，保证目录干净

4. 执行 revert 操作

无冲突场景，直接生成本地回退提交：

复制代码

git revert <commit哈希> --no-edit

--no-edit：跳过编辑器，直接使用默认提交信息 Revert "原提交信息"。

出现冲突场景：

复制代码

git status          # 查看冲突文件
# 手动修改解决冲突
git add .
git revert --continue  # 继续完成 revert，生成本地提交

✅ 执行完 git revert --continue，revert 提交就已经在本地仓库生成完成，但还没到 GitLab 远端。

5. 对齐远端 + 推送远程

复制代码

# 拉取远端最新代码，把本地 revert 提交变基到最新代码之上
git pull origin 分支名 --rebase

# 推送到 GitLab 远程分支，回退正式生效
git push origin 分支名

6. 恢复本地工作区改动

复制代码

git stash pop

📋 完整标准流程一键复制版

复制代码

# 1. 定位+检查
git log --oneline
git show <hash> --stat

# 2. 工作区暂存
git stash

# 3. 执行回退
git revert <hash> --no-edit
# 冲突则执行：git add . && git revert --continue

# 4. 对齐远端并推送
git pull origin tz-dev --rebase
git push origin tz-dev

# 5. 恢复本地修改
git stash pop

六、高频踩坑避坑指南

公共分支禁止 git reset --hard + 强制推送 这是多人协作头号红线，会直接抹掉别人的提交，造成代码丢失。公共分支回退一律用 revert。
git revert --continue 不是推送远程 它只是生成本地提交；真正传到 GitLab 靠 git push。
stash 时机错误 不要在 revert 执行一半、rebase 中途去 stash/pop；统一在操作前暂存，全部结束后再恢复。
pull --rebase 冲突不要慌 解决冲突 → git add . → git rebase --continue；想放弃就 git rebase --abort，全程不要手动 commit。
不要盲目 -f 强制推送 push 被拒绝先检查是不是本地落后远端，先 pull --rebase 再 push；公共分支永远不要随便加 -f。
merge 的 ours/theirs 不要搞反 以当前所在分支为基准，ours 是当前分支，theirs 是要合并进来的分支。

结尾

Git 命令本身不难，难的是多人协作场景下的规范和风险控制。尤其是生产环境的代码回退，宁可流程多几步，也不要图省事用危险操作。这份手册覆盖了企业日常开发 90% 以上的 Git 场景，建议收藏备用，也可以作为团队新人培训的操作规范。