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

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

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 强制推送坑过吗?
加载中

精彩评论

u
unrealt84
强制推送不是最坑的,而且这个是能禁掉的。最坑的是合并代码有冲突的时候,只提交了自己修改的几个文件,最终其他人之前的修改被回滚了。
久永
久永
不控制当然会出现非常多的这样的情况。
因此我制定的管理策略是:
1,每个人拥有自己的分支,特别是刚用git的新手。
2,项目经理负责此项目的主分支。其它人随时负责将自己的分支衍合到最新的主分支上。
3,主分支除非错误提交(比如将密码或者将数据文件等不应在历史中出现的内容提交了),否则不允许强推。
PS:我不知道为什么那么多人要把git当svn的方式用,简直是在侮辱神器。
老大哥
老大哥
谁敢强制推送,就把谁拿来祭天。
红薯
红薯

引用来自“宇润”的评论

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

最新评论(37

衷于栖
衷于栖

引用来自“久永”的评论

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

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

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

引用来自“久永”的评论

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

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

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

引用来自“久永”的评论

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

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

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

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

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

引用来自“久永”的评论

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

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

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

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

引用来自“久永”的评论

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