Des modifications existent en amont dans une branche suivie, mais lorsque je tape git status
, cela indique que ma branche locale est à jour. S'agit-il d'un nouveau comportement, ai-je changé un paramètre de configuration ou est-ce que quelque chose ne va pas?
Merci pour l'aide.
ubuntu@Host:/my/repo# git status
On branch master
Your branch is up-to-date with 'Origin/master'.
nothing to commit, working directory clean
ubuntu@Host:/my/repo# git pull
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From bitbucket.org:my/repo
1234567..abcdefg master -> Origin/master
Updating 1234567..abcdefg
Fast-forward
file1 | 1 -
file2 | 43 +++++++++++++++++++++++++++++++++++++++++++
file3 | 21 ++++++++++++---------
file4 | 21 ++++++++++++---------
4 files changed, 67 insertions(+), 19 deletions(-)
create mode 100644 file5
Ce que le statut vous dit, c'est que vous êtes derrière la référence appelée Origin/master
qui est une référence locale dans votre référentiel local. Dans ce cas, ref fait le suivi d’une branche d’une télécommande, appelée Origin
, mais l’état ne vous dit rien sur la branche de la télécommande. Il vous parle de la référence, qui est simplement un ID de validation stocké sur votre système de fichiers local (dans ce cas, il s'agit généralement d'un fichier appelé .git/refs/remotes/Origin/master
dans votre référentiel local).
git pull
fait deux opérations; commence par un git fetch
pour se mettre à jour avec les commits du référentiel distant (qui met à jour le Origin/master
ref dans votre référentiel local), puis un git merge
pour fusionner ces commits dans la branche actuelle.
Tant que vous n'avez pas effectué l'étape fetch
(soit seul, soit via git pull
), votre dépôt local n'a aucun moyen de savoir qu'il existe des validations en amont, et git status
ne fait que regarder votre Origin/master
réf local.
Quand git status
dit à jour, cela signifie "à jour avec la branche suivie par la branche actuelle", ce qui dans ce cas signifie "à jour avec la référence locale appelée Origin/master
". Cela équivaut uniquement à "être à jour avec le statut en amont qui a été récupéré la dernière fois que nous avons effectué un fetch
", ce qui n'est pas la même chose que "à jour avec le dernier statut en direct du trafic en amont".
Pourquoi ça marche comme ça? Eh bien, l'étape fetch
est une opération réseau potentiellement lente et coûteuse. La conception de Git (et d’autres distribués systèmes de contrôle de version ) évite les opérations réseau inutilement et constitue un modèle complètement différent du système client-serveur typique utilisé par beaucoup de Comme indiqué dans les commentaires ci-dessous, le concept de "branche de suivi à distance" de Git qui crée de la confusion n'est pas partagé par tous les DVCS). Il est tout à fait possible d’utiliser Git hors ligne, sans connexion à un serveur centralisé, et le résultat de git status
en témoigne.
La création et la commutation de branches (et la vérification de leur statut) dans Git sont supposées être légères, et non pas comme une opération qui effectue une opération réseau lente sur un système centralisé. Lors de la conception de Git, et de la sortie de git status
, l'hypothèse était que les utilisateurs le comprenaient (trop de fonctionnalités de Git n'ont de sens que si vous savez déjà comment fonctionne Git). Avec l'adoption de Git par de nombreux utilisateurs qui ne sont pas familiers avec DVCS, cette hypothèse n'est pas toujours valable.
En effet, votre référentiel local n’a pas été enregistré auprès des télécommandes en amont. Pour que cela fonctionne comme prévu, utilisez git fetch
, puis exécutez à nouveau un git status
.
"Origine/maître" fait référence à la référence pointant vers le commit HEAD de la branche "Origine/maître" . Une référence est un alias convivial pour un objet Git, généralement un objet commit . La référence "Origine/maître" n'est mise à jour que lorsque vous git Push
Comparez l'ID de validation affiché avec:
cat .git/refs/heads/master
Ils devraient être les mêmes, et c'est pourquoi Git dit que master
Cela récupère les nouveaux objets Git localement dans le dossier .git/objects . Et Git met à jour .git/FETCH_HEAD afin qu’il pointe maintenant vers la dernière validation de la branche extraite.
Donc, pour voir les différences entre votre branche locale actuelle et la branche extraite en amont, vous pouvez exécuter
git diff HEAD FETCH_HEAD
Examinons un exemple de rapport git pour vérifier si your branch (master)
est up to date
avec Origin/master
.
Vérifiez que le maître local suit l'origine/le maître:
$ git branch -vv
* master a357df1eb [Origin/master] This is a commit message
Plus d'infos sur la branche master locale:
$ git show --summary
commit a357df1eb941beb5cac3601153f063dae7faf5a8 (HEAD -> master, tag: 2.8.0, Origin/master, Origin/HEAD)
Author: ...
Date: Tue Dec 11 14:25:52 2018 +0100
Another commit message
Vérifiez si Origin/master est sur le même commit:
$ cat .git/packed-refs | grep Origin/master
a357df1eb941beb5cac3601153f063dae7faf5a8 refs/remotes/Origin/master
Nous pouvons voir le même hachage, et dire que la branche est en cohérence avec la distante, du moins dans le dépôt git actuel.