Foire aux questions - Git

Un ensemble de réponses à un ensemble de questions naturelles sur Git

Visualiser l’état du dépôt

La commande suivante permet de visualiser l’état du dépôt :

git status

Selon l’état dans lequel se trouve le dépôt, il est possible d’obtenir une somme d’informations comme :

On branch master
•Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

•Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   README.txt

•Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   authors.txt

•Untracked files:
  (use "git add <file>..." to include in what will be committed)

        liste_des_courses.txt

Git est un logiciel assez prévenant, et il est donc possible de voir ici 4 items (mis en évidence par les ‘•’) :

Gérer un conflit

Du fait de la présence de multiples dépôts dans lesquels le code peut être modifié, il est possible que la même branche master ait divergé entre deux dépôts (typiquement avec la même branche sur un dépôt distant, comme origin/master). Dans ce cas, une fusion/merge risque d’amener à un conflit. Il convient de ne surtout pas paniquer, cela fait partie des tracas standards du développement logiciel.

Mettons que la dernière fusion/merge ait amené au résultat suivant :

Auto-merging authors.txt
CONFLICT (content): Merge conflict in authors.txt
Automatic merge failed; fix conflicts and then commit the result.

Un conflit peut aussi être visualisé à l’aide de la commande git status, qui devrait indiquer :

On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   authors.txt

no changes added to commit (use "git add" and/or "git commit -a")

Il faut bien noter que l’opération de fusion/merge ne s’est pas terminée (“no changes added to commit”). Git vous met dans un état où il est possible de l’assister à terminer cette fusion correctement.

Pour chaque fichier en conflit, appliquer la procédure suivante :

  1. Ouvrir le fichier dans un éditeur (dans notre exemple authors.txt).

  2. Rechercher dans l’éditeur les blocs de la forme suivante :

    <<<<<<< HEAD
David, le programmeur extrémiste.
=======
David, le programmeur de l'extrême.
>>>>>>> origin/master

    Git a modifié de lui-même le fichier pour inclure, aux endroits qui lui semblaient différents, les deux versions. Il est facile de rechercher ces blocs car les marqueurs <<<<<<<, ======= et >>>>>>> ne sont quasiment jamais utilisés.

    • La zone délimitée par <<<<<<< et ======= représente la version locale du code (branche master).

    • La zone délimitée par ======= et >>>>>>> représente la version distante du code (branche origin/master).

  3. Modifier le code de manière à éliminer tous les marqueurs.

    Il est ainsi facile de choisir une version des deux versions à garder, ou de faire une sorte de mélange des deux si besoin.

  4. A la fin des modifications, ajouter le code au commit (ici le fichier en conflit)

    git add authors.txt

  5. Une fois tous les fichiers en conflit gérés, terminer la fusion (un message de commit est généré automatiquement) :

    git commit

Récupérer un état catastrophique

Il est toujours possible de se retrouver dans une situation dans laquelle continuer à faire des commandes git est difficile ou met en péril l’état du code source sur lequel on travaille. Il peut s’agir en particulier :

La procédure suivante consiste à reprendre la dernière version du dépôt sur la forge, y copier ses modifications et les committer. Si vous l’appliquez à la lettre, elle assure de ne perdre aucune information pour ce qui est du code. Dans les exemples de commandes, la procédure fait l’hypothèse que le dépôt s’appelle chabadabada.

