Skip to content

Repository Conventions

Jump to bottom
Lauritz Thamsen edited this page Jul 3, 2014 · 8 revisions

Repository Conventions

[This is currently only a proposal]

Simplified Gitflow Workflow

We follow a simplified version of the gitflow workflow. In a nutshell, for our project:

  • master: the version of the master is considered the latest stable version. it points to versions that not only pass the unit tests and integration tests using the cluster simulator, but also have been tested on our actual cluster.
  • develop: the develop branch points to the most recent working version. changes are integrated in the develop branch. the versions do not necessarily have to be tested on the cluster, but all local tests have to pass. versions that have been tested on the cluster and are considered stable can be merged into master from here.
  • feature branches: new features are developed in dedicated branches containing work in progress and starting from the develop branch, one feature branch per feature. feature branches get merged into the develop branch via pull requests. Feature branches usually start in forks of the central repository.
  • hotfix branches: acute issues that are part of the master should be fixed in hotfix branches. hotfix branches use the master as starting point and need to be merged into both master and develop. the branch name should start with hotfix-.

We (currently) don't use dedicated release branches and not every merge into master yields a new tagged version of Aura.

The main motivation for this workflow is to have a master with versions that have been tested on our cluster, while also having a dedicated develop branch to exchange recent changes that haven't been tested on the cluster yet.

Pull Requests for Work in Progress

We use WIP pull requests on features that we are currently still working on but want to show and discuss. A PR that starts with the three letters WIP is not ready for merging yet.

Mentioning Issues in Commit Messages

Whenever possible we connect commits to issues.

Commits that close issues should contain:

fixes #xyz

or

closes #xyz

Commits that are work on an issue but do not yet close the issue can also refer to the issue in commit messages.e.g.

... fixes most of the problems of #xyz"_

Open questions

  • do we want to rebase to prevent unnecessary merge commits?
Clone this wiki locally