équivalent git de svn status -u

Question

Quel est l'équivalent git de svn status -u ou plus verbose svn status --show-updates . La commande svn status --show-updates indique les mises à jour que la commande svn update apportera du serveur.

Merci!

Answer 1

Je ne peux pas penser à un moyen de le faire sans réellement chercher les mises à jour (peut-être que quelqu'un d'autre). En supposant que vous êtes sur la valeur par défaut de la branche "master" et l'amont à partir de laquelle ces hypothétiques des mises à jour sera venu, c'est la distance par défaut "origine", essayez....

git fetch
git log --name-only ..origin/master

Notez le double de points .. pas un seul point ou un elipsis¹.

Cela vous donnera une liste d'entrées de journal pour les changements qui sont seulement en amont, avec les noms de fichiers touchés, vous pouvez modifier les paramètres de la commande git log pour obtenir plus ou moins d'informations.

NB dans git "chercher" ces mises à jour n'est pas la même chose que de les appliquer à votre succursale locale. Vous avez sans doute déjà savoir comment le faire avec la commande git pull.

---

¹ pour savoir où faire les deux points viennent, name1..name2 indique une plage. Si name1 est omis, HEAD est utilisé à sa place. Cette syntaxe renvoie à tous les commits accessible à partir d' name2 de retour, mais pas y compris, HEAD. ["Git à partir de la bottom up"]

Answer 2

Les deux Martinho Fernandes et tialaramex réponses décrire correctement ce que vous devez faire. Permettez-moi de décrire pourquoi c'est la façon dont il est.

---

Subversion

Subversion est centralisé, système de contrôle de version. Cela signifie qu'il fonctionne en client-serveur de la mode: le serveur stocke toutes les données à propos de la version (de stockage), le client n'a qu'répertoire de travail (fichiers) et de certaines administrative et d'assistance de données. Cela signifie que pour la plupart des commandes client doit contacter le serveur. Cela signifie aussi qu'il ya beaucoup de commandes en demandant au sujet de l'état de référentiel sur le serveur, ou serveur de configuration, comme "svn status --show-updates" en question.

(Note: un accompagnateur de données que la Subversion des magasins sur le client sont les "vierges" de la version de fichiers, ce qui signifie que la vérification pour les changements que vous avez fait n'a pas besoin de se connecter au serveur (qui est lent)... mais cela signifie aussi que SVN checkout peut être plus grand que le dépôt Git).

"svn update" (nécessaire avant de s'engager si le dépôt a des changements dans la branche) télécharge la dernière version de remote et fusionne (essaie de fusionner) les modifications que vous avez faites avec des changements de distance. À mon humble avis, cette mise à jour avant d'engager de flux de travail n'est pas très conductrices.

---

Git

Git est distribué système de contrôle de version. Cela signifie qu'il fonctionne sur les réseaux peer-to-peer: chaque "client" dispose de toutes les données sur les versions (référentiel). Le référentiel central est central seulement en raison de convention sociale et de ne pas les limitations de la technique. Cela signifie que lorsque vous communiquez avec d'autres dépôt distant le nombre de commandes "exécuté à distance" est très petit. Vous pouvez demander des références (chefs aka. les branches et les tags) avec "git ls-distance" (et "git update show"), vous pouvez tirer (get) ou push (publier) des données avec "git fetch" (ou "git remote update") / "git push", et si le serveur est configuré pour permettre, vous pouvez obtenir un instantané de l'état de dépôt distant avec "git archive --à distance".

Donc, pour examiner s'engage qui sont en dépôt distant mais ne sont pas présents dans votre référentiel, vous devez télécharger les données sur votre machine. Mais "git pull" est en fait rien de plus que "git fetch" qui permet de télécharger des données et "git merge" qui fusionne (avec un peu de sucre pour préparer des messages de validation et de choisir la direction de fusion). Vous pouvez ensuite utiliser git fetch" (ou "git remote update"), examiner nouvellement engage avec "git log" et "gitk" (ne pas être limité à sortie fixe), et ensuite, si tout va bien la fusion avec "git merge".

Ce n'est pas spécifique à Git, mais à toutes les distribué des systèmes de contrôle de version, bien que la façon SCM présente chercher, mais non fusionné les données peuvent différer (Git utilise à distance-suivi des branches à distance/<remotename>/*' espace de noms, Mercurial de ce que je comprends, utilise des têtes sans nom).

HTH

Answer 3

Si vous allez chercher:

 git fetch <remote>
 

au lieu de tirer:

 git pull <remote>
 

à partir de la télécommande, vous pouvez alors vérifier ce qui a changé avec git log . Pour appliquer les modifications:

 git merge <remote>/<remote-branch>
 

Answer 4

Vous pouvez utiliser git ls-remote pour répertorier le SHA des références dans un référentiel distant; alors, vous pouvez voir s’il ya des changements en comparant les résultats de:

 $ git show-ref origin/master     # <-- Where this repo thinks "origin/master" is
5bad423ae8d9055d989a66598d3c4473dbe97f8f refs/remotes/origin/master
$ git ls-remote origin master    # <-- Where "origin" thinks "master" is
060bbe2125ec5e236a6c6eaed2e715b0328a9106    refs/heads/master
 

Si elles diffèrent, il y a des modifications à extraire:

 $ git remote update
Fetching origin
...
From github.com:xxxx/yyyy
5bad423..060bbe2  master     -> origin/master
 

Answer 5

Pour moi, juste pour afficher les fichiers qui vont changer, c'est:

 git fetch (1)
git diff --name-only ..origin/master (2)
 

1. Récupère les modifications dans la "base de données" Git (uniquement le répertoire .git) et ne modifie pas les fichiers.
2. Affiche les noms des fichiers qui seront modifiés après une fusion

Pour mettre à jour des fichiers (pas seulement "base de données" de Git), effectuez une fusion de git