关于后端:浅谈Git架构和如何避免代码覆盖的事故

浅谈 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

批改文件的时候文件名被其他人批改了

原理是相似的, 这里不做赘述了

如何缩小失误?

1. 理解 Git 的工作原理和根本命令, 知其然知其所以然, 就能缩小失误
2. 及时提交代码, 更新代码, 防止因为长时间没有同步代码产生过多的抵触文件, 因为在解决抵触的时候高级人员是非常容易出错的
3. 相熟 Git 工具, 比方命令行或 GitTortoise, 防止因为工具不相熟导致失误
4. 本地批改前应该尽可能的防止本地库与近程之间有过多的差别, 本地批改前执行一次 git pull 先把近程更新拉到本地

5. 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 多平台公布