Git 入门之道:从分支演化到协同开发
一:分支的概念
对于实际项目的开发,分支的使用是十分重要的,分支就是一条提交时间线。
其中,有一条主分支叫做master,最后我们的项目最后都会合并到这个分支上面。
二:分支的细节
对于学习过C++的朋友们,我们应该知道指针
其中:HEAD就是指向master的
zjh@VM-0-14-ubuntu:~/gitcode$ cat .git/HEAD
ref: refs/heads/master
master 里面存的是什么:
zjh@VM-0-14-ubuntu:~/gitcode$ cat .git/refs/heads/master
2ade14f8249026d41678e8334056dea08e079e4d
master 分支指向最新一次提交
HEAD -> master -> 最新 commit
HEAD
↓
master
↓
commit3 -> commit2 -> commit1
三:基本分支命令
1.git branch --查看当前有哪些分支
zjh@VM-0-14-ubuntu:~/gitcode$ git branch
* master
2.git branch 你要创建的分支的name --创建第一个本地分支 dev
zjh@VM-0-14-ubuntu:~/gitcode$ git branch dev
zjh@VM-0-14-ubuntu:~/gitcode$ git branch
dev
* master
3.git checkout dev --切换到 dev 分支
zjh@VM-0-14-ubuntu:~/gitcode$ git checkout dev
Switched to branch 'dev'
zjh@VM-0-14-ubuntu:~/gitcode$ git branch
* dev
master
HEAD 指向哪个分支,你当前就在哪个分支工作
4.git merge dev --把 dev 合并回 master
合并的前提是:如果你想把dev和并给master,那么就需要切到master
然后再使用这个命令
5.git branch -d dev --安全删除dev分支
意思就是此时你已经合并完了,并且你已经不在这个分支上了就可以删除
注意:
如果分支还没有被合并,Git 一般会阻止你删除。
强制删除是:
git branch -D dev
6.git stash --临时保存当前工作区的修改
如果你在dev上修改了文件,但是没有提交,这时候,你直接切到master,那么改的文件就会跟过去
所以先执行:git stash
它会把当前工作区的修改临时保存起来。
保存后再看状态:git status
会看到:working tree clean
意思是工作区干净了。
git stash 默认只能保存被 Git 追踪的文件
7.git stash pop --恢复
1. 把 stash 里的内容恢复到工作区
2. 恢复成功后,把这条 stash 删除
| 命令 | 效果 |
|---|---|
git stash pop |
恢复 stash,并删除这条 stash |
git stash apply |
恢复 stash,但保留这条 stash |
.总结表
| 场景 | 命令 | 作用 | 注意点 |
|---|---|---|---|
| 查看当前分支 | git branch |
查看本地有哪些分支 | * 表示当前所在分支 |
| 创建分支 | git branch dev |
创建 dev 分支 |
只创建,不切换 |
| 切换分支 | git checkout dev |
切换到 dev 分支 |
当前工作分支会变 |
| 创建并切换分支 | git checkout -b dev |
创建 dev 并立刻切过去 |
常用 |
| 查看当前状态 | git status |
查看工作区、暂存区状态 | 改代码后常用 |
| 修改文件 | vim README.md |
编辑文件 | 示例用的是 README.md |
| 添加指定文件 | git add README.md |
把指定文件加入暂存区 | 只添加这个文件 |
| 添加当前所有改动 | git add . |
把当前目录下所有改动加入暂存区 | 包括多个已追踪文件 |
| 提交修改 | git commit -m "message" |
提交到当前分支 | message 要写清楚 |
| 普通合并 | git merge dev |
把 dev 合并到当前分支 |
可能触发 fast-forward |
| no-ff 合并 | git merge --no-ff -m "merge dev" dev |
强制生成 merge commit | 推荐公司开发使用 |
| 查看提交记录 | git log |
查看 commit 历史 | 默认信息较多 |
| 图形化查看提交 | git log --graph --abbrev-commit --oneline --all |
以图形方式看分支历史 | 非常推荐 |
| 删除已合并分支 | git branch -d dev |
安全删除 dev |
未合并会失败 |
| 强制删除分支 | git branch -D dev |
强制删除 dev |
未合并也能删,慎用 |
| 保存当前开发现场 | git stash |
临时保存工作区修改 | 默认不保存未追踪文件 |
| 保存未追踪文件 | git stash -u |
stash 时包含未追踪文件 | 比普通 stash 更彻底 |
| 查看 stash 列表 | git stash list |
查看保存过的现场 | 会显示 stash@{0} |
| 恢复并删除 stash | git stash pop |
恢复最近一次 stash,并删除记录 | 常用 |
| 恢复但保留 stash | git stash apply |
恢复 stash,但不删除记录 | 更保险 |
| 删除 stash 记录 | git stash drop |
删除最近一条 stash | apply 后可手动删 |
| 清空所有 stash | git stash clear |
删除所有 stash | 慎用 |
| 查看 HEAD 指向 | cat .git/HEAD |
查看当前 HEAD 指向哪个分支 | 理解底层用 |
| 查看 master 指向 | cat .git/refs/heads/master |
查看 master 当前 commit id | 理解分支指针用 |
| 查看 dev 指向 | cat .git/refs/heads/dev |
查看 dev 当前 commit id | 分支本质是指针 |
| 查看 commit 内容 | git cat-file -p commit_id |
查看 commit 对象内容 | 可看到 parent |
| 切回 master | git checkout master |
回到主分支 | 合并前常用 |
| 创建修 bug 分支 | git checkout -b fix_bug |
创建并切到修 bug 分支 | 不要直接在 master 修 |
| 合并 bug 分支 | git merge --no-ff -m "merge fix_bug" fix_bug |
把 bug 修复合并回 master | 修完后做 |
| 让 dev 先合并 master | git merge --no-ff -m "merge master into dev" master |
在开发分支提前解决冲突 | 推荐习惯 |
| master 再合并 dev | git merge --no-ff -m "merge dev" dev |
把稳定后的 dev 合并回 master | 更安全 |
| 冲突后查看状态 | git status |
查看哪些文件冲突 | 冲突时先看 |
| 冲突后提交 | git add . && git commit -m "fix conflicts" |
提交冲突解决结果 | 解决冲突后必须提交 |
四:额外知识点
1.fast-forward 快进合并 和 no-fast-forward非快进合并
fast-forward -> FF
no-fast-forward -> no-ff
fast-forward
fast-forward 的本质非常简单:
Git 只是把 master 指针直接移动到 dev2 的最新提交上。
人话就是git永远就是一条直线
fast-forward 虽然快,但是有一个问题:
从历史记录里看不出来这次代码到底是 merge 进来的,还是直接在 master 上 commit 的。
no-fast-forward
即使可以快进合并,我也不让 Git 快进,而是强制生成一个新的 merge commit。
git merge --no-ff -m "merge dev2" dev2
no-ff 合并后的提交图:
假设合并前是:
master
↓
commit1
\
commit2
↑
dev2
执行:
git checkout master
git merge --no-ff -m "merge dev2" dev2
合并后变成:
commit1 -------- merge commit
\ ↑
commit2 ↑
↑ ↑
dev2 master

