引言
我在最初开始学习使用 Git 时总是被它各种各样的命令搞得晕头转向,记也记不住,也难以将各种命令相联系起来,并且也不知道这么多的命令到底哪些才是在真实项目开发中所会经常用到的,抓不住重点,导致学习时十分痛苦。
后来我也想明白了,我为什么不按照使用 Git 的开发工作流程来学习呢?针对每一步骤来学习与此相关的 Git 命令和一些操作。这样,既不用担心学的命令用不上,同时学习时也能有目的性,知道学的这些命令是用来干什么的,也能加强命令之间的联系,也因此,有了这篇文章。
在讲正文前,我先用一句话讲明 Git 对于项目的作用吧:所有人从仓库克隆代码,开分支各改各的,完成后,发起合并请求,评审无误后合并,测试通过自动部署。全程有日志、有备份、可回滚。
下图是 git 储存文件的不同区域:
在 IDEA 中,你所用来查看和编辑文件的区域就是工作区,
当你做出修改后,IDEA 内置的功能会自动将其存储到暂存区
使用 commit 或点击提交则修改了的文件会保存到本地仓库
使用 push 或点击推送则会被推送到远程仓库

第 1 步 初始化/克隆仓库
对于第一步,主要有两种场景:
场景 一:自己从零开始开发的新项目
1.选择一个文件夹用来存放项目
2.对该文件夹使用:git init //进行初始化
3.将其与自己在Github上的一个空白仓库关联起来:git remote add origin 你的项目的地址

