diff --git a/docs/buildsys/git.md b/docs/buildsys/git.md
index bb5482b..4100d05 100644
--- a/docs/buildsys/git.md
+++ b/docs/buildsys/git.md
@@ -1 +1,46 @@
 # Git source control 
+
+We use various git hosting solutions for CentOS, depending on the need[s] :
+
+ * [Pagure](https://pagure.io/pagure) : self-hosted on [https://git.centos.org](https://git.centos.org)
+ * Github : we have a [presence/Organization](https://github.com/centos) there for some automation scripts for historical reasons, like all [ansible roles](https://github.com/centos?q=ansible-&type=&language=&sort=)
+ * Gitlab : Recently Red Hat decided to start using Gitlab for [Stream 9 sources](https://gitlab.com/redhat/centos-stream) and beyond
+
+Let's only focus on the first one, that infra team needs to manage/maintain and let's explain also what it's used for, and which specific permissions/delegations we have for Special Interest Groups.
+
+# Git.centos.org
+The first thing to know is that it's all managed/deployed by Ansible [pagure role](https://github.com/CentOS/ansible-role-pagure)
+
+Due to experience within the team, we decided to use MySQL DB instead of postgresql, and also to reuse existing roles for these other parts.
+
+## Initial purposes
+
+It's mainly used for :
+
+ * centos specific projects (like website, etc), all in the `/centos/` namespace
+ * RPM packages sources from RHEL, pushed by Red Hat, and then built by the CentOS team, all landing in the `/rpms/` namespace
+
+## Authentication
+
+Our pagure instance is tied with our existing [Authentication service](/infra/authentication/) so one needs to first have a account there to interact with the pagure instance (except of course for Read-Only operations like cloning a repository, etc)
+
+When a user is added in a SIG group , and logs in again, its membership will be reflected at the pagure/git.centos.org side.
+
+Their ssh public key is imported into their account (normal for a git forge solution).
+
+## Protected branches and ACLs
+
+By default, *nobody* (except specific Red Hat privileged account) can push to `master` branch on *any* project under /rpms/ namespace, nor any other protected branches, like `c7`, `c8`, `c8s` and so one (based on regex).
+All these protected branched represent what Red Hat is pushing, and that should represent upstream RHEL Sources.
+
+Apart from protected branches, member of SIGs can push *automatically* (the logic is checked automatically by [pagure-dist-git](https://pagure.io/pagure-dist-git) to some 'sub' branches.
+
+Example : a member of the `sig-cloud` can automatically push to the `c8-sig-cloud-<whatever_if_I_want_to>` branch of any rpm in the `/rpms/` namespace, but *never* to the main `c8` branch (and repeat the logic by swapping distro release and sig group/name)
+
+### Lookaside cache upload
+
+People can also push to the [`lookaside cache`](https://git.centos.org/sources) the needed tarballs/archives that can be used to [rebuild/compose a src.rpm](https://wiki.centos.org/Sources) package before being submitted to the build system (to build and release rpm packages)
+
+Same logic as above : specific priviledged Red Hat account can push all needed tarballs/archives to the lookaside cache in all directories.
+
+A SIG member can push to specific branch that correspond to the logic described above for git : from our previous example, that means pushing to `c8-sig-cloud-<whatever_if_I_want_to>`