Git@OSC 新增分支保护功能 : 常规、保护、只读

oschina
 oschina
发布于 2015年01月30日
收藏 8

Git@OSC 新增分支保护功能!

分支保护功能是为了防止相关成员 Push 代码到重要的分支(例如 master 分支),便于项目的分支管理。

Git@OSC 的分支除了之前的常规分支外,新增两种不同的权限:

  • 常规分支:项目成员(开发者权限及以上)可Push分支

  • 保护分支:项目管理员才能管理(Push)被保护的分支。

  • 只读分支:任何人都无法Push代码(包括管理员和所有者),需要Push代码时应设为“常规”或“保护”分支。

只有项目管理员可以管理保护分支,进入项目管理,点击分支保护即可设置各个分支的权限,如下图:

现在就访问 http://git.oschina.net 实地体验。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Git@OSC 新增分支保护功能 : 常规、保护、只读
加载中

最新评论(30

Maxwhale
Maxwhale
为啥这个功能我的账户里看不到呢? 关闭了?
Raphael_goh
Raphael_goh

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?

引用来自“张山疯”的评论

svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。

引用来自“Raphael_goh”的评论

还有一个就是如果master分支配合钩子做了自动发布之类的操作,那是否意味着所有对master的误操作都会直接影响到生产环境。

引用来自“张山疯”的评论

两条一起回复吧:
1,如果需要自动部署,那么git仓库必须存在两个,一个是开发用,一个是自动部署用----你可以把钩子挂在git tag上,或者是向git flow的做法一样专门用个release分支来挂钩子发布。毕竟直接将开发版代码发布到线上属于非常不负责的做法。

2,“git是分布式的,每个开发者都拥有一个完整的仓库副本”。无论团队有多菜的人干了多么惊天动地日事情,只要开发者中还有一个人的版本还建在,一切都可以轻松恢复。觉得有人动了远程master就干掉了一切还是使用了svn的思维方式在作怪。
关于第二点,我只说了是非常麻烦的事情,并没有说干掉了一切。
张山疯
张山疯

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?

引用来自“张山疯”的评论

svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。

引用来自“Raphael_goh”的评论

还有一个就是如果master分支配合钩子做了自动发布之类的操作,那是否意味着所有对master的误操作都会直接影响到生产环境。
两条一起回复吧:
1,如果需要自动部署,那么git仓库必须存在两个,一个是开发用,一个是自动部署用----你可以把钩子挂在git tag上,或者是向git flow的做法一样专门用个release分支来挂钩子发布。毕竟直接将开发版代码发布到线上属于非常不负责的做法。

2,“git是分布式的,每个开发者都拥有一个完整的仓库副本”。无论团队有多菜的人干了多么惊天动地日事情,只要开发者中还有一个人的版本还建在,一切都可以轻松恢复。觉得有人动了远程master就干掉了一切还是使用了svn的思维方式在作怪。
Raphael_goh
Raphael_goh

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?

引用来自“张山疯”的评论

svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。
还有一个就是如果master分支配合钩子做了自动发布之类的操作,那是否意味着所有对master的误操作都会直接影响到生产环境。
Raphael_goh
Raphael_goh

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?

引用来自“张山疯”的评论

svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。
公共项目基于pull request自然用不到这个功能,但私有的团队项目所有人都有权限去动某些分支,我觉得就不好了,至少要锁定master分支。毕竟一旦push到远程仓库,回溯什么的操作就非常麻烦了。

特别是一些刚刚接触git的人,经常会想当然的直接在master分支上进行修改,毕竟大部分人用svn的比较多。
Yashin
Yashin

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?

引用来自“张山疯”的评论

svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。
用户的建议是我们进步的源泉,感谢还来不及哈。说得有理,看来以后我们推这样的功能要对git思维用户要足够透明才行,哈哈
张山疯
张山疯

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。

引用来自“oscfox”的评论

我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?
svn的各种保护机制权限机制,是因为集中式仓库这种脆弱的设计而不得以为之的

git是每人一个副本的分布式设计,从根本上就跟svn不一样。从根本上就用不着svn那些蹩脚的机制。

用git@osc的人很多都是从svn上转过来,如果一开始就不让他们明白这种区别,而是用各种打补丁的形式来迁就用户。
那么结果就两种:
1,svn的迁移过来的用户理所当然的用svn的思维方式来使用git@osc,那么他们只是得到了一个非常蹩脚的svn
2,用管git的用户觉得自己用的是个加了很多奇怪功能的git(osc版)。

嘛,既然osc做了这个功能,想必也是有许多考量的,我只是从一个git日常用户的角度提下自己的看法,别见怪。
思忆迷往
思忆迷往
不用客气,谢谢!
Yashin
Yashin

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。

引用来自“张山疯”的评论

爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。
我们的出发点正是希望限制不同的人对敏感分支的误操作,降低代码管理成本。用户的使用习惯我们只能建议,并且适应。当然你的建议非常好,对git的使用应该用git的思维方式。但是对于’后患无穷‘,我想不到,可否指点一二?
张山疯
张山疯

引用来自“张山疯”的评论

这功能不适合
1,不同的人就应该在不同的分支上开发,如果发生2+同时维护一个分支,那肯定是项目规划和事情的安排上出问题了。

2,即便有人push错分支,git log/reset/可以回溯,即便push :branch,还有本地

3,把git当svn来用是个不良习惯,增加这种所谓的保护机制类似实现了svn的锁,助长了这个坏习惯,非常不应该。

------
如果对git分支规划还有疑问的,可以参考一下这篇文章:
http://nvie.com/posts/a-successful-git-branching-model/
(中文)http://www.oschina.net/translate/a-successful-git-branching-model

引用来自“moli”的评论

如果有良好的git使用习惯,我想不会使用这个功能。
但是呢,我们就是要让不同用户爽。
爽是必须的,但有更适合姿势可以爽,没必要用这种后患无穷的爽法。
返回顶部
顶部