23 votes

Quelles sont les limites de Git sur Windows?

J'ai lu partout sur Mercurial et Git ils ont généralement de le jeter dans une ligne ou deux qui implique Git a une capacité limitée sur Windows (à cause de certains Shell scripts ne peuvent pas être portés, etc.) mais je n'ai jamais rencontré une page qui mentionne explicitement eux. Et la plupart des pages sont un peu vieux.

Quelles sont les limites de Git sur Windows en termes de fonctionnalité? Et le fait d'avoir à exécuter Git sur MinGW et MSYS sur les Fenêtres ont des limites de performances?

27voto

cjrh Points 3960

Après avoir écrit un guide de configuration du client et du serveur Git sur Windows, j'ai une assez bonne idée de ce à quoi on peut s'attendre. Aussi, mon premier dépôt (.git le dossier) est ~260 MO de source, de sorte qu'il n'est vraiment pas une mince performance test pour la journée-à-jour Git fonctionne sur Windows.

Mon impression générale est que Git sur windows est très rapide pour la grande majorité des cas on est susceptible de rencontrer, avec un vraiment énorme exception: git gui blame -C -C. Par défaut, git ne sera pas la faute sur les fichiers au-delà du changement de nom de fichier des limites, et l'extra - -C -C arguments doivent être adoptées afin de permettre que cela se produise, mais alors les choses peuvent vraiment ralentir. Il faut 17 minutes sur le matériel moderne pour produire une annotation complète de l'un de nos plus grands ~20 kloc fichiers sources. Ce délai peut vraiment briser votre concentration.

Concernant cygwin:

J'ai seulement essayé une fois, et pas pour quelque chose de significatif. Je voulais vraiment une solution native. Par tous les comptes, git sur cygwin fonctionne assez bien.

Concernant TortoiseGit

Frank Li a effectué un énorme travail on le fait aujourd'hui à l'INTERFACE utilisateur Git monde. TortoiseGit démarré très rapidement parce que la plupart de l'INTERFACE utilisateur est disponible à partir de TortoiseSVN (et d'autres outils comme TortoiseMerge), et j'ai travaillé avec cette interface beaucoup. En général, elle permet à chacun d'y aller avec Git très rapidement si vous êtes familier avec TortoiseSVN. Le développeur n'a pas ménagé ses efforts pour utiliser des termes de la commande TortoiseSVN monde et de la carte à commandes git. Par exemple, un revert vraiment effectue une git checkout <file> sous le capot.

En général, travailler avec Git de cette façon a été assez fluide, et je dois admettre avoir appris Git en utilisant le TortoiseGit interface: et l'on doit admettre que c'était un obstacle à mon éducation. TortoiseSVN-comme la visionneuse de journaux ne fonctionne pas vraiment pour un système distribué-vcs flux de travail (il fonctionne assez bien vous utilisez Git, comme si c'était SVN), et vous ne trouverez cela plus tard, car les problèmes ne viennent que quand il y a beaucoup, beaucoup de branches de développement (l' gitk outil est beaucoup mieux à la manipulation de cet écran). Et l'autre problème est que, même après l'utilisation de TortoiseGit pendant de nombreux mois, je ne l'ai toujours pas savoir, même la plus basique des commandes git. Il n'y a rien de vraiment faux avec TortoiseGit, et des bugs ont été corrigés de manière impressionnante rapidement lorsqu'elles se produisent; le principal problème semble être un problème de conception (éventuellement plusieurs) dans l'INTERFACE utilisateur, quelque chose que l' gitk et git gui développeurs ont travaillé sur la raison d'un développement plus long de l'histoire, ou une connaissance plus intime du idiomatiques git d'utilisation, ou quelque chose comme ça.

Concernant l'utilisation en ligne de commande:

Le MSYS git de l'équipe de développement sont ceux qui vraiment doit être remercié pour prendre la peine de faire tout le travail qu'ils ont fait, et sans leur soutien, il est probable que le mingw git branch aurait même jamais été fusionnée avec la ligne principale.

J'ai commencé à l'aide de msysgit, comme l'est, dans le Git Bash shell, comme mon git interface pour quelques semaines. Mon impression est que, bien que l'apprentissage initial semble plus difficile, une fois que la connaissance a été acquise, tout le reste devient plus facile. Cette référence est, à mon avis, une des meilleures références de l'apprentissage git en ligne de commande.

