We propose that for development in C2NET we use tickets to make a clear isolation between the code of the various features. First, we have four types of branches: ticket, development, alpha and master. The ticket branch is where features are developed. Before the start of each feature, a ticket is opened indicating the feature's name and its purpose. Then, a new branch is created, derived from the development branch, where that feature is implemented. Once finished, that branch is merged into the the development branch for integration with the already existing features. Once this integration is finished, the feature is passed onto the alpha branch, where is properly and thoroughly tested. Once its conformity is confirmed, the new feature can now be a part of the master branch, composed of only the final features.

The ticket branch is in fact a set of branches. When creating the ticket, it should be mentioned the commit it applies to. Then, the developer may clone directly from the mentioned commit, or from another commit/branch if (s)he deems so.

This development process has a sequential git processing: features start as a ticket branch, go to development, followed by testing, and a final merge into the master. If during development the code has to return to the previous step, then the current branch shall not be merged with the previous one. Development shall continue in the previous point, and once corrected shall be merged again into the next branch.

An example of this development philosophy is presented next.

After the initial project commit on the master branch, a new feature is to be added (1). After its development (2), it is sent to the development branch (3). Once it is ready for testing (4), and its compliance is confirmed (5), the new feature can become final and placed in the master branch (6).
If during development a new feature is to be added to a specific commit (7), the it is developed, and once completed (8) it is sent to testing until it is correct (9), and then added to the master (10).

Tickets will be used not only for features, but also for bug reporting. For bugs, our proposal is that new branches are created from the original code branch. For example, consider that was found a bug during development. A new ticket was opened, the bug #32. Then, a sub-branch of development is created, identified as "bug-32-dev". The bug is corrected in this new branch. Once finished, this "bug" branch is merged into the development branch, and normal development resumes.

The alpha branch is dedicated to testing. It is in the alpha branch that code dedicated to testing is kept, in order to obtain a common repository for all the testing dedicated code. When new features are ready to be tested, they are merged into the alpha branch. If they pass the tests, then they can be added to the master branch.

Both these strategies allow an hierarchical organization of the code inside the project, and ease of access to specific code development, such as adding features or correcting bugs.

Now we present a simple practical example of this development strategy.

Original git state.

$ git branch
  alpha
  dev
* master

Begin development in Optimizers of feature mentioned in ticket #1.

$ git branch dev-opt-1
$ git branch
  alpha
  dev
  master
* dev-opt-1
$ git checkout dev-opt-1 
Switched to branch 'dev-opt-1'

Actual development.

$ git add skel.java 
$ git commit
[dev-opt-1 c93ae16] Add feature #1
 1 file changed, 1 insertion(+)

Once the development is done, merge the new feature to the development branch.

$ git checkout dev
Switched to branch 'dev'
$ git merge dev-opt-1 
Updating ad0239b..c93ae16
Fast-forward
 skel.java | 1 +
 1 file changed, 1 insertion(+)

Continue development in the development branch, and once finished merge to the alpha branch for testing.

$ git add skel.java 
$ git commit
[dev d694961] Development
 1 file changed, 1 insertion(+)
$ git checkout alpha 
Switched to branch 'alpha'
$ git merge dev 
Updating ad0239b..d694961
Fast-forward
 skel.java | 2 ++
 1 file changed, 2 insertions(+)

Testing done, can be merged to the master branch.

$ git add skel.java 
$ git commit 
[alpha dc95e25] Tested
 1 file changed, 1 insertion(+)
$ git checkout master 
Switched to branch 'master'
$ git merge alpha 
Updating ad0239b..dc95e25
Fast-forward
 skel.java | 3 +++
 1 file changed, 3 insertions(+)

This example considers that the ticket branches are always created from the last commit of the branch. If we want to branch from a specific commit, first we need its hash. It can be obtained via the commands git log or gitk, or through the web interface.

$ git log
commit 0ebc79747cbc3855056a8e1d0fb5c854c4352948
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 15:04:49 2015 +0000

    commit 2

commit 94594df68e8476b44538967088bcbd2211eb3748
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 15:04:18 2015 +0000

    commit 1

commit dc95e259f6776668972e37a11dac7b6ad23d1535
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 11:37:28 2015 +0000

    Tested

commit d69496135373f9897d4d9e04d7e5b16e9c1068fb
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 11:36:43 2015 +0000

    Development

commit c93ae1654407958c25c8fbde3e9ef903a8c16f0c
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 11:18:07 2015 +0000

    Add feature #1

commit ad0239b326f9f5451d016f15eb248b7de113a114
Author: Fernando Alves <fernando.alves@caixamagica.pt>
Date:   Mon Nov 16 11:16:08 2015 +0000

    Initial commit

The gitk will show a graphical representation of the user's current branch.

$ gitk

Then, we can branch from a specific commit.

$ git branch dev-opt-2 94594df68e8476b44538967088bcbd2211eb3748
$ git checkout dev-opt-2 
Switched to branch 'dev-opt-2'
$ git branch
  alpha
  dev
* dev-opt-2
  master
  opt-1

The merge process is the same as before.