Questions fréquentes

Cela peut être le cas pour modules/client/exe/SAINETV4.exe. Cela signifie que git-lfs n’a pas été installé correctement. Une fois installé, il faudra supprimer le fichier et faire un:

git checkout .

Voir également cet article à propos de git-lfs.

J'ai fait des commits dans plusieurs branches, mais je ne les vois pas sur GitLab.

Il faut publiquer (push) dans toutes les branches que vous avez modifiées. Par défaut, un git push ne publie les commits que dans la branche courante.

Comment savoir si j'ai publié ?

En utilisant la commande suivante:

git status

Switched to branch 'fix/sainet/fix-conflict'
Your branch is ahead of 'origin/fix/sainet/fix-conflict' by 2 commits.
  (use "git push" to publish your local commits)

Dans le cas ci-dessus, on voit clairement que 2 commits n’ont pas été publiés.

Lorsque tout est publié, la réponse obtenue est:

On branch fix/sainet/fix-conflict
Your branch is up-to-date with 'origin/fix/sainet/fix-conflict'.
nothing to commit, working tree clean

Comment annuler des modifications non committées ?

Attention: efface les modifications définitivement !

Pour annuler les modifications d’un fichier (qui n’a pas encore été committé):

git checkout <path/to/file>

Pour annuler toutes les modifications d’un répertoire récursivement:

git checkout <path/to/folder>

J'ai libéré ma Merge Request, mais j'ai encore des modifications à faire.

Si la Merge Request commence par le préfixe WIP:, alors elle n’est pas libérée et par conséquent il n’y a aucun problème (voir ici).

Si la Merge Request est effectivement libérée, il y plusieurs cas de figures:

La Merge Request/branche existe toujours et il s’agit juste d’une micro-modification à ajouter: il suffit commit puis push la modification. Elle sera automatiquement intégrée dans la Merge Request.
La Merge Request/branche existe toujours et plusieurs modifications sont encore nécessaires: retourner éditer la Merge Request pour ajouter le préfixe WIP: et ainsi éviter qu’elle ne soit intégrée dans le master.
La Merge Request/branche a déjà été intégrée dans le master et il s’agit d’une micro-modification à ajouter: faire la modification, commit puis push. Il vous faudra réouvrir une Merge Request sur GitLab. La branche n'aura pas les dernières modifications du master.
La Merge Request/branche a déjà été intégrée dans le master et plusieurs modifications sont encore nécessaires: repartir dans le processus standard de création de branche.

J'ai committé dans une branche supprimée (Merge Request fermée).

Lorsqu’une Merge Request est intégrée dans le master, la branche est supprimée sur le serveur. Par contre, il se peut que vous l’ayez toujours en local sur votre machine et que par inadvertance (ou manque de rigueur), vous ayez committer des changements à l’intérieur.

Les commits ont été publiés (Synch/push)

Cela va recréer la branche sur le serveur avec vos nouvelles modifications. Vous devrez donc aller créer une nouvelle Merge Request pour qu’elles soient intégrées au master.

Les commits n’ont pas été publiés, mais concernent effectivement cette branche

Dans ce cas, le plus simple est effectivement de publier les commits et de recréer la Merge Request sur GitLab.

Les commits ne conernent pas cette branche

Vous avez committé sur la mauvaise branche.

Je veux annuler les x derniers commit.

Ne fonctionne que pour les commits qui n'ont pas encore été publiés (push) ! => argl, comment faire ?

Pour cette opération, il faut ouvrir un console git (Git Shell dans Windows) et aller dans le répertoire du projet.

Pour savoir le nombre de commits que l’on peut annuler simplement:

git status

On branch test/reset
Your branch is ahead of 'origin/test/reset' by 2 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

On voit dans ce cas que la branche est en avance (ahead) de 2 commits (donc ces 2 commits n’ont pas été publiés).

Pour annuler les 2 derniers commits, c’est la commande suivante:

git reset HEAD~2

Cela va garder les modifications qui y ont été faites (donc rien ne sera perdu). Il sera ensuite possible de les recommitter ensemble si besoin est.

Je veux annuler les x derniers commit, mais je les ai publiés.

Il y a deux possibilités: la première est de créer un commit de revert en effectuant les commande suivantes dans un Git Shell (s'assurer qu'il n'y a pas d'autres changements):

#revert les commits et les ajoute pour le prochain commit
git revert -n <commit1> <commit2> ...

#ces opérations sont optionnelles
#unstage les modifications ajoutées par le revert et voir les diffs
git reset HEAD
git diff

Il est possible de ne pas mettre l’option -n lors du revert, cela provoquera automatiquement un commit d’annulation qui n’aura plus qu’à être publié.

L’autre possibilité est de revenir en arrière et de forcer le push. Cela va remplacer la branche en ligne avec la branche locale. Attention: il faut être sur de ce que l'on fait car on risque de perdre des modifications !

# on récupère la branche en ligne pour être sur d'avoir la dernière version
git pull

