Development/Tutorials/Git/Feature Development Workflow/Branches and Commit policies: Difference between revisions
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....' |
m moved Archive:Development/Tutorials/Git/Feature Development Workflow/Branches and Commit policies to Development/Tutorials/Git/Feature Development Workflow/Branches and Commit policies: revert |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
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. | {{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=== | ===Creating a 2+ commit feature=== | ||
You have to follow the standard ''branch->integration->staging'' procedure described in the previous documents. | You have to follow the standard ''branch->integration->staging'' procedure described in the previous documents. | ||
Latest revision as of 19:43, 24 March 2012
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.