Каковы ограничения Git на Windows?

везде, где я читал о Mercurial и Git, они обычно бросают строку или две, что подразумевает, что Git имеет ограниченную способность на окнах (из-за некоторых оболочек не могут быть портированы и т. д.) но я никогда не сталкивался с какой-то страницей, которая явно упоминает их. И большинство страниц немного старые.

каковы ограничения Git на Windows с точки зрения функциональности? И имеет ли необходимость запускать Git на MinGW и MSYS в Windows ограничения производительности?

3 ответов


EDIT: Итак, это 2016 год, шесть лет спустя, когда я написал оригинальный ответ ниже. Я использовал git и mercurial в течение нескольких лет, и я развивался на mac в течение нескольких лет. Я стал очень знаком и удобен с использованием git в командной строке, но для повседневной работы я использую SourceTree от Atlassian. Это не реклама, а просто примечание для обновления этого ответа. Программа является двойной абстракции: тот же интерфейс для Git/HG и тот же интерфейс для Windows / Mac. Когда вам приходится часто переключать платформы и проекты, это становится очень привлекательным.

написал руководство по настройке клиента и сервера для Git в Windows, у меня есть довольно хорошее представление о том, что можно ожидать. Кроме того, мой основной репозиторий (.git папка) - ~260 МБ исходного кода, поэтому это действительно не тривиальный тест производительности для повседневной работы Git в Windows.

мое общее впечатление, что Git на windows очень быстро для подавляющего большинства ситуаций, с которыми можно столкнуться, с одним действительно огромным исключением:git gui blame -C -C. По умолчанию git не будет обвинять файлы за пределами границ переименования файлов, а extra -C -C аргументы должны быть переданы, чтобы это произошло, но тогда все может действительно замедлиться. На современном оборудовании требуется 17 минут, чтобы создать полную аннотацию одного из наших больших исходных файлов ~20 kloc. Эта задержка действительно может нарушить вашу концентрацию.

в отношении cygwin:

я пробовал только один раз, и не для чего-то значительного. Я действительно хотел родное решение. По всем отзывам, git на cygwin работает достаточно хорошо.

о TortoiseGit

Фрэнк Ли проделал огромную работу, приведя теперь знакомый пользовательский интерфейс в мир Git. TortoiseGit запустился очень быстро, потому что большая часть пользовательского интерфейса была доступна из TortoiseSVN (и других инструментов, таких как TortoiseMerge), и я работал с этим интерфейсом очень много. В общем, это позволяет очень быстро работать с Git, если вы знакомы с TortoiseSVN. Разработчик приложил много усилий, чтобы использовать термины из мира TortoiseSVN и сопоставлять их с командами git. Например,вернуться действительно выполняет git checkout <file> под капотом.

в общем, работа с Git таким образом была довольно бесшовной, и я должен признать, что узнал Git при использовании интерфейса TortoiseGit: и это надо признать, что это было помехой моему образованию. TortoiseSVN-подобный просмотрщик журналов на самом деле не работает для распределенного рабочего процесса vcs (он работает достаточно хорошо, вы используете Git, как если бы это был SVN), и вы узнаете об этом позже, потому что проблемы возникают только тогда, когда есть много, много ветвей разработки ( и много лучше при обработке этого дисплея). И другая проблема заключается в том, что даже после использования TortoiseGit в течение многих месяцев я все еще не знал даже самых простых команд git. В TortoiseGit нет ничего плохого, и ошибки исправляются впечатляюще быстро, когда они происходят; основная проблема, похоже, заключается в проблеме дизайна (возможно, более одного) в пользовательском интерфейсе, что-то gitk и git gui разработчики разработали из-за более длинной истории разработки или более глубокого знания идиоматического использования git или чего-то подобного.

относительно использования командной строки:

в команда разработчиков MSYS git это те, кого действительно следует поблагодарить за то, что они даже потрудились сделать всю работу, которую они сделали, и без их поддержки, вероятно, ветка mingw git никогда бы даже не была объединена с mainline.

