Git Workflow

This document provides an overview of the Git workflow that is being used by the SFML team. If you are not a team member and want to contribute code, refer to the Contribution Guidelines instead.

General Workflow

Branch master is used for active development.
Create a branch feature/name or bugfix/name for every new feature or bugfix respectively, where name is a descriptive name using the under_scores convention.
Create a pull request for every branch that you want merged into master.
Reviewed and tested pull requests will be merged into master.
Releases receive a tag in form of the version number (x.y.z).

Backporting

Critical bugs are fixed in master and pushed out as a bugfix release with an increased patch version number. Starting from SFML 3, these modifications must be applied to the latest minor version of the previous major version as well.

The workflow is as follows:

Fix bug in master (see General Workflow).
Branch off of the older release and cherry-pick the bugfix commits, using the -x flag to include a "(cherry-picked from...)" message.
Create a tag with an increased patch version number.

Examples

Feature

Develop feature.
Clean up commits (squash and rebase onto master if necessary).
Push to feature/airplane.
Create pull request.
Let others review and test it.
If okay it will be merged into master.
Delete feature/airplane.

Bugfix

Develop bugfix.
Clean up commits (squash and rebase onto master if necessary).
Push to bugfix/window_shrinking.
Create pull request.
Let others review and test it.
If okay it will be merged into master.
Delete bugfix/window_shrinking.
If this is a critical bug which leads to a bugfix release, backport the commit(s) (see Backporting). Let's say we have versions 2.x.0 (latest release of SFML 2) and 3.1.1, where the latter is a bugfix release. The changes in 3.1.1 are then backported to 2.x.1.

Release

Test current master code on all supported platforms.
Clean up if necessary.
Tag last commit with new version number.
Release.
Happiness!