2011-04-03 4 views
2

Possible en double:
What are currently the problems with Git on WindowsEst-ce que git est stable sur Windows?

Récemment, j'ai notre système de commutation envisageais de contrôle de source de svn git afin que nous puissions tirer parti de la fonction de distributability. Après avoir fait des recherches. Je l'ai trouvé, il semble que nous n'avons pas beaucoup de choix pour lancer git sur Windows. MsysGit est la seule option qui équilibre les deux côtés de la courbe d'apprentissage et de l'effort administratif. Malheureusement, il est encore sur la version d'aperçu jusqu'à présent.

Quelque chose me manque? Ou, y a-t-il une meilleure alternative?

+0

question si des problèmes de Git sous Windows: http://stackoverflow.com/questions/3696834/what-are-currently-the-problems-with-git-on-windows – lecodesportif

+0

Je me sers beaucoup pour msysGit Les deux travaillent et jouent depuis plus d'un an maintenant et n'ont jamais eu un problème. Je le recommande fortement. –

+0

D'accord avec @Matt Greer ci-dessus. Cela fonctionne à merveille pour moi et je n'ai pas encore atteint un seul problème. –

Répondre

0

Nous utilisons mSysGit depuis environ un an. Nous avons rencontré quelques bugs, mais pas de bloqueurs - le référentiel a toujours été assez solide; les bugs sont tous dans les outils frontaux.

Les deux bugs que nous avons rencontré sont:

  • Les applications GUI (git-et gitk GUI) Verrouillez les deux de temps en temps, souvent plusieurs fois par jour. Les blocages ne se produisent que lorsque vous essayez de faire quelque chose avec le dépôt: mettre en scène un changement, faire un commit, extraire une branche, etc. Cela semble être une impasse dans la communication entre l'application GUI et la commande- processus de ligne qui fait réellement le travail. Lorsque l'interface graphique cesse de répondre, tout ce que vous avez à faire est de le tuer et de le redémarrer. Je n'ai jamais vu cette cause de corruption de données - il semble que ce soit juste l'application GUI qui se bloque; l'application de ligne de commande termine son travail ou ne démarre pas. C'est inoffensif mais ennuyeux, et apparemment les mainteneurs de mSysGit ne peuvent pas le reproduire (bien que je l'ai vu sur tous les ordinateurs sur lesquels j'ai essayé Git). De temps en temps, lorsque vous extrayez une branche différente, Git échouera silencieusement à créer tous les fichiers de la nouvelle branche sur le disque; Donc, si vous regardez le statut, vous verrez un fichier "supprimé" (je ne pense pas avoir vu plus d'un ou deux) prêt à être mis en scène. Je ne l'ai jamais rencontré depuis la ligne de commande, donc je ne sais pas si le checkout donne un avertissement, mais si vous quittez l'interface graphique, rien ne vous indique que quelque chose ne va pas, sauf si vous effectuez une nouvelle recherche. Cela arrive assez rarement (peut-être une fois par semaine), mais vous le remarquerez lorsque vous effectuerez vos changements, avant de pouvoir faire des dégâts. Le fichier est toujours présent dans le référentiel; vous avez juste besoin de réinitialiser (ou de rétablir les modifications sur ce fichier) pour le remettre dans votre copie de travail.

Les deux sont simplement des ennuis; vous n'avez pas besoin d'être particulièrement vigilant pour eux, vous avez juste besoin de patience pour nettoyer quand ils se produisent.

+0

Ce n'est pas trop surprenant, étant donné qu'un très grand nombre de Git est écrit en C, et donc la plupart du noyau est le même code compilé sur Windows à la place. (De toute évidence, la portabilité peut parfois être un cauchemar, mais quand même!) – Cascabel