Les bases de GIT#
Comme nous l’avons mentionné dans la section précédente, git gère l’évolution d’un ensemble de fichiers - appelé référentiel ou repo - de manière très structurée.
Repo#
Pour commencer, il est recommandé (pour ce cours, car nous allons coder avec R) de créer un projet RStudio : Dans “File / New Project,” sélectionner Version control puis GIT.
Il suffit ensuite de compléter les trois paramètres :
Repository URL : coller l’adresse SSH copiée depuis le GitHub git@github.com:nmeraihi/ACT3035git.git
Projet directory name : le nom du dossier où va sera la copie locale du repository, c’est là où vous allez modifier les programmes et où se situera votre code.
Create project as subdirectory of : le chemin physique où se situera le projet.
Cliquer sur Create project.
Les commandes de base#
Il existe trois principales fonctionnalités dans GIT , définies par leur nom de commande :
git branch : création d’une branche
git checkout : pour changer de branche
git merge : fusion de branche
De manière plus précise, il y a trois étapes avant d’envoyer les modifications validées (commit) au dépôt. Elles se définissent en fonction des commandes qui permet de les appliquer quand Git est utilisé en ligne de commandes :
diff: inspection des modifications. Cela permet de comparer les fichiers modifiés et de distinguer les fichiers ajoutés ou supprimés.staging area: sélection des modifications.commit: validation des modifications sélectionnées (avec commentaire).
Lors d’un commit, le message de validation est très important:
il décrit brièvement les modifications contenues dans le
commitil s’adresse aux autres et doit donc être intelligible
Chaque commit doit rassembler des modifications homogènes. Il ne faut donc pas hésiter à séparer les changements qui ne sont pas directement reliés, car il est plus facile de rechercher au sein de plusieurs modifications différentes qu’une seule trop vaste.
Chaque commit est identifié de façon unique par un hash (ex: 2d176d25afc13e79c067de6822647b80db9c2b53), un numéro peu intelligible pour un humain mais qui permet au système de contrôle de version de gérer proprement chaque modification.
Ensuite, les deux fonctions push et pull permettent la mise à jour du projet local par rapport au distant et réciproquement. C’est donc avec un push qu’on envoie les modifications qui ont été sélectionnées puis validées.
Lors des étapes de push et pull, des conflits peuvent apparaître, par exemple lorsque deux personnes ont modifié le même programme simultanément.
Danger
Danger
Ne jamais ⛔️ utiliser git push --force. Cette commande peut définitivement endommager votre projet.
Commandes git communes#
clone#
Nouveau repo git local à partir d’un repo sur GitHub :
git clone https://github.com/nmeraihi/ACT3035git.git
remote –verbose#
Vérifiez que le remote a été clonée avec succès :
git remote --verbose
add et commit#
Effectuer des changements locaux, commit:
git add foo.txt
git commit --message "Ajout de message"
status et log#
Vérifiez l’état de Git :
git status
git log
git log --oneline
diff#
Comparez les versions :
git diff
remote add#
Ajouter un remote au repo local existant :
git remote add origin https://github.com/nmeraihi/ACT3035git.git
git remote --verbose
git remote show origin
push –set-upstream#
Poussez le main local vers le main de GitHub et faites en sorte que le main local suive le main sur GitHub :
git push --set-upstream origin main
# forme abrégée
git push -u origin main
# vous ne devez paramétrer le suivi en amont (upstream) qu'une seule fois !
git push#
Un push régulier:
git push
git pull#
Pull les commits de GitHub :
git pull
Pull les commits et ne les laissez pas vous mettre dans un pétrin de conflit de merge :
git pull --ff-only
git fetch#
Récupérer les commits (Fetch commits)
git fetch
git branch#
Créer une autre branche
git branch [branch-name]
git checkout#
Passer à une autre branche
git checkout [branch-name]
suivi à distance#
Vérification du suivi à distance des branches
git remote -v
git remote show origin
git branch -vv