Git équivalents des principales commandes de Mercurial ?

Question

Je sers de Mercurial mais aimeriez faire une démonstration rapide de Git.

Quels sont les équivalents de Git des :

Answer 1

Git-HG rosetta stone est pas mal

Il y a quelques autres pièges entre les deux ne sont pas mentionnés. Cette liste a été chipé par mon propre blog, quand je suis allé l'autre sens (git -> hg).

Hg .hgignore, de la syntaxe: glob est le même comportement que git .gitignore.

Git .git/config, ~/.gitconfig, l'utilisation de git-config pour modifier les valeurs
Hg .hg/hgrc, ~/.hgrc, utilisez hg help -c config

Git git commit -v
Hg hg diff | moins; hg commit

Git gitk
Hg hg de la vue ou de la thg de TortoiseHg

Git git gui
Hg Mercurial n'envoyons pas de GUI pour sélectionner les ensembles de modifications, seule console hg record commande.

Git git rebase
Hg hg rebase. Pour git rebase --interactive il y a hg histedit, ou Mercurial Files d'attente

Git git push URL ; git remote add origin URL
Hg hg push URL; $EDITOR .hg/hgrc ; [chemins] par défaut = URL

Git gitk, git log origin/master TÊTE..
Hg hg sortant

Git git format-patch GAMME
Hg hg e-mail -m nom de fichier -o

Git git add . ; Notez le point
Hg hg add ; Pas de point nécessaire.

Git git checkout RÉVISION-CLÉ
Hg hg mise à jour de l'ensemble de modifications

Juste pour remplir les espaces vides, les plus utiles des commandes à partir d'Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Pas de réel équivalent. Vous ne pouvez faire l'équivalent d' hg pull; hg log -r .:

Hg hg URL
Git s'il vous Plaît ajouter si vous savez comment.

Answer 2

Remarque: l'un de la plus grande différence entre Git et Mercurial, c'est la présence explicite de l' index ou de la zone de transit.

De Mercurial pour les Utilisateurs de Git:

Git est le seul DistributedSCM qui expose le concept de l'index ou de la zone de transit. Les autres peuvent mettre en œuvre et de le cacher, mais en aucun cas l'utilisateur est conscient, ni de traiter avec elle.

Mercurial est équivalent est l' DirState, qui contrôle de la copie de travail les informations d'état pour déterminer les fichiers à inclure dans le prochain commit. Mais dans tous les cas, ce fichier est géré automatiquement.
En outre, il est possible d'être plus sélectif au moment de la validation, soit en spécifiant les fichiers que vous voulez envoyer sur la ligne de commande ou en utilisant l' RecordExtension.

Si vous vous êtes senti à l'aise avec l'index, vous êtes de commutation pour le mieux ;-)

---

Le truc est, vous avez vraiment besoin de comprendre l'indice d'exploiter pleinement Git. Comme cet article à partir de Mai 2006, nous rappelle ensuite (et c'est encore vrai aujourd'hui):

"Si vous refusez l'Index, vous avez vraiment refuser git lui-même."

Maintenant, cet article contient de nombreuses commandes qui sont maintenant plus simple à utiliser (donc ne comptez pas sur son contenu trop ;) ), mais l'idée générale reste la même:

Vous travaillez sur une nouvelle fonctionnalité et commence à faire des petites modifications sur un fichier.

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

À ce stade, votre prochain commit embarquera 2 modifications mineures dans la branche courante

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Seulement enregistre les modifications ajoutées à la zone de transit (index) à ce stade, pas le de grands changements visibles dans votre répertoire de travail.

$ git branch newFeature_Branch
$ git add myFile

Le prochain commit permet d'enregistrer tous les autres changements majeurs dans la nouvelle branche "newFrature_Branch'.

Maintenant, en ajoutant de manière interactive ou encore le fractionnement de validation sont les fonctionnalités disponibles avec Mercurial, par le biais de la 'hg record' de la commande ou d'autres extensions: vous aurez besoin d'installer RecordExtension, ou l' CrecordExtension.
Mais cela ne fait pas partie du processus normal pour Mercurial.

