Using git for team packages

There are many advantages to team-based package development. The DPT has very excellent, knowledgeable, and experienced Python and Debian developers and our goal is to bring the very best Python experience to Debian users and developers. We're here to help each other and provide consensus (if not 100% agreement) on best practices. Collaboration has many benefits, and one of the things that aids effective collaboration is common tools and workflows surrounding packaging, while still providing individual maintainers the freedom to adapt those practices to their preferences, and the peculiarities of the packages.

One of the perks of being in a team is that all of our packages are managed in a similar way, using similar tools and workflows. This is great because any team member can immediately get the source of a package to do an update or a bug fix, and they don't have to first try to figure out how the package is version controlled. Plus, we can have nice wiki documentation which help new team members how to do things, and almost anyone on IRC can immediately give you advice. We use a common set of vcs procedures to ensure consistency among all of our packages.

It is a team requirement that all packages be managed using the same version control system.


Git Repository, under the python-team

Git Workflows

Most of our git-based workflow is provided by gbp (formerly git-buildpackage). On top of gbp there's the patch management regime. Most Debian developers are familiar with quilt for including Debian-specific patches to upstream pristine tarballs. While it's still possible to use quilt directly of course, there is a better way to integrate the best of the git world with quilt. Of the two predominant git-based patch regimes, the Debian Python team has chosen gbp pq.

Git Branch Names

As a team we are strongly recommending you use DEP-14 style branch names, specifically:

If you use other branch names, please have a good reason (not just personal preference, remember - take one for the team!), and you MUST document the differences in debian/README.source. The default branch names will help the repo interoperate better with other tools.

gbp pq creates a patch branch when you want to directly edit upstream source files for export to quilt patches, however this is for local use only and should not be pushed to remote servers.

Git Tag Names

There seems to be several tag styles in common use. However, we recommend using '/' as a separator, yielding tags like debian/0.2.0-1.

Recommended/required configuration settings

Both git itself and git-bp provide ways to configure defaults. Settings that are personal to you should live only in $HOME/.gitconfig or $HOME/.gbp.conf. Settings which affect how the team interoperates should live in <repo>/debian/gbp.conf so that anyone who checks out the branch will see the same settings.


Here are some common scenarios and use cases. There may be other ways to accomplish these tasks so if you find a more efficient way of doing something, please update these pages and discuss with the team via the debian-python mailing list. Feel free to add more use cases here too! Your experience is valuable.

Creating new repositories

To set up a new repository visit and follow the 'new project' link (the link will not be accessible unless you have joined the team). Enter the source package name as the project name and leave the visibility set to public.

Use these Vcs-* fields in the header of your debian/control file:


Replace <srcpkgname> with your source package name.

You can also create the repository using the salsa tool:

salsa --group python-team/packages create_repo <srcpkgname>

Creating a new package

First, initialize the project on to set up the bare repo that you will push your branch.

Next, you can either import an existing .dsc file or start from scratch(But be careful Debian-python team does not support git-dpm workflow). Here's are the steps from the manpage that seem to work well:

$ uscan   # Download your package's upstream original tarball
$ tar -xvf srcpkgname_1.0.orig.tar.gz
$ cd srcpkgname_1.0
$ git init
$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0
$ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream
$ git checkout -b debian/master

You'll now be left on the debian/master branch, i.e. the packaging branch. You'll also have upstream (raw tarball contents) and pristine-tar branch.

Fill in the rest of your debian/ directory, then do this:

