This should be the expected action which is by designed.
In step2, you add the group in the top-level repositories. This is the action which will make changes to all repositories. When the sub-repos enabled the Inheritance, the child individual repos will inherit the permissions from top-level automatically.
This was mentioned in this document:
Set permissions across all Git repositories by making changes to the
top-level Git repositories entry.
Individual repositories inherit permissions from the top-level Git
Repositories entry. Branches inherit permissions from assignments made
at the repository level.
For more detailed, you add Team A
, Team B
into the top-level repositories, and you make the Inheritance
as true
in sub-repos.
At this time, the system will reject your request with the message ({group} has inherited permissions and cannot be removed from the list) when you trying to remove Team A
from one child repo. Because this Team A
still keep the permission occupation in other sub-repos in the meanwhile.
Or what i can do to remove the group from the child repository.
I'm afraid this could not be achieved, because this is the security model limitation. Every permission group has its corresponding security model. In this Version Control Administration
panel, the rules of this model does not allow the Users or Groups which added into the top-level repository and be inherited by child, can be removed from child.
In this scenario, you had remove them from top-level.
So, I'd suggest that you need add users/groups into top-level repositories carefully while these some groups/users need a global permission. Most of scenarios, add for individual repos would much better. Of course, this based on the actual demands of groups/users.