Git is the version control software of choice for us here at the CentOS Project. If you are new to this, there are some great resources including getting started guides at http://git-scm.com/
Git is included by default in CentOS-6 & -7 and is available from EPEL for CentOS-5.
The CentOS project hosts our sources at git.centos.org and we consider this to be the canonical upstream for the project. Various efforts, as a part of the project, might choose to also mirror their content in other places like Github. However all release content must be built from, tested via and curated at git.centos.org
Code at git.centos.org is organised into git repos, one per rpm or role. These git repositories are then organised into 'projects'. The main 'project' is called rpms/ and contains git repos for all the rpms we build and ship. You can view this project at: https://git.centos.org/project/rpms
Typically, every SIG would have its own project. This allows them to add in non rpm content (eg. test suites, or management interfaces, scripts, etc) within their own domain. SIGs would also typically have administration rights over these projects they own.
Git repositories, specially those that contain rpm content, are organised by branch names that map to CentOS Releases eg. branch name 'c7' would be where you will find content released into CentOS Linux 7. Similarly c5 and c6 branch names correspond to CentOS-5 and CentOS-6. There is usually no content in the MASTER or HEAD branches other than a readme indicating where to look for the actual code. When working with a SIG specific component, we recommend committing code into a branch that maps to the SIG name (or the SIGs project name on git.centos.org). This not only allows people to view and track on the code history they care about but it also allows people to create site-specific forks and branches without polluting the distro release tree.
Non Text Sources
We only checkin text sources into git. All non-text sources are extracted, hashed (sha256sum'd) and uploaded into their own lookaside cache at https://git.centos.org/sources/ They are organised into groups that map to the branch of git to which they apply and are further grouped into the git repos to which they belong. The fully qualified path to those non-text-sources would then be https://git.centos.org/sources/<git repo name>/<branch name>/
Note that there is a special case for zero byte files, that are neither checked into git nor pushed into lookaside. These files are however still tracked and reproduced via the non-text-sources metadata file.
Every git repository has one of these metadata files named .<git reponame>.metadata and hosted in the root directory of the git checkout/branch. This file is used to map the sha256sums to their full filenames and are consumed by the get_sources.sh script.
Everyone considering consuming and contributing content to git.centos.org must first clone and setup the centos-common code, which is available at: https://git.centos.org/summary/?r=centos-git-common.git
The git command to clone this would be:
[user@host]$ git clone https://git.centos.org/git/centos-git-common.git
This git repository contains, amongst other things, the get_sources.sh script. This script, when run from a git checkout for an rpm git repo will parse the non-text-sources metadata file, and download the relevant files, setting up the SOURCES/ directory. You may want to create a symlink to this script from ~/bin (see the example session below).
Assume we want to work with the CentOS kernel sources.
[user@host]$ git clone https://git.centos.org/git/rpms/kernel.git cd kernel # let's work on the centos7 kernel [user@host]$ git checkout c7 [user@host]$ ~/bin/get_sources.sh # switch to the local tree to edit [user@host]$ git branch my-kernel [user@host]$ git checkout my-kernel # make edits to SPEC file, etc [user@host]$ git commit -m'my local changes' -a # ensure we can create a srpm [user@host]$ rpmbuild --nodeps --define "%_topdir `pwd`" -bs SPECS/kernel.spec # if that works, [user@host]$ rpmbuild --define "%_topdir `pwd`" -ba SPECS/kernel.spec