Development Workflow

Martin Zibricky edited this page Oct 4, 2015 · 2 revisions

This page describes the basics of your workflow, which is basically the same as Vincent Driessen described in this blog.

This page is under construction.

Branches

  • branch master
    We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state. Each commit to master is considered a new release and will be tagged.
  • branch develop
    We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”.
    This is where any automatic nightly builds are built from.
  • release branches
    These branches are for preparing the next release. This is for example: updating the version numbers, completing the change-log, recompiling the loader, rebuilding the manuals. See Development Release for details about the release process and what steps have to be performed.
  • hotfix branches
    These branches are also meant to prepare for a new production release, albeit unplanned. This is what is commonly known as a "hotfix".
  • feature branches
    Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.

We do not need long living branches as we do not support bugfixes for several major releases in parallel.

Workflow

  • Occasional contributors use a fork at github (or somewhere else) and send pull requests. One of the core developers should test it and then merge it or ask for other improvements of that patch set.

  • Regular contributors (aka "core developers") use the central repository.

    • Core developers work mostly in feature branches. The purpose thereof is to avoid silly errors in the develop branch.
    • feature branches should whenever the change is more than as single commit. This helps to prevent issues caused of "half-finished" features.
    • feature branches are created for a
      • bug, named like feature/bug-1234-this_is_about_the_bug
      • issue, named like feature/bug-1234_this_is_about_the_issue
      • feature, named like feature/this_is_feature_name
    • When testing is required, the feature branch can be pushed to the central repository or to another personal repository.
    • So other developers can test the code.
    • If a core developer wants some comments for his/her code, then he/she creates a pull request and another core developers should review it and merge.
    • When the code from feature branches are ready, merge it into develop using --no-ff and close (delete) the feature branch.

Hooks

  • New hooks go into develop.
  • Bug fixes for existing hooks go into a hotfix.
  • If existing hooks do not support newer versions of the "hooked" modules, this is a bug, too.
  • Enhancements for existing hooks (e.g suppurt for Qt4 -> Qt5) go into develop.

Merging

Merge the feature-branch back like

git checkout develop
git pull              #  <<<--------
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

Or

git checkout develop
git pull                     #  <<<--------
git rebase develop myfeatre  #  <<<--------
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

Or (untested)

git checkout develop
git pull                #  <<<-------- update
git checkout myfeature
git merge develop       #  <<<-------- merge into branch
git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

Tag Names

Releases are tagged on branch master with the prefix "v" and following this structure:

1.5-a1  # when using alpha versions
1.5-b1  # when using beta versions
1.5-rc1
1.5-rc2
1.5
1.5.1-rc1
1.5.1

TBD: How to tag. Put this into Development Release.