场景二:参与已有项目
同样选择一个文件夹进行下列操作:
git clone <仓库地址> //SSH和HTTPS都可以
例如:git clone https://github.com/your-team/project.git
第 2 步 同步最新代码(主分支)
这一步是为了确保本地主分支和远程主分支完全一致,避免基于过时的代码创建功能分支,导致后面合并时出现太多冲突。
git checkout main # 切换到主分支 使用checkout来切换
git pull origin main # 拉取远程最新提交并合并到本地
git pull等价于git fetch+git merge。
常见问题
- 有未提交的修改时 Git 会拒绝 pull,此时要么提交
git commit,要么临时储藏git stash。 - 合并冲突:如果本地 main 有独特提交,解决冲突后提交。
第 3 步 创建功能分支
为什么要做这一步?
- 隔离开发,不影响主分支稳定性。
- 多人并行开发不同功能,互不干扰。
- 方便代码审查和回退。
# 基于当前 main 创建并切换到新分支
git checkout -b feature/你的功能名 # 创建了一个名为:“feature/你的功能名”的分支
# 只基于当前分支创建不切换
git branch feature/你的功能名2 # 注:feature/你的功能名 和 feature/你的功能名2是两个不同的分支
# 常用分支命名规范:
# feature/add-login —— 新功能:增加登录
# bugfix/登录异常 —— 修复 bug:修复登录异常
# hotfix/紧急补丁 —— 生产环境紧急修复:紧急补丁
# docs/update-readme —— 文档更新:更新readme
常见问题
- 分支名字错了想改名:
git branch -m feature/old-name feature/new-name
- 创建错了分支:删除它
git branch -d feature/wrong,注意-d只能在未合并时安全删除。
小技巧
- 查看当前所有分支:
git branch -a(-a 包括远程分支)。 - 如果你忘了切分支就在 main 上改了代码,可以用
git checkout -b feature/new-branch把当前修改带走,然后再重置 main。
第 4 步 在分支上开发并提交
基本流程
# 查看哪些文件被修改了
git status
# 把改动加入暂存区
git add . # 添加所有改动(包括新文件、删除)
git add src/main.js # 只添加指定文件
git add src/ # 添加整个目录
# 提交(写清晰的提交信息)
git commit -m "feat: add user login validation"
提交信息规范
| 类型 | 说明 | 例子 |
|
| 新功能 |
|
|
| 修复 bug |
|
|
| 文档修改 |
|
|
| 代码格式(不影响逻辑) |
|
|
| 重构 |
|
|
| 测试相关 |
|
|
| 构建/工具变动 |
|
常见问题
- 提交错了想修改:
# 只想补充漏掉的文件,不修改提交信息
git add 漏掉的文件
git commit --amend --no-edit # --no-edit表示原来的提交信息不变
# 既要补充文件,又要修改提交信息
git add 漏掉的文件
git commit --amend -m "新的提交信息"
# 只想改提交信息
git commit --amend -m "新的提交信息"
- 撤销最后一次提交(保留修改):
git reset --soft HEAD~1
- 不小心 add 了多余文件:
git rm --cached <文件>把它移出暂存区。
第 5 步:保持与主分支同步(避免冲突)
为什么要做这一步?
- 在你开发期间,团队成员可能已经向主分支合并了其他功能。
- 你的分支应包含这些新代码,否则推送后会产生合并冲突,甚至覆盖别人的修改。
- 提前在本机解决冲突,比在 PR 页面上解决更轻松。
具体操作(两种方式)
方式一:merge(直观,适合新手)
# 1. 先切换回主分支,拉取最新
git checkout main
git pull origin main
# 2. 再切回你的功能分支
git checkout feature/xxx
# 3. 然后把主分支合并进来
git merge main
- 如果有冲突,Git 会提示哪些文件冲突(
CONFLICT)。 - 手动编辑冲突文件(会看到
<<<<<<< HEAD和>>>>>>> main标记)。 - 解决后
git add .,然后git commit -m "merge main into feature/xxx"。
方式二:rebase(推荐,历史更干净)
# 在功能分支上执行
git checkout feature/xxx # 切换到你开发的分支
git rebase main # 进行合并
- Git 会把你分支上的每个提交“摘下”,然后依次接到 main 分支最新提交的后面
- 遇到冲突时,Git 会暂停并提示:解决冲突 →
git add .→git rebase --continue - 如果需要跳过某个补丁:
git rebase --skip - 想放弃 rebase:
git rebase --abort
| 对比 | merge | rebase |
| 历史 | 多一个合并提交,形成网状 | 线性,像刚基于最新 main 开发的 |
| 冲突解决 | 一次性解决所有冲突 | 每个提交依次解决,可能多次 |
| 适合场景 | 公共分支间合并 | 本地分支同步上游 |
常见问题
- rebase 后推送失败:因为历史改变了,需要用
git push --force-with-lease(比--force安全,能检查是否有人在你之前推送)。 - merge 产生了很多“Merge branch main”的提交:如果介意,可以用 rebase。
小技巧
- 每天开始开发前或准备推送前,都执行一次
git fetch origin+git rebase origin/main。 - 如果分支已经推送到远程并且有其他人也在用(协同开发),不要 rebase,用 merge。
第 6 步:推送功能分支到远程
# 第一次推送,应建立与远程分支的关联
# 如果远程没有所指定的分支,远程则会自动创建同名分支
git push -u origin feature/xxx
# -u 是 --set-upstream 的缩写,记录远程分支,之后直接 git push 即可
# 后续推送
git push
常见问题
- 推送被拒绝(rejected):
-
- 原因 1:远程分支有新的提交(比如你用了
rebase改变了历史)。解决:git push --force-with-lease。 - 原因 2:你没有权限。解决:联系仓库管理员。
- 原因 1:远程分支有新的提交(比如你用了
- 推送时想删除远程分支:
git push origin --delete feature/xxx
小技巧
- 查看本地分支对应的远程分支:
git branch -vv。 - 如果 rebase 后需要强制推送,推荐使用
--force-with-lease,它会检查远程分支是否被你之外的人更新过,更安全。
第 7 步:发起 Pull Request / Merge Request
- Pull Request(PR,GitHub 叫法)或 Merge Request(GitLab 叫法)是你请求别人把你的代码合并到主分支的动作。
- 它提供了一个界面:查看代码改动、发表评论、自动化测试、代码审查等。
具体操作(以 GitHub 为例)
- 打开仓库首页,通常会有黄色提示条:“feature/xxx had recent pushes”,点击 Compare & pull request。
- 如果没有提示,点击顶部 Pull requests → New pull request。
-
- base 选择
main(你要合入的目标分支)。 - compare 选择
feature/xxx。
- base 选择
- 填写 PR 信息:
-
- 标题:简明扼要,如
Add user login feature。 - 描述:写下背景、做了什么、如何测试、是否关联 Issue(
Closes #12)。 - 右侧可以指定 Reviewers(审查者)、Assignees(负责人)、Labels(如
enhancement)。
- 标题:简明扼要,如
- 点击 Create pull request。
注意事项
- 创建 PR 后,你继续向
feature/xxx推送新提交,PR 会自动更新,无需重新创建。 - 如果还没开发完,可以创建 Draft PR(草稿),告诉别人暂时不要合并。
小技巧
- 在描述中使用
Closes #123,合并后会自动关闭对应的 Issue。 - 添加截图或 GIF 动图,能直观展示界面变化。
第 8 步:代码审查与合并
代码审查(Code Review)
- 审查者可以在 PR 的 Files changed 标签页看到你所有的改动。
- 他们可以:
-
- 在某行留下评论:“这里变量名建议用
camelCase”。 - 请求修改:点击 Request changes 要求你改动后才能合并。
- 批准:点击 Approve。
- 在某行留下评论:“这里变量名建议用
- 你根据反馈在本地功能分支上修改:
git add .
git commit -m "fix: address review comments"
git push
新的提交会自动出现在 PR 中。
审查通过后合并
- 有权限的人(通常是你自己或项目负责人)点击 Merge pull request。
- 合并时有三种策略可选(非常重要):
| 策略 | 行为 | 历史效果 | 推荐场景 |
| Create a merge commit | 保留你分支上的所有原始提交,并新增一个合并提交 | 完整保留所有细节,但历史有分叉 | 需要保留每个小提交的历史 |
| Squash and merge | 把你分支上的所有提交压缩成一个提交,然后合并到 main | 历史干净,main 上只有一个功能提交 | 最推荐,日常开发 |
| Rebase and merge | 把你的提交线性接到 main 末尾(不产生合并提交),类似先 rebase 再合并 | 线性历史,但丢失分支的并行信息 | 追求极简线性历史 |
- 点击 Confirm merge。
常见问题
- 合并时出现冲突:GitHub 会提示“无法自动合并”,你需要先在本地解决冲突再推送。
- 合并后想撤销:
git revert <merge-commit-hash>但比较复杂,建议合并前谨慎。
第 9 步:清理分支
为什么要清理?
- 功能分支已经合并到主分支,不再需要。
- 保留无用分支会让仓库混乱,干扰
git branch列表。
具体操作
删除本地分支
# 先切出要删的分支(比如回到 main)
git checkout main
# 删除 feature/xxx(-d 会检查是否已合并)
git branch -d feature/xxx
# 如果提示未完全合并但仍想删除,用 -D 强制删除
git branch -D feature/xxx
删除远程分支
git push origin --delete feature/xxx
或者在 GitHub PR 页面点击 Delete branch 按钮(合并后会自动出现)。
清理本地过期的远程分支引用
- 删除远程分支后,你本地
git branch -a仍可能看到remotes/origin/feature/xxx,那是残留的缓存。
git remote prune origin
# 或者 fetch 时清理
git fetch --prune
小技巧
- 设置自动清理:
git config --global fetch.prune true,以后git fetch会自动删除本地不存在的远程分支引用。 - 查看哪些分支已经合并到 main:
git branch --merged main
可以批量删除它们(小心别删掉 main 本身)。
最后,给大家介绍一个不错的用来练习git命令的网站:Learn Git Branching
要知道,有过实际操作git和没有实际操作过在学习git时完全是两种感觉,尽量还是要去实践的
到这里,本篇文章就结束了,可以看到我并没有介绍太多的命令,我更多的是想给大家提供一个学习git的思路,即本文标题:根据工作流程来学习git命令。这样,大家在学习时就不至于被各种命令搞晕了头。就可以有目的性的去学习,比如可以直接了当的去查跟推送功能分支到远程相关的命令等。
内容创作不易,如果本文对你有所帮助,不妨点赞、收藏、关注支持一下,谢谢你的阅读!!!

1612

被折叠的 条评论
为什么被折叠?