# on revient 3 commits en arrière
git reset HEAD~3

# on force la mise à jour en ligne
git push --force

J'ai des modifications (non committées)

Vous êtes dans cet état si un git status vous montre une liste de fichier modifiés (qu’ils soient en attente de commit -staged- après un git add) ou pas.

Je suis sur le master (à jour)

Dans ce cas, il suffit de créer une branche directement via un git checkout puis committer et publier vos modifications.

git checkout -b <branch>
git add <fichiers>
git commit

# à ce moment git vous indique que la branche n'existe pas et donne la
# commande exact à taper avec l'option --set-upstream
git push

Une fois la branche poussée en ligne, il suffit de rafraîchir gitlab pour qu’il vous propose automatiquement la création d’une nouvelle Merge Request.

Je suis sur le master (en retard / pas à jour)

Il faut mettre les modifications en attente (les “stasher”), puis mettre à jour le master.

# enregistre vos modification en interne dans git, mais vous
# ne les voyez (temporairement) plus.
git stash

# mise à jour du master
git pull

# réapplication des modifications
git stash pop

A partir de là, vos modifications sont appliquées sur le master. Il suffit de vous référer à la partie précédente pour créer une branche.

Je suis sur une autre branche

De même que la partie précédente, il faut simplement “stasher” les modifications, puis se mettre sur le master pour les réappliquer.

git stash

git checkout master
git pull

git stash pop

A partir de là, vos modifications sont appliquées sur le master. Il suffit de vous référer à la partie précédente pour créer une branche.

J'ai committé sur la mauvaise branche.

Suivant l’état dans lequel votre repo se trouve (commits publiés ou non), cela va complexifier la tâche. Pour rappel, le 1er point de la checklist !

J’ai committé, mais pas publié

Deux cas possibles:

Vous n’avez pas besoin de garder l’historique: il suffit d’effacer les commits concernés, de changer de branche, puis de refaire un commit.
Vous avez fait plusieurs commits (tous non publiés) et vous souhaitez les récupérer dans une nouvelle branche: 2.1 Créer une nouvelle branche 2.2 Sélectionner la branche du point précédent:

git fetch
git checkout <branch-name>

2.3 Récupérer les commits qui ont été faits sur l’autre branche (attention à l’ordre)

git cherry-pick <commit1> <commit2> ...

2.4 Retourner sur la branche original et annuler les commit du point précédent

git checkout <orig-branch>
git revert <commit1> <commit2> ...

Ou bien s’il s’agit des n dernier commits:

git checkout <orig-branch>
git reset HEAD~n

J’ai committé et publié

Dans ce cas, vous ne pouvez pas simplement effacer les commits incriminés. Il va falloir faire des commits d’annulation. En gros, la procédure est la même que ci-dessus, sauf qu’au point 2.4 il faudra forcément faire un git revert.

Comment lancer le ssh-agent/add automatiquement?

Il faut d’abord créer le .bashrc sous le repertoire home.

~ sous linux.
C:\Users\<nom d'utilisateur> sous Windows.

Également vous pouvez taper echo ~ dans un terminal bash pour voir quel est le répertoire en question. Copiez-collez le script bash ci-dessous:

# Copied from https://help.github.com/articles/working-with-ssh-key-passphrases
env=~/.ssh/agent.env

agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }

agent_start () {
    (umask 077; ssh-agent >| "$env")
    . "$env" >| /dev/null ; }

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
    echo "Requesting permission for ssh..."
    ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
    echo "Requesting permission for ssh..."
    ssh-add
fi

unset env

Il faut faire attention à ce que les variables ne soient pas les mêmes si votre .bashrc contient déjà quelque chose. Si votre clé privée n’est pas dans le répertoire par défaut ~/.ssh/id_rsa, vous devez explicitement informer l’authentification SSH où la trouver. Spécifiez la à la commande ssh-add:

...
echo "Requesting permission for ssh..."
ssh-add ~/chemin/vers/ma/clé
...

Dorénavant, vous serez amené à taper le mot de passe de votre clé privée ssh lors de la première ouverture de votre terminal. En voici un exemple:

> Requesting permission for ssh...
> Enter passphrase for /c/Users/you/.ssh/id_rsa:
> Identity added: /c/Users/you/.ssh/id_rsa (/c/Users/you/.ssh/id_rsa)

À noter que le processus ssh-agent continuera de fonctioner jusqu’à ce que vous éteindrez l’ordinateur ou vous terminerez de vous même le processus.

La Merge Request m'indique qu'il y a un conflit, que faire ?

Cela signifie que depuis que vous avez créé votre branche, d’autres Merge Request on été intégrées dans le master et que certains changements entrent en conflits avec les vôtres.

Dans GitLab, il y a un bouton dans la Merge Request qui permet de résoudre les conflits directement.

Je veux récupérer des modifs du master.

Il arrive que l’on ait besoin d’une modification qui a été mergée sur le master après que la branche a été créée. Dans ce cas, il faut faire un rebase.

