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

Jump to: navigation, search
noframe
 
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.


This page was last modified on 24 March 2012, at 20:43. This page has been accessed 917 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal