What are the differences between gitlab team and gitlab group?

Question

I\'m using Gitlab 5.0 to manage my git repositories and I\'ve never used github before Gitlab.

When I create a group, I see a new directory with this group name in /

Answer 1

GitLab 6.0 (August 2013, 22d)

See commit 3bc4845:

Feature: Replace teams with group membership

We introduce group membership in 6.0 as a replacement for teams.
The old combination of groups and teams was confusing for a lot of people.
And when the members of a team where changed, this wasn't reflected in the project permissions.

In GitLab 6.0 you will be able to add members to a group with a permission level for each member.
These group members will have access to the projects in that group.
Any changes to group members will immediately be reflected in the project permissions.
You can even have multiple owners for a group, greatly simplifying administration.

---

Why do references to Teams still exist in GitLab 7 then? e.g. "Filter by Team"

• "Team" seems now (GitLab 6.x->7.x 2015) seems limited to a project (see for example features/project/team_management.feature, and app/models/project_team.rb or spec/models/project_team_spec.rb).
  A project can be part of a group: see "Gitlab API for all projects under group".

• "Group" references users, and can group multiple projects, (See features/groups.feature, app/models/group.rb, app/models/members/group_member.rb)

As a user, you are a first a member of a group, and have roles ('Reporter', 'Developer', ...) associated to a project (which makes you a member of that project, part of the "team" for that project).
No role, means "not a member of the team for a project".
See db/migrate/20140914145549_migrate_to_new_members_model.rb.

---

Answer for GitLab 5.x (before August 2013, 22d)

• Group is for grouping projects, similar to a folder (git repositories)
• Team is for grouping resources (people)

Those notions have been refined in GitLab 4.2.

That allows you to manage authorization in a more convenient way, given permissions to a group of projects in one operation, and/or given permission to a group of people, referenced by their team.

GitLab 5.x no longer used Gitolite, but before 5.0, teams and groups are coming from Gitolite, and its gitolite.conf configuration file.
This is where team and groups were declared and associated in order to grant permission access.
Even without gitolite, the idea persists: managing the authorization through association between teams (of people) and groups (of projects).