Pour faire cela, il faut ouvrir une console et suivre les étapes suivantes:

# 1. mettre à jour la branche master
git checkout master
git pull

# 2. se remettre dans la branche que l'on veut modifier
git checkout <branch>

# 3. demander un rebase depuis le master
git rebase origin/master

Cette commande va prendre tous les commits actuels dans la et les réexecuter l’un après l’autre à partir de la dernière version du master. Si cela se passe bien, la commande va montrer ce genre d’output.

First, rewinding head to replay your work on top of it...
Applying: new page to store the initial request of the parents
Applying: wanted errors to make the documentation

Ensuite, si on demande le status (git status), on va avoir ce message:

On branch feature/pmi/page-demande
Your branch and 'origin/<branch>' have diverged,
and have 5 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean

Méfiance ici. Git dit de faire un git pull, mais il ne faut pas le faire ! En faisant cela, vous annulez le rebase fait précédemment et votre branche sera dans un état bizarre qui posera d’autre soucis.

Autre source de méfiance, le status indique Your branch and ‘origin/’ have diverged. Dans le cas d’un rebase, ce message est normal, car le hash des commits à changé (ils ont été “rejoutés”). Si vous n’êtes pas en train de faire un rebase, alors c’est que vous êtes dans un état bizarre et il faut annuler ce que vous avez fait !

Pour s’assurer que c’est correct, on peut utiliser la commande git cherry -v master et cela ne devrait lister que les commits qui ont été faits dans la branche local (on ne doit pas voir les commits du master).

Une fois que le rebase est fait que l’on est sur d’être dans le bon état, alors on peut publier. Il faut ajouter l’option –force afin de mettre à jour la branche car les commits ont changés.

git push --force

Mettre à jour sa branche après un rebase.

Lorsque l’historique d’une branche a été modifié et renvoyé en ligne (typiquement par un rebase), si cette branche est en local sur votre machine (checkout), alors il va y avoir des conflits. C’est normal car l’historique (donc les hashs des commits) ne sont plus les mêmes et git va dupliquer les commits locaux (ceux présents sur votre machine) et ceux en ligne. L’historique local de la branche sera donc complètement aberrant.

Pour mettre à jour la branche locale par rapport à ce qu’il y a en ligne, suivre la procédure suivante:

# on se remet dans le master
git checkout master
git pull

# suppression de la branche locale
git branch -D <branch>

# récupération de la branche en ligne
git checkout <branch>

Une autre possibilité un peu plus brutale est de remettre le HEAD exactement comme celui en ligne, mais cela nécessite de supprimer toutes les modifications locales non committées:

git fetch
git reset --hard origin/<branch>

Réorganiser l'historique des commits

Tant qu’une branche n’a pas été mergée sur le master, il est possible de modifier la liste des commits (changer l’ordre, en supprimer, en combiner plusieurs, etc).

Cela fonctionne de la même manière qu’un rebase, sauf que l’on ajoute l’option -i avec:

#raccourci pour récupérer la dernière version du master
git fetch

#rebase interactif
git rebase -i origin/master

A ce moment, git va vous ouvrir un éditeur de texte avec la liste des commits que vous pourrez éditer:

pick 17a1106658 Changelog template update
pick 30799f7ec6 Updates the documentation
pick 56739ab427 Fixes typo

Chaque ligne est composée d’un mot-clé (pick), du commit et du libellé du commit. Il est possible de modifier l’ordre des lignes, d’en supprimer ou encore de changer le mot-clé pour que git s’occupe de réoganiser les commits.

Dans l’exemple ci-dessus, le 3ème commit corrige une typo dans le 1er commit. Etant donné que la Merge Request n’est pas mergée, il est considéré comme inutile et il peut être mergé dans le 1er commit. Le fichier doit donc être modifié de la manière suivante:

pick 17a1106658 Changelog template update
fixup 56739ab427 Fixes typo
pick 30799f7ec6 Updates the documentation

Le mot-clé fixup indique à git de fusionner cette ligne dans la précédente en ignorant le message de commit. Donc, au final c’est comme s’il n’y avait eu qu’un seul commit avec les bonnes modifications.

D’autres mots-clés sont disponibles et expliqués dans le fichier ouvert par git lors du rebase.

Une fois le rebase effectué, la branche aura divergé, il faudra donc appliquer un git push --force pour publier les changements.

Ce mécanisme est extrêmement pratique en terme de maintenance car il éviter la surmultiplication de commit dont les changements ne font que corriger des oublis dans les autres commits de la même branche.

Supprimer les branches locales mergées.

Une fois qu’une branche a été mergée, elle peut être supprimée localement (elle est intégrée au master).

# on se remet sur le master
git checkout master

# récupération des branches et suppression de celles dont le remote n'existe plus
git fetch --prune

# suppression des branches qui ont été mergées sauf le master
git branch --merged | grep -v master | xargs git branch -D