Problèmes fréquents Git

Ce chapitre complète l'enseignement Git en donnant des indices ou des corrections pour tous les problèmes entendus en séance de TP et en projet.

A priori, ce chapitre est plutôt là pour vous aider à résoudre des problèmes plus tard. Sa lecture avant d'avoir expérimenté (et fait des erreurs) avec Git n'est pas utile.

Info

Si vous avez un problème qui n'a pas de solution décrite ici, signalez-le.

Fichiers à ignorer

Il est parfois difficile au début de savoir s'il faut ignorer un fichier ou pas. Nous traitons ici les cas Eclipse, IntelliJ, NodeJS et Android Studio

Pour Android Studio, ne faites rien: Android Studio crée automatiquement un fichier .gitignore qui est très bien. Utilisez le tel quel.

Pour IntelliJ, il faut ignorer les répertoires .idea/ et out/.

Si vous utilisez NodeJS, alors il faut ignorer le répertoire node_modules/.

Pour Eclipse, la question qui se pose est: faut-il mettre dans le dépôt Git les fichiers de description du projet, à savoir le .project et le .classpath. Ces deux fichiers dépendent de la configuration de votre machine et pourront perturber vos collaborateurs, surtout si vous avez un mélange de machines Windows, Mac et Linux dans le projet. Ignorez ces deux fichiers.

Cela veut dire que quand vous récupérerez la première fois un répertoire où il y a un projet eclipse, eclipse ne le verra pas comme un projet et il faudra que vous l'importiez.

voir la vidéo

Enlever des fichiers inutiles

Comment faire si vous avez ajouté des fichiers dans un dépôt, et vous découvrez qu'il aurait fallu les ignorer.

Étape 1: ajoutez le nom des fichiers à ignorer dans .gitignore

Étape 2: faites git rm --cached sur les fichiers

Étape 3: faites git commit et vérifiez

La vidéo ci-dessous traite un exemple avec un projet eclipse dont tout a été commit sans .gitignore.

Voir la vidéo

Renommer des fichiers

Si vous renommez un fichier via votre explorateur de fichier ou via mv, Git verra ce fichier comme effacé du dépôt. Faire un git addsur ce fichier reviendra à dire que le fichier est bien supprimé !

Pour renommer un fichier, passez par git mv fichier_old fichier_new

Erreurs de répertoires

voir la vidéo

Vous avez créé votre dépôt dans le répertoire du fichier .project, mais votre collègue a créé son dépôt dans un autre répertoire, soit le répertoire src, soit son répertoire racine ou workspace.

Vous avez tous les deux poussé dans un dépôt distant commun, et vous découvrez le problème en essayant de faire un merge. Vous vous attendez à un merge très difficile, or il ne se passe rien. Vous retrouvez après le merge vos deux projets dans des répertoires différents !

Que faire ?

étape 1: revenir à un état avec vos fichiers dans une branche et les fichiers de l'autre dans une autre branche.

Soit vous revenez en arrière parce que cet état existe déjà dans votre dépôt, car vous aviez déjà des branches séparées.
Soit vous n'aviez pas encore de branches, vous avez tout fait sous master, et il faut reconstituer deux branches séparées.
Créez deux branches moi et autre à partir de la branche master où il y a tous les fichiers.
git switch moi
Vous voyez tous les fichiers
Dans la branche moi, détruisez tous les fichiers de votre collègue par git rm.
Il peut rester des fichiers qui sont ignorés et des répertoires vides que Git ne gère pas, à supprimer manuellement.
Vous ne voyez plus que vos fichiers
git commit -a -m "message pertinent"
git switch autre
Vous voyez de nouveau tous les fichiers
Dans la branche autre, détruisez tous vos fichiers par git rm.
Il peut rester des fichiers qui sont ignorés et des répertoires vides que Git ne gère pas, à supprimer manuellement.
Vous ne voyez plus que les fichiers de votre collègue.
git commit -a -m "message pertinent"

Vous êtes maintenant revenus à l'état où nous pouvons faire le déplacement des fichiers dans une des deux branches.

Le but est donc de déplacer les fichiers d'une branche pour que les deux branches aient des fichiers avec les mêmes noms dans les mêmes répertoires.

Choisissez celle des deux branches dont vous voulez garder la structure de répertoire, par exemple c'est la branche moi qui a les bons répertoires.

Mettez-vous dans la branche autre, par git switch autre.
Faites git mv sur tous les fichiers et répertoires jusqu'à obtenir la même structure que dans la branche moi.
Faites git commit quand la structure est la même.

C'est fini. Vous pouvez maintenant faire un merge pertinent entre les deux branches.

Voir la vidéo

Unrelated Histories

Vous voulez faire un merge avec la branche de votre binôme, et Git vous envoie un message contenant 'unrelated histories' et refuse de faire le merge.

Que se passe-t-il ?

vous avez tous les deux fait git init
vous avez tous les deux fait un premier git commit puis git push sur le dépôt distant

Vous avez donc créé deux commits non liés entre eux et poussé deux points de départ de branche sur le dépôt distant.

Si vous n'avez pas créé de branche avant de pousser, alors le second qui a poussé a dû créer une autre branche que master pour pousser. En essayant de faire le merge, vous avez un message "refusing to merge unrelated histories".

Vous pouvez forcer Git à faire un merge. Commencez par vérifier que les structures de répertoire sont les mêmes des deux cotés, et que les fichiers ont le même nom s'ils doivent être fusionnés.

Puis faites la commande:

git merge master2 --allow-unrelated-histories

Comme vous pouvez imaginer, cette option a un gros potentiel de confusion si vous l'utilisez n'importe comment. Donc faites bien les vérifications.

Répertoire Git dans répertoire Git

Vous avez fait git init dans un répertoire puis git init ou git clone dans un sous-répertoire et vous ne savez plus quoi faire.

Mettez-vous dans le répertoire qui est dans l'autre répertoire. Faites git status. S'il y a des modifications, voyez si elles doivent être sauvegardées.

Si le sous-répertoire interne contient des modifications et est un clone, alors il a un dépôt distant:

Commencez par déplacer le répertoire interne en dehors du répertoire externe
Puis les modifications peuvent être commit et push.

Si le répertoire interne contient des modifications et n'a pas de dépôt distant (remote), alors il faut:

sauver ces modifications d'une manière autre (copie du répertoire, zip...).
supprimer le répertoire interne ou le déplacer en dehors de l'autre répertoire.

Si vous aviez ajouté le répertoire interne dans le Git du répertoire externe, alors il faut commit la suppression du répertoire interne dans le Git du répertoire externe.