Si vous en arrivez à cette appliquer cette procédure, c’est forcément après avoir vérifié qu’il n’existait pas une méthode moins grossière pour sauver votre travail de développement.

  1. Se placer dans le répertoire parent du répertoire correspondant à votre dépôt, et le renommer.

    mv chabadabada chabadabada.old

  2. Recréer une version du dépôt local.

    git clone https://<user>@thor.enseirb-matmeca.fr/git/chabadabada

  3. Copier les données de l’ancien dépôt dans le dépôt nouvellement créé.

    cp -R chabadabada.old/* chabadabada/

  4. Communiquer les modifications dans le dépôt distant.

    cd chabadabada/
git commit -m -a "Récupération catastrophique"
git push origin

A la fin de la procédure, le dépôt chabadabada contiendra la dernière version du code du dépot initial. Tous les commits intermédiaires auront été perdus. Les fichiers supprimés du dépôt entre temps devront être supprimés à nouveau. Si vous estimez ne plus avoir besoin des vieux commits, vous pouvez après coup supprimer le dépôt chabadabada.old.

Renommer les auteurs des commits

Cette procédure permet de modifier les noms et emails d’utilisateurs de certains commits. Dans le cas où ces commits sont rejetés par la forge, elle permet de récupérer une situation mal engagée. Dans tous les cas, commencez par configurer votre dépôt et n’appliquez cette procédure qu’après avoir fait une copie dudit dépôt.

Commencez par compter combien et quels sont les commits fautifs :

Modifier des commits passés

Cette procédure permet de modifier entièrement un ensemble de commits n’ayant pas encore été poussés sur la forge. Dans le cas où ces commits sont rejetés par la forge. Dans tous les cas, commencez par configurer votre dépôt et n’appliquez cette procédure qu’après avoir fait une copie dudit dépôt.

Commencez par compter combien et quels sont les commits fautifs :

Se connecter à son dépôt

Les utilisateurs de machines personnelles possèdent une configuration propre qui est parfois différente de celle des machines de l’école. En particulier, leur login peut différer. Pour éviter ce genre de problème, lorsqu’on clone un dépôt, on référence usuellement le login dans l’URL de connexion :

git clone https://<user>@thor.enseirb-matmeca.fr/git/chabadabada

Il est aussi possible de positionner cette information après coup, en modifiant le fichier .git/config à l’intérieur de son dépôt :

[remote "origin"]
        url = https://<user>@thor.enseirb-matmeca.fr/git/chabadabada
        fetch = +refs/heads/*:refs/remotes/origin/*

Noter que les informations pour se connecter sur un serveur sont propres au serveur. Ainsi, le mot de passe utilisé pour se connecter à la forge de l’école est le même que celui pour se connecter sur les machines de l’école (et pas son mot de passe personnel par exemple).

Configurer son usage de git

Il est possible de configurer un certain nombre de préférences pour l’utilisation de tous ses dépôts git. Le fichier de configuration est usuellement placé dans son répertoire personnel comme $HOME/.gitconfig. En cas de perte de son fichier, ou pour revenir à une configuration initiale, il suffit d’appliquer :

ssh <login_enseirb>@ssh.enseirb-matmeca.fr /net/ens/renault/local/bin/init-gitconfig.sh > ~/.gitconfig

Le fichier .gitconfig est un fichier texte de la forme suivante :

[http]
        sslVerify = false
[color]
        ui = auto

Il est parfaitement possible de modifier ce fichier dans un éditeur, mais il est aussi possible de le faire à l’aide de la commande suivante :

git config --global color.ui "auto"

Si la commande précédente ne comporte pas le --global, et qu’elle est effectuée depuis un dépôt git, alors la configuration ne concernera que ce dépôt.

Parmi les préférences que l’on peut définir dans ce fichier, il y en a deux qui sont particulièrement importantes :

Sans ces deux préférences, git fera des choix automatiques au moment de communiquer les révisions, et ces choix sont moins que judicieux. N’oubliez donc pas de positionner ces variables correctement.

Tout dépôt GIT utilisé sur la forge de l’ENSEIRB ne peut être utilisé qu’avec une configuration correcte, à savoir un nom d’utilisateur valide et un email propre à l’école. Toute utilisation du dépôt en dehors de ces conditions d’utilisation pourra être rejetée.

Les éléments qui sont testés actuellement sont le nom de la personne réalisant le commit et son adresse mail. Le script init-gitconfig.sh décrit ci-dessus génère un fichier de configuration acceptable.

Ignorer la présence de fichiers

Le fichier .gitignore à la racine du dépôt permet de lister les fichiers que Git va ignorer, à savoir ceux qui n’apparaîtront pas dans la section Untracked files lors des appels à la commande git status.

Un exemple de fichier .gitignore pour des projets en C :

# .gitignore -- List of files ignored by git
*.[oa]
*~

Étiqueter les commits

Il est possible d’étiqueter (tag) des commits particuliers en leur donnant un nom plus lisible que les commits classiques. Ces étiquettes permettent ainsi de mettre en valeur des commits correspondant à des versions intéressantes (par exemple correspondant à la version finale du code). Il existe dans git deux types d’étiquettes :

Typiquement, la commande suivante permet de créer un tag local nommé version-1.0 :

git tag version-1.0

L’étiquette reste locale, tant que l’on ne l’a pas versée dans un dépôt distant. Pour cela, il suffit de faire :

git push origin version-1.0

Une fois un tag disponible dans un dépôt, il devient possible de récupérer la version correspondante simplement avec son nom :

git checkout version-1.0

Enfin, la commande suivante affiche la liste des tags existants :

git tag # Display the list of available tags

Pour des informations complémentaires, consulter la man page de git tag et la page de documentation du livre Pro Git.

Pour aller plus loin …

Il est bien évident que cette page passe sous silence un nombre de détails gigantesques quant à ce logiciel tentaculaire qu’est git, et c’est pourquoi il est possible de trouver d’autres sources de documentations plus génériques et/ou plus avancées en se référant à :