51 git branching strategies

white-paper/_quarto.yml

@@ -9,6 +9,7 @@ book:
     - index.qmd
     - state.qmd
     - Challenges.qmd
+    - branching-strategies.qmd
     - audittrail.qmd
     - qcintegration.qmd
     - recommendations.qmd

white-paper/branching-strategies.qmd

@@ -0,0 +1,75 @@
+## Branching Strategies
+
+Defining a branching strategy can be tricky and requires to identify the needs of each repository. While there is no best branching strategies, this part provides a few examples of what could be considered as potential branching strategies.
+
+There is no need to define one single branching strategy for all of the repository of a company or institution. The choice should be made by type of activity.
+
+::: callout-caution
+### No explanation of what a branch is.
+
+\[alex:\] I assume the concept of branch, when and how to use its is defined in another part of the white paper.
+:::
+
+## Basic git structure
+
+The basic structure of a git repository relies on a principal branch called **main**, which will be duplicated in **sub-branches** that will in the end merged back to the main branch through a pull request.
+
+![basic git structure](pictures/bs-01.png)
+
+This branching strategy can be used in the case of a team working on a specific activity of a single clinical study within a repository.
+
+It could potentially be used for a study or a product with several distinct activities using flags (see [Branch locking and flagging](##%20Branch%20locking%20and%20flagging)).
+
+## Usage of a devel branch
+
+A devel branch is usually a development branch located between the main and other specific development branches. It is used to integrate multiple features and updated before all of those are merged with the main branch. The main objective is to ensure stability of interdependent updates. It is possible that two different features, which work fine in separate branches, may cause conflicts when merged into the same branch. The devel branch is used to integrate all updated features and make any necessary final adjustments before merging into the main branch. It's working as a safety net before the final merge to main.
+
+The figure below shows an example of the usage of the devel branch. The two feature branches are working without any problem separately, but removing ADAE.ARELGRP1 causes a conflict issue in the devel branch. This conflict should be resolved before merging into main.
+
+![branching strategy](pictures/bs-01b.png) 
+
+A devel branch is very useful in the following cases:
+
+-   Several of different people are working on the same time on different features
+
+-   The features can present interdependancies
+
+In the case of a single or a little group of persons working together, or when tasks have no interdependancies, the devel branch could be avoided.
+
+## One main branch duplicated per milestone
+
+Several clinical studies relies on the same base programs for several milestone, while some milestones require some specific programs. Storing everything in the main branch and duplicate it for the final step of a milestone is an option.
+
+![branching strategy](pictures/bs-01c.png) 
+
+## One main branch per milestone
+
+A single study often needs to deal with different activities, sometime happening at the same moment. One potential way to use git in theses cases could be to have:
+
+-   1 repository for the study
+
+-   **1 main branch per activity** (CSR, DMC #n, DSUR, etc)
+
+This branching strategy would allow to work separately on each activity, keeping them intact, but also to work on both at the same moment if needed. The following examples shows a repository dedicated to a single study with the 2 following main branches:
+
+-   CSR: for daily ongoing activities related to the CSR preparation
+
+-   DMC #1: specific milestone happening soon
+
+Two issues are handled at the same moment. Issue #1 is dedicated to an efficacy endpoint that should not be part of the DMC, while Issue #2 is stricly dedicated to the DMC activity and will not be part of the final CSR outputs.
+
+![branching strategy](pictures/bs-02.png) 
+
+### Common issue
+
+If something common to more than one of the main branches should be made, it is possible to make as much pull requests as requested. The only tricky part is to define the source branch. In this example, we take the CSR.
+
+![branching strategy](pictures/bs-03.png)
+
+## Branch locking and flagging
+
+::: callout-caution
+## WIP
+
+Work in progress.
+:::