[pgrouting-dev] Using gitflow to standardize branching

pgRouting pgrouting-dev
1

Hi,

Please checkout this blogpost[1] about a successful branching model in
git. I see pgrouting currently has 14 branches and the flow is a bit
confusing. So, shall we slowly transition from the current branches to
the git-flow style workflow?
The transition involves the following:
* 'master' -> 'develop' // Current master becomes the develop branch
* 'tag v1.05' -> 'master' // Latest release point becomes the new master branch
* 'unittests' -> 'feature/unittests' // unittests branch becomes a
feature branch
* 'gsoc-*' -> 'feature/gsoc-*' // gsoc branches become feature branches
* 'darp' -> 'feature/darp' // darp branch becomes feature branch
* 'devel-2_0' is not required and changes are moved to 'develop'

gitflow doesn't tell anything about packaging branches. So, I'm
confused on how to transition them.
Requesting daniel to take this further.

Thanks,
J Kishore kumar.

[1] - http://nvie.com/posts/a-successful-git-branching-model/

2

Hi Kishore,

Thanks for counting the branches! I haven’t counted them till today. :wink:
And the blog post is also good!

Well, there are the branches:

remotes/origin/darp
remotes/origin/debian
remotes/origin/debian-karmic
remotes/origin/debian-maverick
remotes/origin/debian-natty
remotes/origin/devel-2_0
remotes/origin/gsoc-multimodal
remotes/origin/gsoc-tdsp
remotes/origin/master
remotes/origin/pristine-tar
remotes/origin/snapshot
remotes/origin/snapshot-maverick
remotes/origin/unittests
remotes/origin/upstream

Indeed there are many branches, but most of them you don’t really need to worry about.

There are several branches for making debian/ubuntu packages, because git-buildpackage is some nice way to also handle packaging with version control. I counted 8 branches altogether.
Because there were small changes with different versions of Ubuntu I made different branches for them. Maybe I should do this in my own fork instead.

So when you leave them away, there are the following branches left:

  • remotes/origin/darp
    → contains DARP algorithm, should be merged with 2.0
  • remotes/origin/devel-2_0
    → should be used for 2.0 development and will be merged into master, when 2.0 is out
  • remotes/origin/gsoc-multimodal
    → for GSoC
  • remotes/origin/gsoc-tdsp
    → for GSoC
  • remotes/origin/unittests
    → can also go to 2.0, right?
    I think this number is acceptable, isn’t it?

Sorry for the mess with the the branches for packaging. I just left the Karmic branch for example, even if it won’t be supported anymore.

Daniel

On Sun, Aug 7, 2011 at 5:14 PM, Kishore Kumar <justjkk@gmail.com> wrote:

Hi,

Please checkout this blogpost[1] about a successful branching model in
git. I see pgrouting currently has 14 branches and the flow is a bit
confusing. So, shall we slowly transition from the current branches to
the git-flow style workflow?
The transition involves the following:

  • ‘master’ → ‘develop’ // Current master becomes the develop branch
  • ‘tag v1.05’ → ‘master’ // Latest release point becomes the new master branch
  • ‘unittests’ → ‘feature/unittests’ // unittests branch becomes a
    feature branch
  • ‘gsoc-’ → 'feature/gsoc-’ // gsoc branches become feature branches
  • ‘darp’ → ‘feature/darp’ // darp branch becomes feature branch
  • ‘devel-2_0’ is not required and changes are moved to ‘develop’

gitflow doesn’t tell anything about packaging branches. So, I’m
confused on how to transition them.
Requesting daniel to take this further.

Thanks,
J Kishore kumar.

[1] - http://nvie.com/posts/a-successful-git-branching-model/

pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de