[[!toc]] # Keeping debian/patches on a patch-queue branch This part moved to gbp's [manual](https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html) # Cloning a repository If you use *gbp clone* instead of *git clone* to clone a remote repository it will automatically set up the *debian*, *upstream* and *pristine-tar* branches for you. The [manual][] explains the terminology. # Keeping a repository up to date After initially cloning with *gbp clone* you can run *gbp pull* to update your *debian*, *upstream* and *pristine-tar* branches from the remote site. So the complete workflow for simple team maintenance looks like this: # Initially clone the repo once gbp clone git://git.debian.org/pkg-libvirt/gtk-vnc.git cd gtk-vnc Work on that clone, commit, release, push, etc. Now after a couple of days you want to make more changes but don't know if another developer worked on it. So you do: # Update to what others might have pushed gbp pull This will update all necessary branches to what other developers might have pushed in the meantime. If you're also using a patch-queue as described above you can refresh that too in one step: # Update to what others might have pushed and rebuild patch-queue gbp pull --redo-pq This will additionally drop your current patch-queue branch and recreate it from debian/patches. # Preparing a Backport I keep backports on a separate *bpo-* branch like *bpo-lenny*: git checkout bpo-lenny git merge debian/ gbp buildpackage --git-pbuilder --git-dist=lenny -sa -v --git-debian-branch=bpo-lenny In order to avoid the merge conflict in the changelog have a look at *dpkg-mergechangelogs(1)*. To create the necessary cowbuilder chroot for Lenny use: DIST=lenny git-pbuilder create [git documentation]: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history [manual]: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY