Conversation
pictures folded added containing .png for the article.
kieranjmartin
left a comment
kieranjmartin
left a comment
There was a problem hiding this comment.
some suggestions from todays meeting
white-paper/branching-strategies.qmd
Outdated
| 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. |
There was a problem hiding this comment.
maybe link to branch guide on github
There was a problem hiding this comment.
|
|
||
| ## 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. |
There was a problem hiding this comment.
maybe link to https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow there may be other resources
There was a problem hiding this comment.
I linked this one.
|
|
||
| ## 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. |
There was a problem hiding this comment.
maybe some extra words on how the copies are locked for a particular reporting event
white-paper/branching-strategies.qmd
Outdated
|
|
||
| ## 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. |
There was a problem hiding this comment.
sub branches normally called feature branches
white-paper/branching-strategies.qmd
Outdated
|
|
||
| ::: callout-caution | ||
| ## WIP | ||
|
|
There was a problem hiding this comment.
summary with positive and negatives and maybe some examples where one might be favoured over the other
There was a problem hiding this comment.
A table was added.
white-paper/branching-strategies.qmd
Outdated
|
|
||
| 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. | ||
|
|
||
|  |
There was a problem hiding this comment.
could just not lock? Add as suggestion
There was a problem hiding this comment.
I removed it from the diagram. Still I let one phrase about locking with a reference to the GitHub user guide.
white-paper/branching-strategies.qmd
Outdated
| ## WIP | ||
|
|
||
| Work in progress. | ||
| ::: |
There was a problem hiding this comment.
maybe add a section on how hot fixes might be applied for a specific milestone
There was a problem hiding this comment.
I added a part dedicated to hot fixes.
push still draft
Not ready yet for PR. _quarto.yml updated to have a specific "Recommendations" part. Different versons of flowcharts (mermaids, git). Will be clean.
2 participants
Closes #51.
Draft for now. Could you provide your ocmments?