label3 [shape='box', label='ligne 30: je change ça', fillcolor='transparent', color='transparent', fontcolor='#000000']
label3 -> 3 [color='black', minlen=0.2]
label4 [shape='box', label='ligne 30: je change ci', fillcolor='transparent', color='transparent', fontcolor='#000000']
label4 -> 4 [color='black', minlen=1]
label6 [shape='box', label=<Je ne suis qu\'un logiciel,<BR/>je ne sais pas quoi choisir !>, fillcolor='transparent', color='transparent', fontcolor='#000000']
6 -> label6 [color='black', minlen=0.2]
}")
widgetframe::frameableWidget(gitconflict)
```
---
# Les branches
#### A quoi ressemble un conflit ?
```{bash, eval=FALSE}
<<<<<<< HEAD:fichier.R
J'avais mis ça avant dans une branche
======
...
...
@@ -639,10 +669,8 @@ Et maintenant j'ai ça, je ne suis qu'un logiciel je ne sais pas quoi faire
>>>>>>> iss53:fichier.R
```
Il faut choisir entre les 2 versions pour pouvoir finaliser le merge
--
---
# Les branches
#### Merge request/pull request (sur une forge)
Crée une demande de rajout de code.
...
...
@@ -656,7 +684,6 @@ Superviser les "merge" à l'intérieur d'un projet ou permet à une personne ext
Vocabulaire : `merge request` chez GitLab VS `pull request` chez GitHub
---
# Les forges à votre disposition
...
...
@@ -672,33 +699,148 @@ Vocabulaire : `merge request` chez GitLab VS `pull request` chez GitHub
---
## Possibilités (pour des statisticiens)
# Possibilités (pour des statisticiens)
#### Publication/partage du code
```{css, echo = FALSE}
.tiny .remark-code { /*Change made here*/
font-size: 70% !important;
}
```
--
.left-column[
- .h3space[Publication, Partage du code]
#### Nouvelle branche = une nouvelle méthode/nouvelle hypothèse/nouveau jeu de données
- **Branches**
--
- **GitLab pages, GitHub pages**
#### GitLab pages/GitHub pages
Faire des sites webs très facilement ! avec juste un fichier [yml](#yml) à la racine du dépôt
- **CI/CD (integration continue)**
Exemple : j'ai un projet qui crée un fichier html à l'aide de Rmarkdown. --> Si j'active gitlab pages je peux en faire un site web.
#### Exemple de fichier yml (nom de fichier = ".gitlab-ci.yml") :
#### Enseignement
Un projet "principal" forké (`git fork`) par les étudiants qui partent de la même copie et faire leurs propres modifications, indépendemment les un des autres.
.tiny[
```{yml, eval=FALSE}
pages:
stage: deploy
# Je place le nécessaire dans un dossier public/
script:
- mkdir public
- cp -r presentation/* public
artifacts:
paths:
- public
# Je fais tout ça uniquement sur la branche main
only:
- main
```
]
]
---
# Possibilités (pour des statisticiens)
.left-column[
- **Publication, partage du code**
- **Branches**
- **GitLab pages, GitHub pages**
- .h3space[CI/CD (integration continue)]
- **Enseignement**
]
.right-column[
</br></br></br></br></br></br></br></br>
Compiler ses rapports automatiquement.
Faire des tests automatiques (ex. `R cmd CHECK`, lancer des tests unitaires, ...).
Attention, c'est fait à chaque "push" --> Est-ce toujours utile ?
Un projet "principal" forké (`git fork`) par les étudiants qui partent de la même copie et peuvent faire leurs propres modifications, indépendemment les un des autres.