Git équivalents des commandes Mercurial les plus courantes?
J'utilise Mercurial mais je voudrais faire une démo rapide de Git.
Quels sont les équivalents Git de:
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
La pierre de rosette Git-HG n'est pas mauvaise
Il y a quelques autres accrochages entre les deux non mentionnés ici. Cette liste a été extraite de mon propre article de blog lorsque je suis allé dans l'autre sens (git -> hg).
Hg .hgignore, syntaxe: glob est le même comportement que le gitignore de git.
Git .git/config, ~/.gitconfig, utilisez 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 vue hg, ou thg de TortoiseHg
Git git gui
Hg Mercurial ne livre pas d'interface graphique pour sélectionner les changesets, uniquement la commande de console hg record.
Git git rebase
Hg rebase hg . Pour git rebase --interactive, Il y a hg histedit , ou Mercurial Queues
Git git URL push; git remote add URL d'origine
Hg hg URL push; $ EDITOR .hg/hgrc; [chemins] par défaut = URL
Git gitk, git log Origin/master..HEAD
Hg hg sortant
Git git format-patch RANGE
Hg hg email -m nom de fichier -o
Git git add. ; Notez le point
Hg hg add; Aucun point nécessaire.
Git git checkout CLÉ DE RÉVISION
Hg hg update CHANGESET
Juste pour remplir les blancs, certaines des commandes les plus utiles de Mercurial:
Enregistrement Hg hg
Git git add -p; git commit
Hg hg inc [URL]
Git Pas de véritable équivalent. Vous ne pouvez faire que l'équivalent de hg pull; hg log -r .:
Hg hg out URL
Git Veuillez ajouter si vous savez comment.
Pour la résolution des conflits de fusion, la commande hg resolve Dans Mercurial propose quelques options qui modifient le comportement:
Hg hg resolver -m FILE (marque le fichier comme ayant été résolu en corrigeant manuellement le problème de conflit)
Git git add FILE
Hg hg resolve -u FILE Marque le fichier comme non résolu
Git git reset HEAD FILE Pour supprimer le fichier
Hg hg résoudre -l (répertorie les fichiers avec des conflits résolus/non résolus)
Git git status - les fichiers qui ont fusionné proprement sont ajoutés automatiquement à l'index, ceux qui ne sont pas en conflit
Hg hg résoudre FILE (après une fusion, tente de refusionner le fichier)
Git pas d'équivalent pour la fusion à ma connaissance.
Remarque: l'une des plus grandes différences entre Git et Mercurial est la présence explicite de index ou zone de transit .
Git est le seul DistributedSCM qui expose le concept d'index ou de zone de transit. Les autres peuvent le mettre en œuvre et le masquer, mais dans aucun autre cas, l'utilisateur n'est au courant ni n'a à y faire face.
L'équivalent approximatif de Mercurial est
DirState, qui contrôle les informations d'état de la copie de travail pour déterminer les fichiers à inclure dans le prochain commit. Mais dans tous les cas, ce fichier est géré automatiquement.
De plus, il est possible d'être plus sélectif au moment de la validation, soit en spécifiant les fichiers à valider sur la ligne de commande, soit en utilisantRecordExtension.Si vous vous sentiez mal à l'aise face à l'index, vous changez pour le mieux ;-)
L'astuce est que vous devez vraiment comprendre l'index pour exploiter pleinement Git. Comme cela article de mai 2006 nous rappelle alors (et c'est toujours vrai maintenant):
"Si vous niez l'index, vous niez vraiment git lui-même."
Maintenant, cet article contient de nombreuses commandes qui sont maintenant plus simples à utiliser (donc ne vous fiez pas trop à son contenu;)), mais l'idée générale demeure:
Vous travaillez sur une nouvelle fonctionnalité et commence à apporter des modifications mineures à 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 actuelle
# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work
$ git commit
Enregistre uniquement les modifications ajoutées à la zone de transfert (index) à ce stade, pas les modifications majeures actuellement visibles dans votre répertoire de travail.
$ git branch newFeature_Branch
$ git add myFile
Le prochain commit enregistrera tous les autres changements majeurs dans la nouvelle branche 'newFrature_Branch'.
Désormais, l'ajout interactif ou même le fractionnement d'un commit sont des fonctionnalités disponibles avec Mercurial, via le 'hg record 'ou d'autres extensions: vous devrez installer RecordExtension , ou CrecordExtension .
Mais cela ne fait pas partie du flux de travail normal de Mercurial.
Git considère un commit comme une série de " modifications du contenu du fichier ", et vous permet d'ajouter ces modifications une par une.
Vous devriez étudier cette fonctionnalité et ses conséquences: la plupart du pouvoir de Git (comme la capacité de facilement annuler une fusion (ou diviser le problème, ou annuler un commit) , contrairement à Mercurial ) vient de ce paradigme de "contenu de fichier".
tonfa (dans le profil: "Hg dev, pythonist": les chiffres ...) a sonné, dans les commentaires:
Il n'y a rien de fondamentalement "git-ish" dans l'index, hg pourrait utiliser un index s'il était jugé utile, en fait
mqoushelveen font déjà partie.
Oh mec. On y va encore une fois.
Premièrement, je ne suis pas ici pour faire en sorte qu'un outil soit meilleur qu'un autre. Je trouve Hg génial, très intuitif, avec un bon support (surtout sur Windows, ma plateforme principale, même si je travaille sur Linux et Solaris8 ou 10 aussi).
L'index est en fait avant et au centre de la manière Linus Torvalds fonctionne avec un VCS :
Git a utilisé des mises à jour d'index explicites à partir du jour 1, avant même la première fusion. C'est simplement comme ça que j'ai toujours travaillé. J'ai tendance à avoir des arbres sales, avec un correctif aléatoire dans mon arbre que je fais pas je veux valider, car c'est juste une mise à jour Makefile pour la prochaine version
Maintenant la combinaison de l'index (qui n'est pas une notion vue seulement dans Git), et le "contenu est le paradigme du roi le rend assez unique et "git-ish" :
git est un tracker de contenu , et un nom de fichier n'a de sens que s'il est associé à son contenu. Par conséquent, le seul comportement sain pour git add filename est d'ajouter le contenu du fichier ainsi que son nom à l'index.
Remarque: le "contenu", ici, est défini comme suit :
L'indice de Git est fondamentalement très défini comme
- suffisant pour contenir le total " contenu " de l'arborescence (et ce inclut toutes les métadonnées: le nom de fichier, le mode , et le contenu du fichier sont tous parties du "contenu", et ils sont tous dépourvus de sens en eux-mêmes! )
- informations "stat" supplémentaires pour permettre les optimisations évidentes et triviales (mais extrêmement importantes!) du système de fichiers.
Donc, vous devriez vraiment voir l'index comme être le contenu .
Le contenu n'est pas le "nom de fichier" ou le "contenu de fichier" en tant que parties distinctes. Vous ne pouvez vraiment pas séparer les deux .
Les noms de fichiers en eux-mêmes n'ont aucun sens (ils doivent également avoir du contenu de fichier), et le contenu de fichier en lui-même est tout aussi insensé (vous devez savoir comment y accéder).Ce que j'essaie de dire, c'est que git ne vous permet pas de permettre de voir un nom de fichier sans son contenu. Toute la notion est folle et non valable. Il n'a aucun rapport avec la "réalité".
De la FAQ , les principaux avantages sont:
- s'engager avec une granularité fine
- vous aider à conserver une modification non validée de votre arbre pendant une durée raisonnablement longue
- effectuez plusieurs petites étapes pour un commit, en vérifiant ce que vous avez fait avec
git diff, et valider chaque petite étape avecgit addougit add -u. - permet une excellente gestion des conflits de fusion:
git diff --base,git diff --ours,git diff --theirs. - permet
git commit --amendpour modifier uniquement le message du journal si l'index n'a pas été modifié entre-temps
Personnellement, je pense que ce comportement ne devrait pas être la valeur par défaut, vous voulez que les gens commettent quelque chose qui est testé ou au moins compilé
Bien que vous ayez raison en général (sur la partie "testée ou compilée"), la façon dont Git vous permet de créer des branches et de fusionner (sélection de cerise ou rebasage) vous permet de vous engager aussi souvent que vous le souhaitez dans une branche privée temporaire (poussée uniquement vers un référentiel de "sauvegarde" distant), tout en refaisant ces "vilains commits" sur une branche publique, avec tous les bons tests en place.
Mercuriel:
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
Équivalents Git:
git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status
C'est à peu près la même chose, sans ajout:
git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes
Cependant, ce sont des commandes que vous utiliseriez lorsque vous travaillez seul. Vous entrez dans les trucs soigné lorsque vous voulez fusionner vos modifications avec le travail des autres avec git pull et git Push et les commandes associées.