S'exprimant en tant que les utilisateurs de Git sur Windows, et qui vient d'une longue expérience de l'utilisation de la TortoiseGit interface de git, c'est un résumé de mon flux de travail, qui couvre plus de 95% de ce qui est nécessaire (tous dans Git Bash, pas le shell de commande Windows (cmd)):

  • Vérifier les Modifications

    git status

  • Commutateur de direction

    git checkout quelques-fonction-branche

  • Fetch

    git fetch

  • Afficher le Journal (l' & se détache de l' gitk processus de la coquille, de sorte que le shell n'attend pas pour gitk à être fermé avant de permettre à plus de commandes)

    gitk &

  • S'engager: soit

    • Simple commit:

      git commit-a -m "Ceci est mon message de commit"

    • Complexes, multiples successifs s'engage à:

      git gui

  • Pousser la branche master

    git push origin master

  • De fusion (par exemple, après le Fetch)

    git merge origin/master

Je n'ai pas eu à le faire tout de résolution de conflit, encore, mais je verrai ça quand vient le temps (les commentaires sont les bienvenus :).

EDIT: Pour la résolution des conflits, kdiff3 est le chemin à parcourir. L'installation est simple, et tout à partir de simples différences jusqu'à trois voies de fusion fonctionne de manière fiable et rapide.

Conclusions

  • Git sur Windows est complet et fonctionne comme annoncé, et n'est pas limité sur Windows.

  • Le rendement est généralement très bonne, mais complet grand blâme peut être lente.

  • Le TortoiseGit interface est séduisante, mais en fin de compte insatisfaisante: vous devriez essayer d'apprendre git sur la ligne de commande. J'ai fait les deux, et c'est l'itinéraire le plus efficace.

9voto

VonC Points 414372
  • douteuse soutien joker:
    (problématique pour .gitignore fichiers)
    envoyer à l'OS sous-jacent spécifique fnname() méthode: voir à cette question et que l'un (ou qu'un)

  • git-svn pourrait ne pas être très rapide.
    Source: cette SORTE de réponse. Il a fait de bons progrès bien que.

  • l' PATH doivent être ajustées pour éviter tout conflit
    Certaines commandes sont les mêmes entre Windows et le bash. (find, cp, rm, ...).
    Voir cette SORTE de réponse.
    Comme cjrh commentaires, Git pour Windows n'ajoute pas son bin répertoire par défaut pour l' PATH.

  • certains EOL conversion peut avoir lieu (Unix et Windows EOL)
    Voir la recommandation Définitive pour l' git autocrlf paramètres.
    Le nouveau et amélioré core.eol et eol attributs de Git1.7.2 ne sont pas encore msysgit.

3voto

peterjmag Points 1978

(C'est probablement plus un commentaire qu'une réponse, mais mon rep n'est pas tout à fait là encore).

Je me demandais la même chose récemment, et je n'étais pas en mesure de creuser trop non plus. Voici une discussion intéressante (découvert via une citation sur Git de l'entrée de wikipedia).

Aussi loin que je peux dire, les principales questions sont les performances (en particulier sur Cygwin, et/ou avec de grands répertoires du système de fichiers et les questions de (nom de fichier de l'insensibilité à la casse, limitée VFS).

Purement subjectif/anecdotiques:

Je me sens comme Git est un beaucoup plus agréable l'expérience de course nativement sous Ubuntu 10.04 que sur Cygwin sous Win7 sur la même machine, si bien que j'ai fait passer presque tout mon web freelance travaux de développement d'Ubuntu pour prendre avantage de celui-ci (entre autres choses). J'ai appris Git sur mon OSX machine au travail, et donc essayer de travailler avec elle sur Windows par la suite était presque douloureuse. msysgit est certainement une amélioration par rapport à Cygwin, mais il souffre encore de les limitations du système de fichiers Windows.

EDIT: Apparemment, msysgit étouffe sur les noms de fichiers qui ont été saisies dans le dépôt git via une UTF8-connaissance du système de fichiers, comme Linux, qui suce.

J'ai aussi juste trébuché à travers GitSharp, un WIP de Windows natif de mise en œuvre (découvert via ce blog de commentaires).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X