Development/Tutorials/Git/Feature Development Workflow/Branches and Commit policies

From KDE TechBase
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Warning
This page refers to a draft policy which is still to be agreed and implemented. Please take it as a reference for a work in progress project.


In our workflow, 99% of the changes should be developed inside a separate branch, and merged into integration afterwards. However, sometimes creating a branch is not worth it (e.g.: one-line fixes), and stuff can even go straight into origin without having to be staged (e.g.: bugfixes).

This page is aimed to explain different commit strategies depending on the type of changeset you want to introduce.

Creating a 2+ commit feature

You have to follow the standard branch->integration->staging procedure described in the previous documents.