浅谈 Git 架构和如何防止代码笼罩的事变
Git 不同于 SVN 的中央在于, Git 是分布式的版本管理系统, 所有的客户端和服务器都保留了一份代码, 波及到仓库仓之间的同步, 所以处理不当极易造成抵触
最间接的办法就是不让老手合并代码
- PR 开发: GitHub 开源我的项目罕用开发方式, 开发者在本人的 仓库 上开发, 实现后提交 PR 给管理员审核合并
- MR 开发: 对代码要求比拟严格的公司罕用开发方式, 开发者在本人的 分支 上开发, 实现后提交 MR 给管理员审核合并
然而这样每次都要等管理员审核, 不适宜麻利开发的个别团队, 所以 Git 的学习和应用是必不可少的
Git 架构
分布式的版本库
Git 本地仓库
Git 本地仓库 + stash 储藏区
- 应用
git stash
能够将 工作区和暂存区批改的文件 挪动到储藏区, 通常在本地存在不想提交的临时文件的时候 pull 之前应用 - 应用
git stash pop
能够将储藏区的文件复原到 工作区和暂存区 , 通常在提交之后应用
Git 本地仓库 + stash 储藏区 + 近程仓库
常用命令
上面只是介绍下常见的开发命令, 其余命令能够参考 Git 官网文档: https://git-scm.com/docs
共享分支开发
# 增加到暂存区
git add a.txt
# commit 本地仓库
git commit -m "新增 a.txt"
# 同步近程仓库
git pull origin master:master
# 推送到近程仓库
git push origin master:maser
非共享分支开发
提交到本人的近程分支, 而后提交 MR 合并到 master 分支
# 新建集体开发分支 dev_d
git branch dev_d
# 切换到集体开发分支 dev_d
git checkout dev_d
# 批改代码
# 增加到暂存区
git add a.txt
# commit 本地仓库
git commit -m "新增 a.txt"
# 同步近程仓库 master 正本并 merge 到 dev_d 分支
git pull origin master:master
# 推送本地 dev_d 分支到近程 dev_d 分支
git push origin dev_d:dev_d
在 GitLab 等平台创立 PR 合并 dev_d 到 master 分支, 而后让管理员审核
本地存在不想提交的临时文件
# 将不想提交的代码 stash 到储藏区
git stash save "长期配置文件 a.yaml"
# 同步近程仓库 master 正本并 merge 到 dev_d 分支
git pull origin master:master
# 推送到近程仓库
git push origin master:maser
# 将临时储藏的文件复原
git stash pop
什么时候会产生代码抵触
Git 有 2 种状况会产生代码抵触
- 两个人同时批改了同一个文件的同一行 (比方 张三, 李四同时批改了 a.txt 文件的第一行)
- 批改文件的时候文件名被其他人批改了 (比方 张三批改了 a.txt 文件的第一行, 李四将 a.txt 文件批改为 b.txt( 或者删除))
批改了同一个文件的同一行
上面展现一下代码抵触的过程
- 张三创立 a.txt 并且在第一行写入 1, commit 到本地仓库, push 推送到近程
- 李四将同步代码后, 将第一行的 1 批改为 2, commit 到本地仓库, push 到近程
- 张三将第一行批改为 3, commit 到本地, push 到近程
- 张三代码抵触, 回绝 push
$ git push
To github.com:dengjiawen8955/git-demo.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:dengjiawen8955/git-demo.git'
- 张三 pull 近程代码, 因为代码抵触, 不能主动 Merge
$ git pull
Auto-merging 0928_2/a.txt
CONFLICT (content): Merge conflict in 0928_2/a.txt
Automatic merge failed; fix conflicts and then commit the result.
- 张三手动解决抵触, 能够手动编辑抵触的文件或者应用相干可视化工具
# 查看抵触文件
$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: a.txt
no changes added to commit (use "git add" and/or "git commit -a")
# 解决抵触 (留神, 代码笼罩事变就是在这里产生, 抵触解决笼罩了李四的代码)
$ vim a.txt
# 将解决完的文件增加到暂存区
$ git add a.txt
# 提交到本地仓库
$ git commit -m "解决抵触"
# 推送到近程
$ git push
如果原本 李四提交的代码 2 和 张三提交的代码 3 都应该保留的, 张三却没有保留李四的代码, 那么就会产生代码笼罩事变
正确的后果
2
3
张三合并后的后果
3
批改文件的时候文件名被其他人批改了
原理是相似的, 这里不做赘述了
如何缩小失误?
- 理解 Git 的工作原理和根本命令, 知其然知其所以然, 就能缩小失误
- 及时提交代码, 更新代码, 防止因为长时间没有同步代码产生过多的抵触文件, 因为在解决抵触的时候高级人员是非常容易出错的
- 相熟 Git 工具, 比方命令行或 GitTortoise, 防止因为工具不相熟导致失误
- 本地批改前应该尽可能的防止本地库与近程之间有过多的差别, 本地批改前执行一次 git pull 先把近程更新拉到本地
-
pull 之前如果有没有提交的文件, 先 stash
git stash git pull git stash pop 如果有抵触解决抵触
呈现了代码抵触事变应该怎么做?
如果事变曾经产生了, 首先应该查看日志剖析起因, 找到出问题的节点撤销操作, 回滚代码
查看日志剖析起因
应用命令行或者你相熟的工具查看分支历史
命令行
#log --graph 联合应用时尤其有用,这个选项增加了一些 ASCII 字符串来形象地展现你的分支、合并历史
$ git log --pretty=format:"%h %s" --graph
* f3b92cb 解决抵触
|\
| * 3543686 a.txt 第一行批改为 3
* | 251b3cb a.txt 第一行批改为 2
|/
* 6a432b2 a.txt 第一行新增 1
# 应用 git diff 查看批改历史 (找出出问题的节点)
$ git diff f3b92cb 3543686
应用其余工具能够更加不便的可视化查看, 这里不赘述了
找到出问题的节点撤销操作
参考: https://blog.csdn.net/jarvan5…
总结
如果明天的内容你只能记住一件事, 那请记住: 相熟 Git 工具, 比方命令行或 IDE, 防止因为工具不相熟导致失误
reference
https://blog.csdn.net/qq_2738…
https://git-scm.com/docs
本文由 mdnice 多平台公布