Ciò che lo stato ti sta dicendo è che sei dietro l'arbitro chiamato origin/master che è un riferimento locale nel tuo repository locale . In questo caso, ref rintraccia un ramo in qualche telecomando, chiamato origin, ma lo stato non ti dice nulla sul ramo sul telecomando. Ti sta parlando dell'arbitro, che è solo un ID commit memorizzato sul tuo filesystem locale (in questo caso, è in genere in un file chiamato .git/refs/remotes/origin/masternel tuo repository locale).
git pullesegue due operazioni; prima fa un git fetchaggiornamento per i commit nel repository remoto (che aggiorna il origin/masterref nel repository locale), quindi fa un git mergeper unire tali commit nel ramo corrente.
Fino a quando non si esegue il fetchpassaggio (da solo o tramite git pull) il repository locale non ha modo di sapere che ci sono ulteriori commit a monte e git statusguarda solo il riferimento locale origin/master.
Quando git statusdice aggiornato, significa "aggiornato con il ramo che il ramo corrente tiene traccia", che in questo caso significa "aggiornato con il riferimento locale chiamato origin/master". Ciò equivale solo a "aggiornato con lo stato upstream che è stato recuperato l'ultima volta che abbiamo eseguito un fetch" che non è lo stesso di "aggiornato con l'ultimo stato live dell'upstream".
Perché funziona in questo modo? Bene, il fetchpassaggio è un'operazione di rete potenzialmente lenta e costosa. Il design di Git (e di altri sistemi di controllo della versione distribuita ) è di evitare le operazioni di rete quando non necessario, ed è un modello completamente diverso dal tipico sistema client-server a cui molte persone sono abituate (sebbene, come sottolineato nei commenti sotto, il concetto di Git di un "ramo di tracciamento remoto" che causa confusione qui non è condiviso da tutti i DVCS). È del tutto possibile utilizzare Git offline, senza connessione a un server centralizzato, e l'output di git statusriflette questo.
La creazione e il cambio di rami (e il controllo del loro stato) in Git dovrebbero essere leggeri, non qualcosa che esegue un'operazione di rete lenta verso un sistema centralizzato. Il presupposto durante la progettazione di Git e git statusdell'output era che gli utenti lo capiscono (troppe funzionalità di Git hanno senso solo se sai già come funziona Git). Con l'adozione di Git da parte di molti e molti utenti che non hanno familiarità con DVCS questo presupposto non è sempre valido.