Hello everyone, if you are not in the know, we started publishing translations of GitLab's release articles.
If you missed the previous ones, here are the links: 8.10 , 8.9 , 8.8

GitLab releases releases on the 22nd of every month.
The translation of the post about release 8.11 is in progress, but for now I am submitting to your court another article from the GitLab blog about the difference in terminology between GitLab, GitHub and Bitbucket.

Depending on the work tasks and customer needs, developers have to use different repository management platforms. A typical developer participates in some open source project on GitHub, and at work hosts a project of one client on GitLab, and the other on Mercurial and Bitbucket. Switching between platforms is complicated by the fact that in them the same things can be called completely differently. In this article, we will help you compare the differences and at the same time explain why we chose these names.

Starting with version 8.4 , GitLab has significantly improved the process of repository migration from GitHub. Now GitLab imports not only repositories, but also wiki pages, tickets and pull requests. However, most entities do not change their name. For example, specific Git terms such as commit or push are the same everywhere. General terms such as users, webhooks and issues do not change.

But some terms are still different. For example, the fact that in GitHub and Bitbucket called pull-rekvest (pull-request), we call merzh-rekvest (merge-request). We called it that because it is a request for mergebranches for a feature branch with a master branch; actually the team pullis not used anywhere. By the way, Git has a separate team request-pull: it also allows you to propose your changes and uses the same command pull, but it has a completely different mechanism .

If you are just starting out with GitLab, this table will help you get started faster:

Teams, Repositories and Organizations

Let's see how the team (team), repository (repository) and organization (organization) differ . GitHub repositories contain the actual Git or SVN repository, as well as issues, participation statistics, etc. At the same time, users often call repositories projects.

In GitLab, we disambiguated by explicitly calling such a structure a project . The project includes a Git repository, tickets, merge requests and everything else. On the project configuration page, you can:

• Select features used.
• Set project avatar.
• Set the project visibility level: public, internal (for authorized users) or private (only for group members).
• Move, archive or delete a project.
• Configure the use of Gitlab CI in the project.
• Add services to integrate the project with third-party applications.

It’s important to understand that even if you import into GitLab only a clean Git repository or something that is called a “repository” in the source, you will always get a GitLab project as a result.

An important difference: in Bitbucket, a project is a combination of several repositories. Such projects, in turn, belong to teams . In GitHub, organizations perform a similar task .

In GitLab, such structures that combine several projects are called groups . Users included in the group get access to read, modify and configure projects depending on their role in the group. Each project belongs to only one group, but it can be “shared” for other groups. This feature has been in Gitlab Enterprise Edition, as well as in GitLab Community Edition since version 8.5 . If you want to explicitly prohibit sharing projects, this can be done in the group settings.

Hope this article has helped you better understand terminology. If you still have questions, ask them in the comments.

Translator: nick_volynkin