Last updated July 30, 2012.

Each Drupal project, either a module, theme, or installation profile, gets its own Git repository, hosted at http://git.drupalcode.org.

The Git repository for each project, regardless of project type, lives at the URL http://git.drupalcode.org/project/PROJECTNAME.git, where PROJECTNAME is the machine-readable name of the project.

Unlike CVS, Git does not currently offer the option of browsing all repositories in one place. Instead, you must access each repository directly by fully-qualified URI, e.g. for Drupal core, http://git.drupalcode.org/project/drupal.git . If you want a listing of repositories, you will need to consult the listings of projects on Drupal.org itself: modules, themes, and distributions.

Note: Browsing capability will be added in a future phase of the Git rollout.

Branches

For Drupal core, there is a Git branch for each major version of Drupal. For example, the last few branches of http://git.drupal.org/project/drupal.git are 5.x, 6.x, and 7.x.

Modules and themes use branches for each new major version, as well as releases for new versions of Drupal core. Their branch naming convention include the Drupal core version and the module's version number. Example branches include 6.x-1.x, 6.x-2.x, and 7.x-2.x. For more details about branch names, see Release naming conventions.

Tags

Tags are used for individual releases of a project. For example, there is a new tag for each new minor release of Drupal core, a few of the latest being 6.19, 6.20, 7.0-rc-4, or 7.0.

Modules and themes use a tag naming convention including the Drupal core version and the module's version number. Example tags include 6.x-1.0, 6.x-1.1, and 7.x-2.0-alpha. For more details about tag names, see Release naming conventions.

Comments

I have a suggestion for how drupal.org could use git in a way that would make it far more convenient to follow the latest release: add a separate branch that contains only releases, e.g. only 7.x releases.

At the moment, all development on the next 7.x release seems to be happening on the "7.x" branch. When that development has completed, that branch gets a tag with its version number (e.g., "7.13"). This means that anyone who wants to follow the latest release first has to look up the latest tag and then do a checkout on that tag.

Would it not be much more convenient if there were separate "7.x" and "7.x-dev" branches, the former for releases and the latter for development? Then, whenever development on the "7.x-dev" branch has reached maturity for a new release, the release is performed by merging "7.x-dev" into the "7.x" branch (plus still adding a tag like "7.13" to the result of that merge, to document the version number). This way, those of us who merely want to keep our production environments up-to-date with the latest release simply would have to initially do a "git checkout 7.x" to get the latest released 7.x version. After we have specified this way once what we want, we simply have to type "git pull" every now and then, to update to the very latest released 7.x version.

Any particular reason why that isn't done?

Having such release branches would seem much more convenient (especially in scripts), than having to manually specify the latest release tag each time. It would also make it much easier to merge new releases into a local branch, which could simply track the 7.x release branch.