s'il existe une possibilité que le serveur ait reçu un push venant d'ailleurs: git pull (avec la précaution ci-dessous), ceci pour éviter de subir un merge forcé
(si le serveur n'est pas en avance, ce pull ne fera rien de mal)
Avant un commit :
git status pour vérifier qu'il ne reste pas un fichier source utile dans les "untracked"
git log pour vérifier que HEAD pointe bien sur la branche qu'on veut prolonger
Avant un push :
git log pour vérifier que le dernier commit est irréprochable, car il reste une chance de l'amender
Avant un pull :
git status pour vérifier qu'il n'y a pas de modification en attente d'un commit.
Si c'est le cas, il faut cacher ou abandonner ces modifications avant le pull
pour abandonner une modif, git checkout -- nom_fichier
pour cacher une modif on peut déplacer le fichier ailleurs et abandonner la modif (comme ci-dessus),
ou utiliser git stash, qui fait la même chose mais encombre l'historique
Avant un checkout vers un commit passé :
Comme pour un pull
Le stockage des credentials permet d'éviter d'avoir à saisir nom d'utilisateur et mot de passe à chaque accés au serveur
(push, et pull si le repo n'est pas public.
La distribution de GIT pour Windows (en 2018) offre une seule possibilité, peu documentée, de stockage de credentials,
dite manager.
git config -l
credential.helper=manager
Ce "manager" délègue le stockage des credentials au système d'exploitation.
On peut accéder à ce stockage via le "Gestionnaire d'identification" de Windows:
Panneau de Configuration --> Utilisateurs --> Gestionnaire d'Identification --> Identif. Windows
La saisie des credentials se fait automatiquement lors de la première connexion.
Si on souhaite temporairement changer d'identité sur un serveur, on peut désactiver le manager pour le repo courant : git config credential.helper ""
Et le réactiver plus tard : git config credential.helper manager
Après avoir créé un compte d'utilisateur, on peut créer des repositories
gratuitement à condition que leur contenu soit lisible par le public.
L'interface web donne accés aux données aux moyen d'URLs de la forme: https://github.com/nom_utilisateur/nom_repo
Aprés avoir créé un repo, on peut le peupler depuis un repo local: git remote add origin https://github.com/my_name/my_repo git push -u origin master git push --all s'il y a d'autres branches git push --tags s'il y a des tags
cliquer sur un fichier
cliquer sur history pour avoir la liste des commits qui le concernent
cliquer sur le compteur de commits pour acceder à l'historique de la branche courante
cliquer sur le message ou le hash d'un commit pour voir les diff
cliquer sur < > pour explorer le working tree à l'époque de ce commit
cliquer sur le compteur de branches
cliquer sur la branche pour explorer le working tree au dernier commit de cette branche
cliquer sur le compteur de releases
ce sont les tags ! on peut avoir un zip du code pour chaque release
cliquer sur Insights --> Network: on a le graphe des branches, il montre aussi les forks (ne pas confondre)
draguer la timeline à droite ou à gauche pour tout voir
Après avoir créé un compte d'utilisateur, on peut créer des projets.
Chaque projet contient automatiquement un et un seul repository GIT, et peut aussi faire
l'objet d'autres services.
L'interface web donne accés aux données aux moyen d'URLs de la forme: https://gitlab.com/nom_utilisateur/nom_projet
Aprés avoir créé un projet, on peut peupler son repository de la même manière qu'avec github
cliquer sur un fichier
cliquer sur history pour avoir la liste des commits qui le concernent
cliquer sur le compteur de commits pour acceder à l'historique de la branche courante
cliquer sur le message ou le hash d'un commit pour voir les diff
cliquer sur l'icône "folder" à droite pour explorer le working tree à l'époque de ce commit
cliquer sur le compteur de branches
cliquer sur la branche pour explorer le working tree au dernier commit de cette branche
cliquer sur le compteur de releases
ce sont les tags ! on peut avoir un zip du code pour chaque release
cliquer sur le menu: Repository --> Graph: on a le graphe des branches
Le propriétaire d'un repo sur github peut autoriser des contributeurs à faire des modifications sur ce repo (seulement).
Chaque contributeur doit déjà avoir un compte sur le serveur.
La procédure comprend 2 phases :
Inviter un contributeur (menu Settings du repo)
Attendre que celui-ci réponde à l'invitation, qu'il reçoit sous forme de notification sur son compte github
Pour éviter des merges trop fréquents, il est habituel de laisser chaque
contributeur préparer sa contribution sur une branche distincte.
Lorsque son travail est prêt, le contributeur peut inviter de leader du projet à merger sa branche dans la branche principale.
Github fournit un mécanisme pour émettre une pull request à cet effet.
Le propriétaire d'un projet sur gitlab peut enregistrer des membres dans le but de les autoriser à faire des modifications sur
certaines branches de ce projet.
Chaque membre doit déjà avoir un compte sur le serveur.
La procédure comprend 2 phases :
Référencer un membre dans le projet (menu Settings -> Members du projet) avec le statut de développeur
Désactiver la protection des branches que ce développeur devra modifier (la protection des branches est une particularité
de gitlab, par défaut la branche master est protégée)
Lorsque son travail est prêt, le contributeur peut émettre une merge request dans le but d'inviter de leader du projet
à merger sa branche dans la branche principale.
En créant un repository avec un nom tel que nom_utilisateur.github.io , il est possible de créer un site
HTML statique, hébergé par github à l'URL https://nom_utilisateur.github.io.
le contenu du site est géré via GIT
il peut contenir un nombre arbitraires de pages html, css, images, sous-répertoires
l'encodage utf-8 semble obligatoire, HTML5 est recommandé
l'encombrement total est limité (1Gb fin 2019)
un seul site par utilisateur enregistré sous github.com
comme pour n'importe quel repo public, les internautes peuvent récupérer l'archive du site sur
https://github.com/nom_utilisateur/nom_utilisateur.github.io/archive/master.zip pour consultation hors-ligne
Dans le repository d'un projet gitlab, il est possible de placer des pages HTML dans un répertoire public pour qu'elles soient
hébergées par gitlab à l'URL https://nom_utilisateur.gitlab.io/nom_projet.
Un script .gitlab-ci.yml doit être inclus pour activer le déploiement des documents du projet sur le site.
La méthode la plus simple pour l'obtenir est de créer le projet à partir du template Pages/Plain HTML.
le contenu du site est géré via GIT, ce contenu peut être créé sur plusieurs projets gérés indépendamment
il peut contenir un nombre arbitraires de pages html, css, images, sous-répertoires
l'encodage utf-8 semble obligatoire, HTML5 est recommandé
l'encombrement est limité (10Gb par projet fin 2019)
si le projet est public, les internautes peuvent récupérer l'archive des pages sur
https://gitlab.com/nom_utilisateur/nom_projet/-/archive/master/nom_projet-master.zip pour consultation hors-ligne
Si on efface TOUS les fichiers et répertoires du working-tree, est-ce que GIT peut tout reconstituer à partir de l'historique
(répertoire .git) ?
Oui bien sûr à l'aide de la commande checkout !
Cependant il y a un petit détour, en effet si le working-tree comporte des changements par rapport au dernier commit,
checkout évitera de reconstituer ce qui serait en conflit avec ces changements.
Pour obtenir le résultat souhaité, il faut forcer la reconstitution avec la commande checkout au niveau fichier.
Syntaxe générale : checkout <nom_de_branche_ou_commit_ou_tag> <nom_de_fichier>
exemple : checkout master '*' ou généralement checkout -- '*'
N.B. L'argument '*' désigne tous les fichier et dossiers archivés, les simple quotes sont
requises pour que ce soit GIT et non le shell qui interprête le symbole *.
Pour être sûr que les tags soient cohérents avec les numéros de version inclus dans le code source, on peut utiliser un script
pour le shell bash. Beaucoup de solutions sont possibles, voici un exemple qui effectue le commit après
avoir lu le numéro de version dans le code source
#! /bin/bash
v=V$(grep -P -o '#define\s+VERSION\s+[0-9.]*' src/version.h | grep -o '[0-9.]*')
git commit -a -m "Version "$v
echo creation tag $v
git tag $v
Cet exemple utilise des expressions régulières pour extraire le numéro de version au moyen de l'utilitaire Unix
grep.
