它拥有与GitHub类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
GitLab进入了新的里程碑——GitLab 7.12正式到来。以下为官方发布日志摘译：
这次的发布带来了大量的新特性和修复，主要是面向Community Edition (CE)、Enterprise Edition (EE)和Continuous Integration (CI)。在CE和EE中，GitLab开始支持使用SAML身份验证，这一点曾被广泛要求，我们也非常高兴CERN参与了贡献。在GitLab Enterprise Edition中，你可以邀请多个人来批准某个合并请求。在GitLab CI中，我们推出了.gitlab-ci.yml文件，使得更容易管理job 脚本。
这个月的MVP很好选择，他是来自CERN的Alexandre Lossent，Alexandre 贡献了他们写的SAML代码。我们很高兴有这个贡献，以及确信你会受用。感谢Alexandre!
SAML 支持
由于得到Alexandre的贡献，GitLab现在可以成为一个SAML 2.0 Service Provider。这使得GitLab 以SAML 2.0 Identity Provider(IdP，如Microsoft Active Directory Federation Services)身份来提供一个用户认证机制。
参见如何设置SAML集成的文档。
Web Hook评论
现在有了一个新的可用的Web Hook，它将连接所有的评论。你可以用它来增加额外的自动化和集成至GitLab。例如，当有人评论一个合并请求时，你可以把它连接至内部的系统，或者你可以根据评论内容运行一个特定的构建。
更好的Web Editor性能
每一个GitLab新版本都比过去的更快，但这个版本中，我们做了一些其他的工作。简而言之，不再是通过克隆一个空的仓库至一个临时的位置来执行Web界面代码更改，在那儿提交，然后Push更新回至空的仓库，而是我们现在可以直接提交更改至空仓库。这显著提高了Web Editor的性能。
UI更新
每个月我们都尝试和调整我们的UI，让它变得更好、更美观和更加直观，这个月依然这么做了。
我们已经迁移你的个人资料页，将它链接到底部左下角，以及更新各个UI部分的外观。
Merge Request Approvers(仅支持EE版本)
如果你想确保你最喜爱项目在合并请求前可以有超过一个人的review，在新版本中，你就可以配置一个最低Merge Request批准的数值。
Git Hook来检查Maximum File Size(仅支持EE版本)
我们增加了一个新的Git Hook，允许你限制即将提交的大文件。你可以很简单地设置一个门槛，GitLab 将会阻止所有包含太大文件的Git pushes。
LDAP Group Sync改进(仅支持EE版本)
我们在GitLab EE上改进了LDAP Group同步。当同步时它会检查更多的特殊属性，防止因为同步而删除最后组里的owner。
.gitlab-ci.yml文件替代jobs(CI)
在5月6日，我们用存储在代码仓库中的.gitlab-ci.yml文件替换GitLab CI jobs。优点被列出在公告中，但主要的是：
既然构建脚本是由版本控制的，更多人可以看到它且提出修改建议;
较旧的和较新的分支都可以正确地构建，因为他们能够包含一个不同的构建文件;
Forks自动获得一个正确的构建脚本，当他们向上合并获得更新时;
在没有破坏其他分支的情况下，你可以在你的分支中尝试CI构建设置;
上面的事情不可能用类似Jenkins脚本实现，因为它与整个项目相关联。
它是如何工作
GitLab发送web-hook和.gitlab-ci.yml内容至CI Coordinator，基于YAML文件来创建builds。反过来，这些builds通过Runners来执行。
这里是一个YAML文件例子：
before_script:
- gem install bundler
- bundle install
- bundle exec rake db:create
rspec:
script: "rake spec"
tags:
- ruby
- postgres
only:
- branches
spinach:
script: "rake spinach"
tags:
- ruby
- mysql
except:
- tags
staging:
script: "cap deploy staging"
type: deploy
tags:
- capistrano
- debian
except:
- stable
production:
script:
- cap deploy production
- cap notify
type: deploy
tags:
- capistrano
- debian
only:
- master
- /^deploy-.*$/
我们包含了一个Lint工具来检查你的语法。它现在可以在每一个 GitLab CI中获得，通过url /lint的方式。如果你在push 你的代码后 .gitlab-ci.yml出现问题，你将能够在提交页中看到错误。
before_script 部分将在每一个job前被执行。你可以通过添加type: deploy从而实现定义一个部署job。每个job包含的参数，例如script (shell script)、tags (只有运行这个tag/tags才允许选择这个构建)，以及only或except 参数来定义允许运行构建的分支名称。only 部分优先于 “except”。参见：Configuration of your builds with .gitlab-ci.yml
新版本的灵感来自已经使用YAML文件的Travis CI和Circle CI的工作。首先，我们考虑使用开源的Travis CI模块，但是我们最终还是自己编译了，所以我们可以提供：
定制化的部署jobs;
能够在Metal、VM和Docker images运行jobs;
能够每次在同一个台机器上运行(例如性能测试);
能够运行在特殊的架构上(例如一个Raspberry Pi 2);
能够运行在特殊地方或特定证书的机器上;
支持简单和浅显的YAML文件的语法;
命名jobs，实现轻易地辨别。
因为这些，“one image per architecture and that’s it”不再成立。当你能够tag runners和jobs，这让你在分配一个job给指定的runner时拥有更多的自由。我们希望新版本具有着Jenkins的自由和Travis CI的用户友好。
迁移
当升级到GitLab 7.12，你的CI job脚本将被自动转变成一个示例.gitlab-ci.yml 文件，你可以在GitLab CI项目页查看和下载。
在push引发一个构建后，GitLab会从仓库的根发送.gitlab-ci.yml 文件。如果不存在， GitLab CI 将利用已生成的示例脚本。这意味着你的项目没有更新好。然而，我们建议你尽快添加.gitlab-ci.yml 文件至你的仓库的根。
你应该添加.gitlab-ci.yml 文件至你项目的所有分支中，特别是正进行接受提交中的Git pushes。
BETA: Secret Variables for runner(CI)
我们增加了一个GitLab CI的新功能，允许你面向runners设置私密变量。Secret Variables将通过runner来设置至环境中，且可从构建日志中隐藏。使用它们的密钥、secret keys或者其他任何东西。确保你的runner版本为0.4或更高版本。
目前，此功能处于测试阶段。添加至GitLab CI 7.12 的Secrets被存储在他的SQL数据中，并没有加密。我们将在7.13中进行加密。
其他变化：
此版本有太多的改进，包括安全补丁，所有更新请参见更新日志。
升级要点
此版本仅是微小的迁移，如果你目前使用GitLab 7.11 CE或EE，你直接可以在线升级7.12。
当使用Omnibus 程序包时，更新行为要用‘secret_token’设置。
如果你针对在 /etc/gitlab/gitlab.rb 中的 gitlab_rails['secret_token']、gitlab_shell['secret_token']或 gitlab_ci['secret_token'] 设置一个自定义的值，那么请仔细检查在 gitlab.rb 中的是否值匹配/etc/gitlab/gitlab-secrets.json 中的值。如果一些值不匹配，从gitlab-secrets.json 复制值到此前升级至GitLab 7.12的 gitlab.rb。
在7.12之前，你在 gitlab.rb 中任何的 secret_token 值实际上是忽略了支持所有的gitlab-secrets.json 。
在大多数的GitLab Omnibus安装中，‘secret_token’仅在gitlab-secrets.json 中设置，并且不需要任何的操作。
这个变化仅适用于GitLab Omnibus程序包。从源头的安装不受影响。
更改操作系统初始化的检测
当运行gitlab-ctl reconfigure omnibus-gitlab 时，需要决定系统是否使用SysV初始化、Upstart 或Systemd，再安装gitlab-runsvdir 服务。
在这个版本之前，这个决定是通过观察该平台，操作系统版本和系统默认的初始化是什么来实现。
这是不可靠的，由于omnibus-gitlab被安装在多个OS代码上，导致处理这个变得复杂和易于出错。
从这个版本开始，这样的做法已经被替换了，检测是通过查询OS初始化系统来完成的。基于这个响应gitlab-runsvdir 服务已经被安装了。
如果你偶然遇到一些如omnibus-gitlab README中描述的问题，请尝试使用一些变通方案，并在omnibus-gitlab问题跟踪器汇总提交问题。（文章来自欣才PHP培训http://www.thinksite.cn/）
