Structuration de projets de science des données - Laboratoire

Objectif du laboratoire

Cloner le dépôt privé de portfolio préparé par l’équipe enseignante, comprendre la structure fournie, produire une première trace personnelle et synchroniser les premiers commits.

La personne étudiante ne crée pas un nouveau dépôt GitHub. Elle travaille dans la copie privée du modèle qui lui a été attribuée sous le nom portfolio-stt4230-IDUL ou portfolio-stt6230-IDUL, selon son sigle d’inscription.

Résultat attendu

À la fin du laboratoire, le dépôt contient au minimum:

portfolio-sttSIGLE-IDUL/
  README.md
  .gitignore
  portfolio-stt4230-6230.Rproj
  semaines/
    semaine-01/
      README.md
  scripts/
    diagnostic.R

Le modèle fournit déjà README.md, .gitignore, portfolio-stt4230-6230.Rproj et semaines/semaine-01/README.md. La personne étudiante complète ces fichiers et ajoute scripts/diagnostic.R.

Étape 1 - Repérer le dépôt attribué

1. Se connecter à GitHub avec le compte communiqué à l’équipe enseignante.
2. Ouvrir l’organisation STT-4230-6230.
3. Repérer le dépôt privé portfolio-stt4230-VOTRE-IDUL ou portfolio-stt6230-VOTRE-IDUL, selon le sigle d’inscription.
4. Vérifier que l’identifiant dans le nom du dépôt est le bon.

Ne pas utiliser le bouton de copie du modèle et ne pas créer un dépôt parallèle.

Étape 2 - Cloner le dépôt

Depuis le dossier dans lequel vous conservez vos projets de cours, exécuter:

git clone git@github.com:STT-4230-6230/portfolio-sttVOTRE-SIGLE-VOTRE-IDUL.git
cd portfolio-sttVOTRE-SIGLE-VOTRE-IDUL
git status
git remote -v

Remplacer VOTRE-SIGLE par 4230 ou 6230, selon l’inscription, et VOTRE-IDUL par l’identifiant présent dans le nom du dépôt attribué.

Vérifier ensuite que:

• git status ne signale aucune modification inattendue;
• le dépôt distant origin pointe vers le dépôt attribué dans l’organisation du cours;
• les quatre fichiers du modèle sont présents.

Si le clonage échoue

Ne pas utiliser git init et ne pas créer un autre dépôt GitHub. Conserver plutôt:

• l’adresse exacte du dépôt tenté;
• la commande exécutée;
• le message d’erreur complet;
• le nom d’utilisateur GitHub utilisé;
• l’IDUL attendu dans le nom du dépôt.

Ne jamais copier une clé SSH privée ou un jeton d’accès. Pendant que l’équipe enseignante vérifie l’attribution, le diagnostic R peut être exécuté dans un fichier temporaire. Une fois l’accès corrigé, cloner le dépôt attribué et y ajouter le travail réalisé.

Étape 3 - Personnaliser le README

Ouvrir README.md et compléter le champ Nom au début du fichier. Lire ensuite les sections sur le travail hebdomadaire, les jalons et les vérifications avant un commit.

Vérifier la modification:

git status
git diff -- README.md

Créer un premier commit personnel:

git add README.md
git diff --staged
git commit -m "Personnaliser le portfolio"

Étape 4 - Ajouter le diagnostic technique

Créer le dossier scripts/, puis le fichier scripts/diagnostic.R.

mkdir -p scripts

Placer le code suivant dans scripts/diagnostic.R:

# Diagnostic technique de départ pour STT-4230 / STT-6230

check_command <- function(command, args = "--version") {
  result <- tryCatch(
    system2(command, args = args, stdout = TRUE, stderr = TRUE),
    error = function(error) {
      paste("Non trouvé ou non accessible:", conditionMessage(error))
    }
  )

  paste(result, collapse = "\n")
}

diagnostic <- list(
  r_version = R.version.string,
  platform = R.version$platform,
  system = Sys.info()[c("sysname", "release", "machine")],
  working_directory = getwd(),
  git = check_command("git"),
  quarto = check_command("quarto")
)

print(diagnostic)

Exécuter le script depuis la racine du dépôt:

source("scripts/diagnostic.R")

Si une commande échoue, conserver le message complet pour la trace de la semaine 1.

Étape 5 - Compléter la trace de la semaine 1

Ouvrir semaines/semaine-01/README.md et remplacer les indications du modèle par une trace personnelle. Elle doit préciser:

• que le laboratoire de démarrage constitue le point de départ;
• que scripts/diagnostic.R a été produit;
• quelles vérifications ont réussi;
• quelle difficulté subsiste, s’il y en a une;
• quelle sera la prochaine action avant la semaine 2.

Ne pas supprimer les rubriques du modèle. Les compléter de manière concise et factuelle.

Étape 6 - Faire un second commit lisible

git status
git diff
git add scripts/diagnostic.R semaines/semaine-01/README.md
git diff --staged
git commit -m "Ajouter le diagnostic de la semaine 1"

Les messages peuvent être adaptés, mais chaque commit doit correspondre à une intention compréhensible.

Étape 7 - Pousser et vérifier sur GitHub

git push

Ouvrir ensuite le dépôt sur GitHub et vérifier que les deux commits personnels et les fichiers modifiés sont visibles.

Si git push échoue, ne pas supprimer le dépôt local ni recommencer le travail. Conserver les commits locaux, noter le message complet dans semaines/semaine-01/README.md et demander de l’aide avec les faits observés.

Ce qui doit être terminé

Avant de quitter le laboratoire, chaque personne doit avoir:

• cloné le dépôt privé qui lui a été attribué, ou documenté précisément le problème d’accès;
• complété son nom dans le README.md;
• ajouté et exécuté scripts/diagnostic.R, ou documenté son erreur;
• complété semaines/semaine-01/README.md;
• créé au moins un commit personnel lisible;
• poussé ses commits, ou documenté précisément le blocage.

Le second commit et la configuration SSH peuvent être régularisés après la séance si un problème technique réel a été documenté.

Vérification finale

Avant de quitter:

• git remote -v pointe vers le dépôt attribué;
• git status ne contient pas de surprise;
• le README.md identifie la personne étudiante;
• la trace de semaine 1 correspond au travail réellement effectué;
• aucun secret, jeton d’accès ou fichier confidentiel n’a été ajouté;
• les commits personnels sont visibles sur GitHub, lorsque la synchronisation fonctionne.