如何用 git 折磨同事

·  阅读 8017

merge 代码的正确姿势

前情铺垫

这里就不讲 gitflow 的问题了,最最简单的场景,同事A 和 B,协同开发,假设分支名是 feature。两人共同在 feature 上提交代码。

初始化

B 君开了个分支,写了一行B代码

B 君告知A,请求代码合并到公共分支上

A 一堆操作猛如虎

git checkout feature
git merge -s ours func_b
复制代码

通知B君,我合并你代码了。

这时候 B 君一看,我代码咋没了

😠 demo git:(feature) cat code
😠 demo git:(feature) 
复制代码

再看一下 git log

😠 demo git:(feature) git log --oneline --decorate --graph
*   846f001 (HEAD -> feature) Merge branch 'func_b' into feature
|\\
| * 93972fb (func_b) code by b
|/
* 1c2b405 init
复制代码

没毛病,提交已经合并了。

要不自己再合一下?

😡 demo git:(feature) git merge func_b
Already up to date.
复制代码

完犊子,git 认为已经合并过了 ,不做处理。🤬

原理

我们合并代码时候,是可以指定合并策略的。recursive 是默认的。

  • resolve
  • recursive
  • octopus
  • ours
  • subtree

划重点,ours 策略,即合并时候,不管别人做了什么,以我分支上的提交为主,丢弃掉别人的变动。

对此 ,我们可以有很多操作坑队友

$ git merge --strategy=ours origin/master  # 合并主干代码,但丢弃主干变动
$ git pull -s ours # 拉取远程代码,并丢弃队友push的代码
复制代码

结尾

为啥我会看这些?因为我特么是被坑的那个🤬。不晓得同事的git GUI工具咋配置的能干出这种事🤬

由于太气了,所以不能好好介绍上述其他策略了,详见大佬文章

git 合并策略

个人博客原文地址

分类:
前端
标签:
分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改