The array logic you mention is an imperative language solution, not quite appropriate for storing on a database.
Relational databases use set logic, which is somewhat similar to array concepts but not the same. You think on sets / tables which are like extensible arrays.
The most usual database design for your problem (with many different variants) would include 3 tables, product of normalization of the data requirements:
a) Users, basic fields like id_user and login_user plus any fields you require (e.g. first_name, last_name)
b) Permissions, with basic fields like id_permission and name_permission
1 Create Repo
2 Commit in Repo
c) Users - Permissions relationship table, with basic fields the foreign keys id_user and id_permission; then flags if you have different levels for the permissions, e.g. can_read, can_write, which may instead be independent permissions
The lack of data in the relationship imply no permission. You may want to add a grant/deny flag to allow explicit permission removal.
Another common pattern that extends this one, is to add a Resources table (or Securables), changing relationship to user - permission - resource