Skip to end of metadata
Go to start of metadata


This page documents:

  • Asterisk's various Git repositories, and their intended purposes.
  • Policies for using Git and Gerrit with Asterisk.
  • Useful commands.

Git Repositories


Asterisk uses Gerrit as its primary repository and for for code review. Users who are looking to clone or contribute patches back to Asterisk should work the repositories on Gerrit. Please see the Gerrit Usage documentation for more information.


The repositories on mirror the repositories on Gerrit, and provide source tree browsing.


The repositories on GitHub mirror the repositories on Gerrit, also provide source tree browsing, and exist because of GitHub's popularity.

Pull requests on GitHub WILL be ignored.

On This Page

Gerrit Access

Anyone may clone repositories from Gerrit anonymously.

Users may participate in code reviews or contribute patches if they have signed a Contributor License Agreement. Access to Gerrit is performed using your JIRA (Atlassian) username/password. You may create an account at, and sign a CLA in JIRA. Note that you will not be able to log into Gerrit if a CLA is not associated with your JIRA account.


When submitting a patch to Gerrit, you are explicitly doing so under the terms and conditions of the Contributor License Agreement. If you do not wish to contribute a patch back to the Asterisk project, please do not push a patch up to Gerrit.

Gerrit Policies

Code Reviews

  • -2 should only be used if the current implementation requires a complete rewrite to be acceptable, or if the change should not be made under any implementation.


    If you use a -2, please be prepared to justify its usage.

  • +2 should generally not be given unless someone has already given the review a +1.
  • Related to the previous, users who provide a +2 should generally not provide it to a change that they provided the +1 on.
  • Please read the Asterisk project Coding Guidelines prior to submitting patches. When performing code reviews, please refer to the Code Review Checklist.


  • Please use the -t option with git review, specifying the ASTERISK issue the change should be associated with:

    This helps to tie Gerrit reviews to the JIRA issue that necessitated the change.


  • All branches that require the change should have the change cherry-picked to that branch, and submitted for review. See Software Configuration Management Policies for which patch types are appropriate for what branches. See Gerrit Usage for instructions on cherry-picking.
  • The same Gerrit Change Id must be present in all cherry-picked commits.
  • The same topic (ASTERISK issue) must be used in all reviews.
  • Test Suite test reviews should use the same topic (ASTERISK issue) as the code change reviews.

Useful Commands and Tips

  • git clean: When switching between major release branches there are often whole directories that are in one branch but not another.  'git clean -fd' will clean out the working directory.  Just make sure any files you want to keep are either checked in or ignored.
  • If you use an IDE or other tools that need configuration files in the working directory but their names don't match an entry in .gitignore, you can add them to git/info/exclude to ignore them locally without updating the checked-in .gitignore.
  • git log:  This is one of the more useful tools there is.  Here are some examples:Show the commit difference between 13.8 and 13.9

    • Show the difference between the 13.8 and 13.9 branches:

       Both are branches so you'll see the diff between their current states with the merge and housekeeping commits excluded.

    • That's a lot to type so add an alias:

    • Show the commits added to 13.9 after up to 13.9.1

       Wait, that didn't show anything!  That's because 13.9.1 is a tag on 13.9 and nothing's been added to 13.9 since then so they're equal. What you probably want is:


    • Now things get a little complicated. Let's say 13.8 is closed but certified/13.8 is still open. So, what's in certified/13.8 but not 13.8? You might be tempted to use the '..' operator between the 2 branches as before but because '..' is a range operator it doesn't work well when the 2 branches overlap, especially when we're cherry-picking; you'll wind up showing commits that are in both branches. Instead, you need to use the '...' operator and the --cherry-pick flag.

    • Finally, things get even more complicated when trying to compare 13 and master.  Because of the cherry-picking and the fact that these 2 branches started in subversion, there is no single git command that will show the differences reliably. The only way to do this is to pick a point in time as a starting reference, list the log from both branches, sort them, then compare them.  It would be nice if git could do the matching on the gerrit change id but it can't so we're left with matching on subject

      April 11 2015 was the migration from subversion to git.  Also note that the 2 app_amd commits are probably the same but we have no way to tell.


  • No labels