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"
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).