也就是说:
master 没有直接指向 dev2 的 commit
而是新生成了一个 merge commit
这个 merge commit 的提交信息就是:
merge dev2
2.解决merge冲突流程
# 1. 确保在 master
git checkout master
# 2. 创建并切换到 dev1
git checkout -b dev1
# 3. 修改 README.md,把 AAA 改成 BBB
vim README.md
# 4. 提交 dev1 的修改
git add .
git commit -m "modify README to BBB"
# 5. 切回 master
git checkout master
# 6. 修改 README.md,把 AAA 改成 CCC
vim README.md
# 7. 提交 master 的修改
git add .
git commit -m "modify README to CCC"
# 8. 合并 dev1
git merge dev1
# 9. 如果出现冲突,打开文件手动解决
vim README.md
# 10. 解决后重新添加
git add README.md
# 11. 提交合并结果
git commit -m "merge dev1"
# 12. 查看提交图
git log --graph --abbrev-commit --oneline --all
3.修 bug + 继续开发的完整命令流程
# 1. 当前正在 dev2 上开发
git checkout dev2
# 2. 开发到一半,修改了文件但还没提交
vim README.md
# 3. 突然发现 master 有 bug,先保存当前开发现场
git stash
# 4. 切回 master
git checkout master
# 5. 创建修 bug 分支
git checkout -b fix_bug
# 6. 修 bug
vim README.md
# 7. 提交 bug 修复
git add .
git commit -m "fix bug"
# 8. 切回 master
git checkout master
# 9. 合并 fix_bug 到 master
git merge --no-ff -m "merge fix_bug" fix_bug
# 10. 回到 dev2
git checkout dev2
# 11. 查看 stash
git stash list
# 12. 恢复开发现场
git stash pop
# 13. 继续开发
vim README.md
# 14. 开发完成后提交 dev2
git add .
git commit -m "finish dev2 feature"
# 15. 先让 dev2 合并 master
git merge --no-ff -m "merge master into dev2" master
# 如果有冲突,手动解决后:
git add .
git commit -m "merge master and fix conflicts"
# 16. 切回 master
git checkout master
# 17. 再让 master 合并 dev2
git merge --no-ff -m "merge dev2" dev2
# 18. 删除无用分支
git branch -d fix_bug
git branch -d dev2
更多推荐




所有评论(0)