теперь я начал использовать msysgit, как есть, в Git Bash shell, как мой единственный интерфейс git в течение нескольких недель. У меня сложилось впечатление, что, хотя первоначальное обучение кажется более трудным, как только это знание получено, все остальное становится проще. этой ссылке, на мой взгляд, одна из действительно лучших ссылок на обучение git в командной строке.

говоря как пользователь Git в Windows и исходя из расширенного опыта использования интерфейса TortoiseGit для git, это сводка моего рабочего процесса ,которая охватывает > 95% того, что необходимо (все в Git Bash,не командная оболочка Windows (cmd)):

  • проверить Модификации

    статус git

  • переключатель филиала

    git checkout some-feature-branch

  • Fetch

    git fetch

  • Показать Журнал (the & отсоединяется gitk процесс из оболочки, так что оболочка не ждет gitk быть закрытым, прежде чем разрешить больше команд)

    gitk&

  • Commit: или

    • простая фиксация:

      git commit-a-m "Это мое сообщение о фиксации"

    • сложные, несколько последовательных коммитов:

      git графический интерфейс

  • Push to branch: master

    git push origin master

  • слияние (например, после извлечение)

    git merge origin / master

мне еще не приходилось заниматься разрешением конфликтов, но я выясню это, когда придет время (комментарии приветствуются :).

EDIT:для разрешения конфликтов kdiff3-это путь. Настройка проста, и все от простых различий до трехстороннего слияния работает надежно и быстро.

выводы

  • Git на Windows является полнофункциональным, и работает, как рекламируется, и является не ограничено в Windows.

  • производительность обычно очень хорошая, но всесторонняя большая вина может быть медленным.

  • интерфейс TortoiseGit соблазнителен, но в конечном счете неудовлетворителен: вы должны попытаться изучить git в командной строке. Я сделал и то, и другое, и этот маршрут более эффективен.


  • сомнительная поддержка подстановочных знаков:
    (проблематично для .gitignore файлы)
    отправить в базовую ОС-specific fnname() способ: см.этот вопрос и этого (или этого)

  • git-svn может быть не очень быстрым.
    Источник:так что ответ. Однако он добился некоторого прогресса.

  • the PATH потребность быть отрегулированным для предотвращения любой конфликт
    Некоторые команды одинаковы между Windows и bash. (find, cp, rm, ...).
    Смотрите это так что ответ.
    As cjrh комментарии, Git для Windows не добавляет его bin каталог по умолчанию для PATH.

  • некоторые преобразования EOL может иметь место (Unix против Windows EOL)
    См.окончательная рекомендация для git autocrlf настройки.
    Новые и улучшенные core.eol и eol атрибуты из Git1.7.2 еще нет в msysgit.


(Это, вероятно, больше комментарий, чем ответ, но мой представитель еще не совсем там.)

недавно я задавался тем же вопросом, и я тоже не смог выкопать слишком много. вот одна интересная дискуссия (обнаружен с помощью цитата на записи Википедии Git).

насколько я могу судить, основными проблемами являются производительность (особенно на Cygwin и / или с большими репозиториями) и проблемы с файловой системой (нечувствительность к регистру имени файла, limited VFS).

чисто субъективное/анекдотично:

Я чувствую, что Git-гораздо более приятный опыт работы под Ubuntu 10.04, чем на Cygwin под Win7 на той же машине-настолько, что я перенес почти всю свою внештатную работу по веб-разработке на Ubuntu, чтобы воспользоваться этим (среди прочего). Я узнал Git на своей машине OSX на работе, поэтому попытка работать с ним на Windows впоследствии была почти болезненной. msysgit определенно улучшение по сравнению с Cygwin, но он по-прежнему страдает от ограничений файловой системы Windows.

редактировать: видимо, msysgit подавляется именами файлов, которые были введены в git через файловую систему с поддержкой UTF8, например Linux, которая засасывает.

Я тоже просто наткнулся GitSharp, собственная реализация Windows WIP (через этот комментарий в блоге).