$ git add debian/*
$ debcommit  # assuming you have a d/changelog entry, otherwise git commit

Checking out an existing package

Packages can be checked out individually, or managed as a group, with mr. It is configured to not checkout all the team packages by default, but easily manage the ones that are checkout out, collectively.

$ sudo apt install mr
$ git clone
$ cd packages
$ echo $PWD/.mrconfig >> ~/.mrtrust
$ ./checkout PACKAGENAME  # For each package you care about

if your username differs between your local machine and Salsa, then you can add this snippet to ~/.ssh/config:


To update the .mr-config file, run

$ git pull
$ ./make-mrconfig

And if there are any, commit and push changes.

To update all your checked out packages, run

$ ./quick-update

To check out packages individually, you might be able to just

$ debcheckout -a <srcpkgname>

but while the Vcs-* fields have been updated in the repository, new uploads with those fields still need to be done. In the meantime, you can:

$ gbp clone<srcpkgname>.git

gbp clone is preferable to git clone because gbp clone ensures that you'll have all the remote tracking branches set up properly. You can still use git clone but you'll have to check out the pristine-tar and upstream branches yourself.

You might also want to add this handy little convenience to your ~/.gitconfig file:

[url ""]
    insteadof = dpt:

which allows you to do this:

$ gbp clone dpt:srcpkgname.git

make sure you cd into the source directory.

Ensure up-to-date

Before doing anything on an existing repository, always always always ensure you have pulled in any changes:

$ gbp pull --redo-pq

If you always remember to do this, you reduce the risk of causing accidental git conflicts.

Note that the --redo-pq option will discard any local changes to your local patch queue, and replace with the patches from debian/patches.


Now you can build your package using whatever tools you like, including debuild, dpkg-buildpackage, and git-buildpackage.


Push your repo to

$ git push --set-upstream<srcpkgname>.git : --tags

At this point, I like to cd to a different directory and do a gbp clone<srcpkgname>.git and then continue working from the <srcpkgname> directory. To prove that all the branches got pushed correctly, in this fresh clone, checkout the debian/master, pristine-tar, and upstream branches.


Once you've built and uploaded your package, you should tag the release.

$ gbp buildpackage --git-tag-only
$ git push --tags

Alternately, if you want to sign your tags:

$ gbp buildpackage --git-tag-only --git-sign-tags
$ git push --tags

New upstream release

You should import the patch queue first. For this to work correctly, debian/gbp.conf should already have the correct value debian-branch, otherwise gbp import-orig will merge to the wrong branch.

Using a debian/watch file (recommended):

$ gbp pq import
$ git checkout debian/master
$ gbp import-orig --pristine-tar --uscan

Note "gbp pq import" will switch to the wrong branch, and if not fixed then import-orig can do the wrong thing.

Using a tarball file:

$ gbp pq import
$ gbp import-orig --pristine-tar /path/to/new-upstream.tar.gz -u 0.2

where 0.2 is the new upstream version number.

{i} If the upstream tarball is already in the form packagename_version.orig.tar.gz (E.g. package_0.2.orig.tar.gz), then the -u option is not required.

Important notes:

Rebase the patches:

$ gbp pq rebase
$ gbp pq export

You will need to push the debian/master branch and also the upstream and pristine-tar branches.

$ git push origin : --tags


Patching (i.e. adding quilt patches) is easy. You import the patches to a git patch queue, edit the patch queue, then export back again.

In general, to patch your package do this:

$ gbp pq import
Edit patches
$ gbp pq export
$ vim debian/changelog
$ git add debian/changelog
$ git add debian/patches/*
$ git commit

Cherry picking upstream commits

Sometimes you need to cherry pick upstream commits, e.g. to fix a bug in the Debian version when upstream hasn't yet released a new version. A convenient way to do that, if upstream is developed in git, is to add a remote and cherry pick from that. For example:

$ git remote add upstream_repo git://
$ git fetch upstream_repo
$ gbp pq import
$ git cherry-pick any_upstream_commit
$ gbp pq export
$ vim debian/changelog
$ git add debian/changelog
$ git add debian/patches/*
$ git commit

Sponsoring, mentoring, reviewing


Pull requests


Converting git-dpm to gbp pq

Previously DPT used git-dpm at the workflow. This section documents how to convert from git-dpm to gbp pq.

  1. Ensure all branches up to date.
  2. Unapply all patches
  3. Delete debian/.git-dpm config file.

  4. Set debian-branch value to debian/master in debian/gbp.conf

  5. Commit to debian/master branch (use git branch -m master debian/master to rename the branch).

  6. Update .git/config branch debian/master to refer to merge = refs/heads/debian/master.

  7. Refresh the patches.
  8. On Salsa, set the default branch to the new debian/master branch.

Sample debian/gbp.conf file:


Sample steps to do the above (upstream branch will not be automatically checkout out locally):

gbp pull
git read-tree --reset -u upstream
git reset -- debian
git checkout debian
git rm debian/.git-dpm
cat <<EOF > debian/gbp.conf
git add debian/gbp.conf
git commit -m "Convert from git-dpm to patches unapplied format"
git branch -m master debian/master
git push origin -u debian/master

To refresh the patches:

gbp pq import
gbp pq export
dch -m "Refresh patches after git-dpm to gbp pq conversion"
git add debian/patches/
git add debian/changelog

To make the new branch the default and delete the old branch:

  1. go to$1/edit

  2. expand "General settings"
  3. select the new default branch
  4. go to$1/settings/repository

  5. expand "Protected branches"
  6. fix those settings
  7. go to$1/branches

  8. delete the old master branch

Packages no longer maintained by DPT

Packages repositories can be archived on Salsa by owners of the Python team namespace. If you want an obsolete repositories to be archived you will need to contact one of the owners and ask them to do it.


Q: What if I don't want to use gbp pq?
A: Please be nice to your fellow teammates, and reconsider! We want team members to easily know what workflow to use, by common convention. In rare cases, if some deviation from the team default is required, you MUST have a good rationale, and both the reason and workflow MUST be documented in the README.source file.

Q: Source-full or source-less branches?
A: Source-full branches please! There are lots of good reasons for this, including the ability to easily diff between upstream versions, say to double check that nothing untoward or undocumented has been added in a new upstream version. E.g. git checkout upstream and git diff upstream/0.11.3 would for example give you an overview of what's new in upstream's 0.11.4.

We require team maintained packages to contain the full upstream source, and we don't believe it will be an overwhelming performance or disk-space burden to do so. It is much easier to hack on packages, including generating the quilt patches, when a checkout of the repo gives you the full source. Source-less branches defeat much of the benefit of managing packages in git.

Q: Should we honor pull requests and allow for mirrors on ?GitHub or GitLab?
A:We will still require all team packages to be available on Please do not host your team maintained packaging branches anywhere else; e.g. ?GitHub is not appropriate for the packaging branches because it is not free software. GitLab does have a free software Community Edition and someday it might be interesting to run one of those for DPT or Debian-at-large, but for now please do not submit merge requests on

More information and resources