qMp (Quick Mesh Project) - Packages

h1. Repository workflow

h2. Structure

The qMp git repository is split in three branches:

# Master

# Testing

# Other: Features/Bugfixes

h3. Master

This is the main branch and all changes committed here must be tested in Testing branch before.

However the small bugfixes can be directly applied here. These changes must be merged in the testing branch.

<pre>

o---o---o---o---o master

                 \  

--o---o---o---o---o testing 

</pre>

*Example:*

<pre><code class="shell">

git checkout origin/testing

git merge origin/master

</code></pre>

h3. Testing

This is the branch for test new features and changes. The features must be already working features tested before in a specific branch by at least the developer. A feature can be committed here only when it is finished, but not in a middle state.

When the testing branch are deeply tested by more than one developer, than it can be merged on the master branch. Each developer can specify the commit that he thinks is a candidate to merge in master with a signed tag.

<pre>

o---o---o---o---o master

     \         /  

--o---o---o---o testing 

</pre>

*Example:*

Import master bugfixes to testing

<pre><code class="shell">

git checkout origin/testing

git merge origin/master

</code></pre>

Merge testing changes in master

<pre><code class="shell">

git checkout origin/master

git merge origin/testing

</code></pre>

Add a signed tag

<pre><code class="shell">

git tag -s master_candidate_mynick -m "Proposal to update master branch by MyName."

git push origin master_candidate_mynick

</code></pre>

h3. Other: Features/Bugfixes

The rest of the branches are temporal branches.

h4. Features

If it is about a new feature the name of the branch must be the name of the feature (of some name which identifies it). These branches are considered non-functional, so a non-finished feature can be committed here. This branch should preferably be based on a commit of master branch. Once the feature is finish and tested by at least the developer, it should be merged to testing and other branches.

<pre>

o---o---o---o---o master

     \

      o---o---o issue#23-new-feature

               \

o---o---o---o---o testing 

</pre>

*Example:*

<pre><code class="shell">

git checkout -b issue#23-new-feature origin/master

editor dir/file

git add dir/file

git commit

#test issue#23-new-feature branch

git checkout origin/testing

git merge issue#23-new-feature

</code></pre>

h4. Bugfixes

A bugfix must be implemented in a new branch. This branch must be based on a commit of the master branch. This branch should not be based on a commit of the testing branch because it may contain new features and these maybe cannot be imported in the master branch. This new branch can be merged in testing and other branches.

<pre>

o---o---o---o---o master

     \         /

      o---o---o issue#23-bugfix

               \

o---o---o---o---o testing 

</pre>

*Example:*

<pre><code class="shell">

git checkout -b issue#23-bugfix origin/master

editor dir/file

git add dir/file

git commit

#test issue#23-bugfix branch

git checkout origin/testing

git merge issue#23-bugfix

git checkout origin/master

git merge issue#23-bugfix

</code></pre>

*Another example:*

<pre><code class="shell">

git checkout -b my-new-branch \

    $(

        git merge-base \

        --octopus origin/master origin/testing origin/kalimotxo \

    )

editor file

git add file

git commit -m "My change"

git checkout origin/master

git merge my-new-branch -m "Import my change"

git checkout origin/testing

git merge my-new-branch -m "Import my change"

git checkout origin/kalimotxo

git merge my-new-branch -m "Import my change"

git push

</code></pre>

h2. How to use it

h2. Good practices