问一下各位码工码婆

git problem：楼主commit到公共branch 的code，被其他同事做另一个feature的时候overwrite了 （应该是操作失误，做feature前没有fetch pull最新的版本。不是故意的） 。
两个版本公共branch history都有。
那么问题来了，公序良俗的角度， 咱就是说。。。。。应该是楼主还是应该同事B来在git上面解决这个问题呢？

这么菜的同事都把别人code overwrite了，敢让对方继续修吗？😂 放心一点的话自己修

B, but B is so 菜 so eventually u may still need to fix yourself.

奇怪 居然没有PR 直接push to master

理论上谁break的谁修。 如果你们都在feature branch上， 感觉你修比较容易。 如果在master 或者 main/develop/trunk branch, 你们应该设置禁止 git push -f

是他的错，跟他打个招呼让他改就行了。

这个需要是b修，你管他菜不菜，都应该让他修了让你review code，你只用看结果。这次他不修，以后都是你

贵司的流程有问题……

谁更厉害谁fix。但要告知B以后谨慎点。

ping他，看他同不同意先revert他的master commit

b修 谁的问题谁来修 修不好或出问题了他来担责

回复 8楼kingcythia的帖子
是啊，居然可以直接push to public…

应该b修但是他修得了么。

他修但是你要verify一下

没有rebase 的merge 能成功吗？
如何行数比较多，你可以直接revert 他的 commit, 然后告诉他自己fix. 你也可以让他自己revert 自己的commit 。
如果行数少，怎么办都行。

哈哈哈，作为菜鸟入行的时候我也干过这事，人家让我修，可是我真的不会，他只好自己修了。修完还给我科普了一下git的原理，教授了一些小技巧，好人啊。

谁pr的呢？

一般来说， 先无脑 revert bad diff. PR? 感觉很奇怪阿， 俺老马工了， 很少用 PR 这个词。

这也太菜了
ask him to create a revert PR, and revert his merge
then re-open his old PR, resolve merge conflicts, and you need to review and approve it
btw, when you have devs so junior, you guys need to implement git hooks to require senior level approvals before merging

没有test吗

谁更厉害谁fix。但要告知B以后谨慎点。
Yolo 发表于 2022-06-16 16:15

同意。如果对方是新手，楼主和他一起做比较好。

我的理解是lz 的commit 已经被覆盖了。 所以B就算是revert了他的commit， lz 还是没有办法直接merge，还是要 git co master git pull git merge feature git push
当然你也可以在第三步forward merge ，merge --squash 或者rebase。
然后B还要把上述的步骤再做一遍， 还不如lz 自己修算了。

我的理解是lz 的commit 已经被覆盖了。 所以B就算是revert了他的commit， lz 还是没有办法直接merge，还是要 git co master git pull git merge feature git push
当然你也可以在第三步forward merge ，merge --squash 或者rebase。
然后B还要把上述的步骤再做一遍， 还不如lz 自己修算了。


ted.hanks 发表于 2022-06-16 17:24

revert 大部分是 work 的。 当然， 有时 revert 也会有 conflict.

这也太菜了
ask him to create a revert PR, and revert his merge
then re-open his old PR, resolve merge conflicts, and you need to review and approve it
btw, when you have devs so junior, you guys need to implement git hooks to require senior level approvals before merging
纷纷大土豆 发表于 2022-06-16 17:18

这个是正解。

这个是正解。
gokgs 发表于 2022-06-16 17:44

Lot 如果我们这里有菜鸡竟然不会resolve merge conflicts, 肯定有人会在slack channel 里@他一下。。。让他revert

Lot 如果我们这里有菜鸡竟然不会resolve merge conflicts, 肯定有人会在slack channel 里@他一下。。。让他revert


纷纷大土豆 发表于 2022-06-16 17:51

revert conflict 很麻烦的，尤其是如果没有好的 tool, 只能命令行改，我我经常也会搞晕，所以只能特别小心。

revert conflict 很麻烦的，尤其是如果没有好的 tool, 只能命令行改，我我经常也会搞晕，所以只能特别小心。
gokgs 发表于 2022-06-16 17:58

or check out a previous commit and force push 😂😂
Resolve conflicts 这种烂摊子没人爱干

不经过review就被上去了？

不经过review就被上去了？
Yourdad 发表于 2022-06-17 14:27

大概率是 merge 的时候 conflict 搞混了， review 的人也没 catch 到。
所以先 backout 是正解。

回复 1楼helenh的帖子
当然是同事的问题。
每次提交前，要先pull一下，看有没有更新的commit，merge有conflicts要修好，在push上去。

回复 18楼gokgs的帖子
GitHub都用PR，你如果不怎么做开源项目，确实不会用到这个。

回复 22楼ted.hanks的帖子
squash一般是多个commits合起来提交，给人code review用的。一般谁都不会用这个。
lz这情况，共同工作人数少，直接merge，fix conflicts。如果人多，就用rebase。

在大公司，一般TL handles all code management.

难道不是先revert吗？况且这公司的流程一定是有问题的，竟然可以允许这样的事发生，还没有code review

回复 1楼helenh的帖子
有没有instagram 工作的小伙伴？听说你们只有master branch. 大家都直接在master 上面实操

回复 1楼helenh的帖子
垃圾堆吗谁都可以merge

一般来说， 先无脑 revert bad diff. PR? 感觉很奇怪阿， 俺老马工了， 很少用 PR 这个词。
gokgs 发表于 2022-06-16 17:08

不是新老问题，你只在脸家干过吧？ PR- Amazon CL-Google Diff-Meta

不是新老问题，你只在脸家干过吧？ PR- Amazon CL-Google Diff-Meta
smartlhc 发表于 2022-06-17 21:45

哈哈， 世界上好像只有这三家公司？

啥意思，PR的时候不就会直接告诉你有conflicts不然不能merge么。

设施master branch 不能 push 必须通过PR 同时限制 git push -f。这样你可以简单revert 他的commit。让他pull latest 再在上面改。