Git vues de commettre une série de "contenu du fichier changements", et vous permettent d'ajouter ces changements, un à la fois.
Vous devriez étudier cette fonction et de ses conséquences: la Plupart de Git puissance (comme la possibilité de facilement revenir à une fusion (ou traversent le problème, ou pour annuler un commit), contrairement à l'Mercurial) provient de "contenu du fichier" paradigme.

---

tonfa (de profil: "Hg dev, pythonist": les chiffres...) s'est écrié, dans les commentaires:

Il n'y a rien de fondamentalement "git-ish" dans l'index, hg peuvent utiliser un indice si c'était avoir de la valeur, en fait mq ou shelve le font déjà partie.

Oh boy. Ici, nous allons à nouveau.

Tout d'abord, je ne suis pas ici pour faire un outil, c'est mieux que l'autre. Je trouve Hg grand, très intuitive, avec un bon soutien (surtout sur Windows, ma principale plate-forme, bien que je travaille sur Linux et Solaris8 ou 10).

L'indice est en fait l'avant et centre dans la façon dont Linus Torvalds fonctionne avec un VCS:

Git utilisé explicite de l'indice des mises à jour à partir du jour 1, avant même que la première fusion. C'est simplement, j'ai toujours travaillé. J'ai tendance à avoir sale arbres, avec quelques aléatoire patch dans mon arbre que je n'ai pas envie de commettre, parce que c'est juste un Makefile mise à jour pour la prochaine version

Maintenant, la combinaison de l'indice (qui n'est pas une notion vu que dans Git), et le "contenu est roi" paradigme rend assez unique et "git-ish":

git est un contenu tracker, et un nom de fichier n'a pas de sens à moins d'être associée à son contenu. Par conséquent, la seule saine d'esprit, le comportement de la commande git add nom de fichier pour ajouter le contenu du fichier ainsi que son nom à l'index.

Remarque: le "contenu", ici, est définie comme suit:

Git est l'indice est fondamentalement très bien défini comme

• suffisant pour contenir le nombre total de "contenu" de l'arbre (et cela comprend toutes les métadonnées: le nom de fichier, le mode et le contenu de ce fichier sont toutes les pièces du "contenu", et ils sont tous vides de sens sur leur propre!)
• supplémentaires "stat" de l'information pour permettre à l'évident et banal (mais très important!) système de fichiers comparaison des optimisations.

Donc vous devriez vraiment voir l'index comme étant le contenu.

Le contenu n'est pas le "nom de fichier" ou le "contenu du fichier" en tant que parties séparées. Vous vraiment ne peut pas séparer les deux.
Les noms de fichiers sur leur propre n'ont pas de sens (qu'ils ont besoin de contenu de fichier trop), et le fichier de contenu sur son propre est de même insensé (vous devez savoir comment l'atteindre).

Ce que j'essaie de dire, c'est que git fondamentalement ne pas permettre à vous de voir un nom de fichier sans son contenu. L'idée est de fous et non valide. Il n'a aucune pertinence pour la "réalité".

À partir de la FAQ, les principaux avantages sont:

• s'engager avec une granularité fine
• vous aider à garder un uncommited modification dans votre arbre pendant une assez longue période
• effectuer plusieurs petites étapes pour une validation, la vérification de ce que vous avez fait avec git diff, et la validation de chaque petite étape avec git add ou git add -u.
• permet une excellente gestion de conflits de fusion: git diff --base, git diff --ours, git diff --theirs.
• permet d' git commit --amend de modifier uniquement le message de log si l'index n'a pas été modifiée dans le temps

---

Personnellement, je pense que ce comportement ne devrait pas être la valeur par défaut, vous voulez que les gens à commettre quelque chose qui est à l'essai ou au moins compilé

Alors que vous êtes en droit en général (à propos de la "testé ou compilé" partie), la manière dont Git vous permet de branchement et de fusion (cherry-picking ou de changement d'année de base) permet de valider aussi souvent que vous le souhaitez dans un privée provisoire de la branche (poussé qu'à distance, la sauvegarde "référentiel"), tout en re-faisant ces "laid s'engage" à un public direction, avec tous les tests en place.

Answer 3

Mercurial :

Équivalents de git :

Answer 4

C’est à peu près la même chose, sans addremove :

Cependant, Voici les commandes que vous utilisez lorsque vous travaillez seul. Vous entrez dans les trucs sympa lorsque vous souhaitez fusionner vos modifications avec le travail d’autrui avec et et les commandes.