Build the same source package for different Debian based distros

Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).

Another approach is to keep different files side-by-side; see Solaar for an example of this.

But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.

For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).

The general idea is to ask dpkg-vendor what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules has

derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")

and further down an override for dh_gencontrol to fill in “substvars” as appropriate:

override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
        dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
        dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif

This fills in the appropriate variables in debian/control:

Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
 ${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
 ${solaar:Desktop-Icon-Theme}

and

Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
 gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
 ${solaar:Gnome-Icon-Theme}

You can use the test in debian/rules to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.

Probably you can go with git-buildpackage and keep the different debian directories in different branches.