2011-11-03 22 views
1

有一些存储库(每次-indepndent模块方式)在Gitosis的GIT中:禁止对意外强制合并测试到主

两个分支:主(产量从该分支接收更新)和测试

  • 任务:每库否认试图搞砸了master分支: 禁止推测试到主合并

  • 情况:最近从SVN迁移到Git的

大家有本地克隆,并为每一个错误

他将其合并到测试(我们的集成分支)的本地分支,那么,如果质量检查小组批准,部署(并入主机和推)

没有太多的人力,就像每谁知道那里发生了仓库

一个最活跃的人 - 他是一个git的新手,像我

我们需要中央集成分支准备尽快使用生产部门,但无法承担单独的人只是为了做这种整合。

人谁写的代码负责合并成测试和测试上的另一完成的,集成的web应用实例(从开发商mashine不同)

  • 进球后部署:从这个主要开发螺钉UPS保护

我想到写检测裁判被推向

,看起来牛逼的更新挂钩推提交的hrough消息

https://gist.github.com/23b807f29c37c5699670

是啊,这是丑陋的

一些开发商从他们的克隆手动推,有些不

也许我应该确保每个人都使用部署脚本需要任务分支名称和显示列表,然后将其合并到主设备中并推送它


任何想法

  • 禁止合并通过钩在中央存储库中测试进入主

  • 在开发mashine通过钩禁止合并检测到主

+1

考虑转向gitolite,因为gitosis不再积极开发。以同样的方式工作,但您可以获得新功能的好处,并且可以为当前版本的Git提供良好的支持。 –

回答

1

如果每个人都推到一个中央仓库,你会得到非分布式版本系统的大部分问题。

这样做的分布式方式是:让只有你信任的人(例如你和Linus等)才能写入“规范”存储库。让所有其他用户都拥有自己的公共镜像(只有他们可以推送到,并且每个人都可以从中获得)的信任用户可以从中获得回报,然后推入规范回购。问题解决了。

+0

查看更新的问题。正确的做法是将每个模块(回购)首席开发人员都转换成Linus,并以git专业知识为依据。同时,我应该让每个人都使用相同的部署脚本,并建立一些界限来禁止显而易见的错误(这是发生的第二次) – jonny

0

我只会在中央存储库上限制它。如果当地需要的话,本地开发可以随着冲刺推动并推向不同的分支。

你在挂钩中缺少的是检查用户。添加这个以确保/ someone /可以推送给主人。

或者,制作另一个回购站,只给自己和任何其他人通过修改配置书写访问权限。这根本不需要你使用钩子。