branching strategy

[leilaicruz]

Lets not create branchs with our names because this is a bad habit . So lets do the things good from the beginning 😉

• If you create a branch with your name this basically telling nothing , I dont know a priori what is there.
• If you would like to add a new functionality to a certain piece of code you can experiment , and then you create a new branch only dedicated to experiment on that specific funcionality , with a proper informative name of what is this branch doing like adding-area-plot-to-codeXX . Once you have the code there working you can then merge it where you have the original codeXX and succesfully add this functionality.
• You can also make a new branch for only coding , and also a new one for the project log, and leaves the master/main branch with the project changes we want to show there

[T-Wisse]

That makes sense. I was figuring out how to make them and merge them so I just copied what we had in the shared repo. I will remove devThomas and we can create branches when needed.

[T-Wisse]

I was thinking about creating and keeping a branch for literature review in general because I find I need to better document what papers/other I read/skim and what information they have that is relevant for me. Just the issues on the classifier and genetic interaction data made me realise that. However, for documenting that I don't necessarily need to use git, what do you think would make sense to use? I could use trello as well but I feel that may become a bit unwieldy over time.

[leilaicruz]

• It doesnt hurt to use git anyways , as long as you keep using markdown for text
• you could use the wiki of github to document your literature review as well
• or you can have an external source , like google docs, latex online etc that ou can provide the link into the readme of the repo , that , that is your literature review
• there are many options , but the key is to integrate well everything such as it can help you in the learning and documentation process

[leilaicruz]

To finish with the branch strategy :

• I will do a branch when I would like to improve or change something you have done in one of your branches and then make a pull request in order for you to test the changes I did and if you are OK to integrate them in your branch.

• For your experimenting , let say when you are programing, when something is working and you want to add it more stuffs or use it for smething else is a good practice to also create a new branch for experimentation without touching the branch you already have working . Then when you finish your experiment , you can integrate it (merge git command) safely to the working branch and keep experimenting in the other one. The message is to keep clean stuffs away and safe from dirty stuffs as much as possible to avoid disasters hahahahha

[T-Wisse]

I have restructured the branches and repositories such that all coding is done in the repo MEP_Thomas (this repo):

• The main branch is the stable (release) version.
• The development branch will be used for developing new features
• A new branches will be made for each feature I will add
• These feature branches will branch from and merge with the development branch once finished.
• The feature branch names should describe the feature I am adding
• If the development branch has stable changes, these changes will be pushed to the main branch

Furthermore, this repo is issued to keep track of all the issues and used as a board for expirimental work

The repo journal_mep (https://github.com/T-Wisse/journal_mep) will be used to keep track of the day to day- and lab journal

• These journals are simply kept in the main branch