发布于 2016-02-04 05:52:19 | 154 次阅读 | 评论: 0 | 来源: 网友投递

这里有新鲜出炉的精品教程,程序狗速度看过来!

GitLab项目管理和代码托管平台

GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具,并在此基础上搭建起来的web服务。


前几日,GitHub 上一些流行的开源项目维护者联合签署了一篇名为“亲爱的,GitHub”的公开信,表达了对 GitHub 某些行为的不满之情。

接下来,GitLab 官方也发出了自己的声音。他们在自己的博客上表达了希望 GitLab 成为任何软件项目的最佳托管场所的愿景,无论开源与否,无论项目规模是怎样的,他们都希望 GitLab 能在这个过程中助广大开发者一臂之力。

GitLab 官方表示,虽然 GitHub 开源社区联合签署的公开信并不是针对于自己,但他们还是对这封公开信中所提及的问题进行了深入的思考。最后,GitLab 希望能与广大开发者分享他们的一些想法,以及为了让 GitLab 变得更好而做出的努力。

主要的问题

在 记录 Issue 时常常会丢掉诸如重现步骤或是测试的版本等相关的重要信息。我们希望 Issue 能够拥有一些自定义字段,同时还能提供一种机制(比如说强制性的 Issue 模板,这也许可以通过在项目根目录下的 newissue.md 文件来实现,这也是个简单的解决方案)来确保每个 Issue 都能如此。

在 GitLab 中,你可以对 Issue 与合并请求设定模板。我们还计划添加多个模板,这样使用者就可以根据需要进行选择了。此外,GitLab 还对自定义字段表示出了兴趣。对于模板使用 new_issue.md 文件是个好想法,我们也很乐意讨论这个问题。

Issue 通常伴随着毫无内容的“+1”评论,这只会不断困扰项目维护者以及其他订阅了这个 Issue 的人。这些 +1 对于让维护者知晓这个 Issue 的影响范围有多么广是很有意义的,不过其缺点也是显而易见的。我们希望 Issue 能有一个不错的投票系统,对于那些诸如“+1”或是“me too”等无内容的评论会触发一个警告,并给出相应的指示告诉大家该如何使用投票机制。

GitLab 目前有一个投票系统,它会自动将 +1 转换为一个投票。在我们自己使用 GitLab 作为问题追踪或是特性投票功能时,这对于我们来说是个优先级很高的事情。我们还计划对投票进行一些改进,这里也欢迎大家提出更多有价值的想法以及合并请求。

很 多时候,人们在创建 Issue 与 Pull Request 时并未遵守 CONTRIBUTING.md 贡献指南,这是由于在创建 Issue 时,“贡献指南”并不起眼所导致的,同时也与该指南包含了大量与 Issue 并不相关的信息有关(比如说关于如何 Hack 项目的信息等)。维护者应该能在仓库中配置一个文件,该文件显示在新的 Issue/PR 页面的顶层位置而不是一个链接的形式。维护者可以选择在里面插入内容,当然也可以在必要时使用指向其他页面的链接。

目前,我们提供了对 CONTRIBUTING.md 的链接,你可以在创建 Issue 与合并请求时使用。还可以使用 Issue 模板告知人们具体的规则。我们对于在 GitLab 中为 Issue 添加自定义的贡献文件很感兴趣。

对于具体建议的响应

在“亲爱的,GitHub”的公开信中包含了长长的建议列表。若想了解我们对于每个建议的回应,请在 GitLab.com 上查看。其中有一个 Issue 被反复提起多次,那就是无法创建合并提交。在 GitLab 中,你可以使用快进合并或是对合并请求进行变基来间接实现合并提交。

我们是如何构建 GitLab 的

GitLab 的构建是开放的。我们对 GitLab 变化的决策、疑虑、争论与新特性等等都可以在我们的仓库中看到(主要是 GitLab CE 与 GitLab EE)。每个人都可以自由地提交、创建新 Issue、投票以及对 GitLab 的开发做出贡献。我们有着短期与长期的目标,这些目标都可以在仓库的 Issue 中与网站的页面上看到。如果想要改变某些东西,请创建 Issue 或是提交合并请求。你可以选择自己实现,也可以让其他人帮你做。好的想法总会得到人们的关注。

GitLab 的这份声明发出后,很快就在国外各大社区中引起了人们的广泛关注,也有很多人表达了自己的看法。

Mdw 说到:

我 最近在 GitLab 上创建了一个 iOS App,GitLab 的工程师的表现让我感到震惊,他们很快就对我所提交的 Issue 作出了响应,并且每次发布时都改进了 API,我真的没有想到他们能做到如此之好的程度。GitLab 有一点做得特别好,那就是每个月的 22 号都会有一个发布,因此你可以进行持续的改进。如果你认为 GitLab 不适合于你的开源项目,那你也可以在其 Issue 追踪器上与 GitLab 团队好好聊聊,问题很快就会得到解决!

lexicality 说到:

在 过去一年多的时间内,我们一直在组织内部使用 GitLab CE。我们需要一个 on-premises 解决方案,这是公司的策略所决定的。到目前为止,体验是非常棒的。在 EE 中,我们所需要的一切都在,我们最终也选择了 EE。我们还有专门的 dev-ops。此外,EE 的价格相比于 GitHub Enterprise 来说也是很给力的。从我个人角度来说,我认为 GitLab 做得非常不错。

akerro 说到:

我 所在的公司有将近 300 名开发者,准备在未来的几个月内迁移到 GitLab 上。今天,公司的 CTO/PM 向我们分享了他们对于 GitLab 的看法,他们觉得我们的做法是非常正确的。我是 GitLab 的老用户了,使用 GitLab 也有好几年的时间。从我个人的角度来说,我喜欢 GitLab 要胜于 GitHub,其中一个重要的原因就是我担心 GitHub 有太多的项目,对 OSS 控制得过多。此外,我也不喜欢他们的 CoS。GitLab,好运,我看好你!

关于 GitLab

GitLab 包括 Git 仓库管理、代码审查、问题跟踪、Wiki 等功能。GitLab 搭配 GitLab CI,能更简单地实现持续集成和自动部署。目前的 GitLab 提供了社区版(CE)与企业版(EE)。社区版可从网络免费下载并且是开源产品,它出自一个由 700 多人组成的社区。企业版提供订阅服务,并且更深层次地集成了 LDAP/AD、Jira 与 Jenkins 等。



最新网友评论  共有(0)条评论 发布评论 返回顶部

Copyright © 2007-2017 PHPERZ.COM All Rights Reserved   冀ICP备14009818号  版权声明  广告服务