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

    From KDE TechBase
    Revision as of 15:37, 28 April 2011 by Drf (talk | contribs) (Created page with '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....')
    (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

    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.