你被猪队友的 Git 强制推送坑过吗? - 开源中国社区
你被猪队友的 Git 强制推送坑过吗?
红薯 2018年08月09日

你被猪队友的 Git 强制推送坑过吗?

红薯 红薯 发布于2018年08月09日 收藏 3 评论 37

同样是搞Java,年薪15W和50W到底差在哪里?>>>  

Git 有一个很可怕的特性,就是 -f 参数 —— 强制推送,强行用本地仓库覆盖远端仓库。导致的后果就是文件可能被老的内容给覆盖掉,仓库的历史提交记录丢失等等。

进行强制推送一般是出现在仓库版本冲突的情况下,在团队协同开发中,很多开发者为了省事,直接不负责任的使用 -f 推送,悲剧就这样发生了。

正常的流程就是想办法解决冲突,再行推送。

可是谁身边又没有几个猪队友呢?

----- 以下是广告时间 -----

我们刚为码云企业版客户上线了限制仓库强制推送的功能,从仓库的管理页面中,可以选择“禁止强制推送”。

一旦禁用了强制推送后,如果开发者在推送冲突时使用 -f 参数,就会报如下错误:

denying non-fast-forward refs/heads/master (you should pull first)

该功能目前只对企业客户开放、默认不启用,需要手工开启。

当然我们更建议大家使用 fork + pull requests 进行协作开发,或者设置主分支只读,然后通过 pull requests 进行代码合并。

即刻前往体验码云企业版 https://gitee.com/enterprises

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:你被猪队友的 Git 强制推送坑过吗?
分享
评论(37)
精彩评论
19
强制推送不是最坑的,而且这个是能禁掉的。最坑的是合并代码有冲突的时候,只提交了自己修改的几个文件,最终其他人之前的修改被回滚了。
7
不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。
7
谁敢强制推送,就把谁拿来祭天。
5

引用来自“宇润”的评论

电脑上看评论有很重的延迟啊。。而且新的电脑样式,看起来好小气。。。就中间一小坨
同意,今天改!
2
电脑上看评论有很重的延迟啊。。而且新的电脑样式,看起来好小气。。。就中间一小坨
最新评论
0

引用来自“久永”的评论

不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。

引用来自“衷于栖”的评论

其实每个人拥有自己的分支,我觉得已经把git当svn用了;项目经理管理master合并的话,会很浪费时间。而且有点大材小用了。

引用来自“久永”的评论

看我最新回复。我说的是对于代码管理理解层次上的。你说的是具体操作层次上的。项目经理用来把控全局的,只有他能决定什么实现是正确的。他负责选提交,不是帮每个人把代码合上去。那是每个人自己要做的事。
估计这里很多人都是用的“合并”连“衍合”都没怎么用过。
分支之间的重叠是因为代码或者业务重叠引起的,每个人一个分支很容易造成这种重叠,特别是开发环境相关的配置,所以一般情况下我都是通过特性去管理分支的,一般不会出现重叠的情况;另外关于项目经理,我也同意你之后的看法,我们的做法是在评审会上,项目经理审核开发代码,并及时给出原因。实际上是谁开发谁去合并代码,并保证代码的正确。虽然提交并合并了,但是与主分支之间是否合并还是需要项目经理进行评审。pull request模式,或者是gitlib的ticket模式我觉得都是比较不错的方案。
0
用git flow方式开发,没有这种问题
0

引用来自“早乙女由依”的评论

我用过强制推送,好几次,我把主线的合并到自己分支,结果说这个主线不要了,不得不回滚强推

引用来自“久永”的评论

说明你们的管理中,不知道什么叫“主线”。

引用来自“早乙女由依”的评论

我们是master-develop-当前月分支,拉了这个月的分支做主线,有些一级需求小伙伴们就直接在这个分支开发,我再拉分支作为自己功能开发分支,每天工作结束,拉这个主线上的代码合并到我的分支,解决解决冲突什么的,免得最后我往主线合并冲突多,结果总有干着干着产品说,这个月的一级需求不做了,但是我的功能需求还要.......
你门这样可能是沿袭svn的管理方式。
个人觉得这种方式分起来太轻率容易,
功能要合起来代价就大了。
因此导致你说的那种情况,
恶劣的时候可能是冲突的,根本没法合并。
0
我最爱的命令之一
0

引用来自“早乙女由依”的评论

我用过强制推送,好几次,我把主线的合并到自己分支,结果说这个主线不要了,不得不回滚强推

引用来自“久永”的评论

