Skip to content

Repository Conventions

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

Repository Conventions

Workflow: Simplified Gitflow

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.

Commits, Merging, and Pull Requests

Pull Requests

We use pull requests for major changes.

Work-in-Progress Pull Requests

We use WIP pull requests on features that we are currently still working on but want to show and discuss. A PR that is tagged with the label work in progress is not ready for merging yet, but wants to be noticed and discussed.

Clean up Commits

Until the commits of a feature branch have been merged into an upstream branch (e.g. the develop branch), the history can be rewritten if that yields a cleaner history.

  • Use git rebase -i [SHA] to squash commits, reorder commits, or reword commit messages

Rebase Commits

We rebase commits to prevent merge commits that do not merge features.

  • Pull changes with the --rebase flag from remote repositories
  • Rebase changes into your feature branches to keep it up-to-date with e.g. the develop branch

Mention Issues in Commit Messages

Whenever possible we connect commits to issues.

  • Include fixes #xyz or closes #xyz if a commit resolves an issue

Commits that are work on an issue but do not yet close the issue can also refer to the issue: e.g. ... fixes most of the problems of #xyz"

Clone this wiki locally