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

Git is included by default in CentOS-6 & -7 and is available from EPEL for CentOS-5.

The CentOS project hosts our sources at 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



Code at 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:

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 organisation

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 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 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<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 script.

Everyone considering consuming and contributing content to must first clone and setup the centos-common code, which is available at:

The git command to clone this would be:

[user@host]$ git clone 

This git repository contains, amongst other things, the 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).

Example workflow

Assume we want to work with the CentOS kernel sources.

[user@host]$ git clone 
cd kernel
# let's work on the centos7 kernel
[user@host]$ git checkout c7
[user@host]$ ~/bin/
# 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

Sources (last edited 2014-06-27 19:38:25 by AkemiYagi)