web-dev-qa-db-fra.com

Pourquoi le statut de git montre-t-il que branch est à jour lorsque des modifications ont été apportées en amont?

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
155
GregB

Ce que le statut vous dit, c'est que vous êtes derrière la référence appelée Origin/masterqui 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.

194
Jonathan Wakely

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.

27
Ryan

"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
0
Marek Stanley

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.

0
themefield