说明你们的管理中,不知道什么叫“主线”。
我们是master-develop-当前月分支,拉了这个月的分支做主线,有些一级需求小伙伴们就直接在这个分支开发,我再拉分支作为自己功能开发分支,每天工作结束,拉这个主线上的代码合并到我的分支,解决解决冲突什么的,免得最后我往主线合并冲突多,结果总有干着干着产品说,这个月的一级需求不做了,但是我的功能需求还要.......
1
强推的场景:
有两个功能分别是:
feature A
feature B

它们经过长时间的研发后终于到了集成的日子,都合并到了 intergration 分支,马上要到了发布的日子。这个时候却发现 A 存在天大的漏洞,而且没有办法在短时间内进行修复,怎么办?

这时候,你只能选择回滚,回滚给我们带来什么,要强推。

所以,强推这个功能还是没有办法省去的,可能一万次有那么一次,关键在回滚时你和团队一定要达成一致,处于一个水平线。
0
被坑过不止一次!
0

引用来自“久永”的评论

不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。
咱们得管理模式一致
0
我强制推送过,因为又一次提交了本不该合并的分支,为了退回,本地force reset 后,force push
0
猝不及防
0

引用来自“老大哥”的评论

谁敢强制推送,就把谁拿来祭天。

引用来自“久永”的评论

如果都不用这个功能,干嘛还要这个功能?
所以 @红薯 帮忙,帮你们干脆开发了这个功能。
还不赶快感谢下大大?
PS:再吐糟下回复功能,既然不能很快的连续回复,干嘛回复完了回复框还要自己手动关闭?
知道啦,评论方式我们改!
0

引用来自“老大哥”的评论

谁敢强制推送,就把谁拿来祭天。
如果都不用这个功能,干嘛还要这个功能?
所以 @红薯 帮忙,帮你们干脆开发了这个功能。
还不赶快感谢下大大?
PS:再吐糟下回复功能,既然不能很快的连续回复,干嘛回复完了回复框还要自己手动关闭?
0

引用来自“unrealt84”的评论

强制推送不是最坑的,而且这个是能禁掉的。最坑的是合并代码有冲突的时候,只提交了自己修改的几个文件,最终其他人之前的修改被回滚了。
改动别人代码,你们都不沟通下的?
你们的团队是完全冷漠没法沟通,
还是太默契以至于不需要沟通?
0

引用来自“久永”的评论

不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。

引用来自“衷于栖”的评论

其实每个人拥有自己的分支,我觉得已经把git当svn用了;项目经理管理master合并的话,会很浪费时间。而且有点大材小用了。
看我最新回复。我说的是对于代码管理理解层次上的。你说的是具体操作层次上的。项目经理用来把控全局的,只有他能决定什么实现是正确的。他负责选提交,不是帮每个人把代码合上去。那是每个人自己要做的事。
估计这里很多人都是用的“合并”连“衍合”都没怎么用过。
0

引用来自“早乙女由依”的评论

我用过强制推送,好几次,我把主线的合并到自己分支,结果说这个主线不要了,不得不回滚强推
说明你们的管理中,不知道什么叫“主线”。
0

引用来自“久永”的评论

不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。

引用来自“Minho”的评论

你这样容易产生冲突。冲突了你是项目经理来处理还是开发处理呢?如果是经理来处理可能会处理不好,如果是开发,可能会把别人的修改给回滚了。

引用来自“Raphael_goh”的评论

把merge request设置为,不允许合并落后提交就行了。每次merge前,开发自己rebase一下,冲突自己解决,基本不会有什么问题。
是的,我就是这么要求的。项目经理(应该是组长)只是负责整体上评审代码,可用就选为主线提交。不可用就告知本人重写提交。如果两个人有冲突,互相确认解决(改动别人代码要求告知)。
PS:吐糟下新回复样式,这样一个弹窗,还能不能好好的让我看别人说了什么回复了啊? @红薯
0
我用过强制推送,好几次,我把主线的合并到自己分支,结果说这个主线不要了,不得不回滚强推
0

引用来自“久永”的评论

不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。

引用来自“Minho”的评论

你这样容易产生冲突。冲突了你是项目经理来处理还是开发处理呢?如果是经理来处理可能会处理不好,如果是开发,可能会把别人的修改给回滚了。
把merge request设置为,不允许合并落后提交就行了。每次merge前,开发自己rebase一下,冲突自己解决,基本不会有什么问题。
0
我就喜欢强推 , 怎么啦
0
你见过自己把代码从本地仓库复制出去开发,然后更新本地库,把代码复制回来,然后提交的么...
顶部