Каковы ваши плюсы и минусы мерзавца после его использования?
Я использую SVN прямо сейчас, и я использовал CVS и VSS в прошлом. SVN - фаворит в моих книгах, но я много слышал о git. Из тех людей, которые использовали git, каковы плюсы и минусы вашего опыта?
13 ответов
У меня нет большого опыта работы с git, но:
Плюсы:
- Это действительно быстро
- Местные коммиты рок
- Быстрый запуск нового репозитория (без настройки и т. Д.)
- GitHub прост в использовании
(Мне пока что "не нужна" распределенная сторона вещей, кроме возможности иметь локальный репозиторий и публиковать его в общедоступном).
Минусы:
- Я считаю, что поддержка Windows все еще отстает, и вы не можете просто использовать ее из обычной командной строки
- Отсутствие интеграции IDE и Explorer
- Мне потребовалось некоторое время, чтобы найти хороший вводный текст в духе книги о красных бобах.
- Тот факт, что "добавление" измененного файла только добавляет содержимое в этот момент времени (поэтому он может отображаться как подготовленный для фиксации и при этом иметь модификации, требующие другого
git add) потребовалось время, чтобы понять
Количество команд
В то время как svn и другие современные VCS, такие как hg или другие, являются хорошими и полезными инструментами, git- это магазин, полный станков. Это считается как за и против одновременно. В то время как svn имеет 30 команд (согласно 'svn help'), git отправляет 130 страниц руководства, каждая из которых более или менее описывает одну команду. Одна из причин этого заключается в том, что git предоставляет функции более низкого уровня, которые большинству пользователей когда-либо понадобятся в качестве инструментов командной строки. Но даже без этих команд низкого уровня git поставляет много очень мощных инструментов и не встречается ни в одной другой VCS, которую я знаю (см. Примеры git-bisect, http://git-scm.com/docs/git-filter-branch, git-cherry или git-reset). Хотя очень полезно иметь эти инструменты под рукой, новичку очень трудно понять, какая команда им нужна, а какую - нет.
Модель развития
Подобная тема в том, что git достаточно мощный, чтобы поддерживать самые разные режимы работы. Это затрудняет работу начинающих, так как на самом деле не существует документа "передовой опыт", поскольку передовой опыт не встроен в git. Таким образом, вы должны решить, сами ли вы
- Просто используйте слияния, чтобы избежать конфликтов с вами
- Используйте частные ветки, которые перебазируются в верхний уровень HEAD
- Используйте ветки вверх по течению
- которые регулярно объединяются (летучая рыба)
- объединены когда закончено
- Используйте дерево одного сопровождающего проекта, сопровождающих деревьев, сопровождающих подсистем, сопровождающих драйверов и участников с каждым уровнем, тянущим патчи с уровня ниже (ядро Linux)
Поскольку у вас есть ваш локальный репозиторий, вы можете даже использовать совсем другой режим работы, чем проект, над которым вы работаете, и просто настроить свои наборы изменений перед их отправкой / публикацией.
Путь перемен
Еще одна вещь, которая также считается за и против в зависимости от вашей точки зрения, заключается в том, что работа с git более сложна, чем с любой централизованной VCS, и даже более сложна в большинстве других распределенных VCS.
С централизованным VCS вы обычно делаете коммит, а сделанные вами изменения отправляются в хранилище. В git изменения могут пройти довольно большое количество шагов, прежде чем они окажутся в конечном пункте назначения. Типичные шаги (не так часто встречающиеся шаги в скобках):
- Рабочий каталог (редактирование)
- Индекс, также известный как область подготовки (git add)
- Локальный репозиторий (git commit)
- (Другое местное отделение) (git rebase, git cherry-pick, git merge)
- (хранилище суб-сопровождающего) (git push, git pull, mail)
- Верхний репозиторий (git push, git pull, mail)
Как вы можете пропустить индекс, как минимум, 2 шага, но обычно их больше. Это требует более глубокого понимания того, что вы делаете, и ввода гораздо большего количества команд. С другой стороны, это дает вам контроль над каждым из этих шагов. Вы можете
- решить, какие джонки / строки идут в коммит, а какие нет
- решить, какие патчи вы хотите в каком из ваших местных филиалов
- решить, какие из ваших патчей опубликованы
- переделывать, сквошить, исправлять, разбивать, переупорядочивать патчи перед их публикацией
- решайте сами, кому вы доверяете, и принимаете патчи от
- делегировать части проекта другому сопровождающему, которому вы доверяете.
Вся эта мощь и решения затрудняют начинающих работать с git. После освоения они дают огромный контроль над кодом.
Доступ для записи
Одним из главных плюсов для любой распределенной VCS является то, что участникам не требуется доступ на запись, чтобы извлечь выгоду из VCS. Каждый, у кого есть права на чтение, может просто клонировать репозиторий, создавать ветки, когда это необходимо, и начинать складывать патчи. Работать с cvs без доступа для записи - настоящая боль - с git нет большой разницы в том, как получить ваши патчи. Это не только техническое преимущество, но и экономит сложные дискуссии о том, должен ли этот новичок действительно получить доступ на запись.
Pro:
- Быстро - очень быстро.
- Создать новый репо очень просто по сравнению с SVN
- Полный репо содержится только в одной папке.git - он не будет добавлять папку.SVN в каждую папку вашего кода (не страшно, но мне это нравится)
- Ветвление проще
- GitHub!
Минусы:
- Невозможно извлечь часть хранилища (например, одну папку или один файл)
- Не отслеживает пустые папки
- Плохая поддержка Windows (меня не особо беспокоит - я использую Linux)
- Я до сих пор не нашел хороший инструмент с графическим интерфейсом для Git(я использую KDESVN для SVN). Не большая проблема, если вам удобно с CLI.
Многие люди отрицают это, но выбор инструмента управления исходным кодом влияет на вашу работу. Я много работал с Subversion, пока не открыл для себя Git. Я в основном избегал ветвления в Subversion. Всякий раз, когда я не мог избежать этого, я предпочитал настраивать локальное зеркало (используя svk). Хотя ветвление легко выполняется как в Subversion, так и в Git, только Git делает слияние (и перебазирование!) Увлекательным, Subversion всегда была королевской болью, когда речь шла о времени слияния.
Второе, что мне действительно нравится в Git (кроме всех уже упомянутых моментов), это "индекс", промежуточная область, в которой хранится ваш следующий коммит, и возможность добавлять в него только отдельные фрагменты измененного файла.
Поддержка Windows ужасна, поэтому я перешел на Mercurial, еще одну DVCS, которая так же хороша.
Преимущества DVCS становятся очевидными, когда, например, у вас есть хранилище на вашем сервере в офисе, и вы работаете на месте. Возможность совершать локальные коммиты без доступа к вашему серверу (и этот откат при необходимости) просто великолепна!
Работа с git сильно отличается от работы с другими системами контроля версий.
Наличие локального хранилища очень важно. Это означает, что вы можете использовать всю мощь системы управления версиями (и это много с git), не мешая никому. Если в вашем проекте есть спорная проблема, вы можете просто поработать над ней в частном порядке - создавая ветки, складывая патчи и полируя их. Таким образом, вы можете вернуться с набором патчей. Но даже в "нормальной работе" гораздо лучше, если вы можете очистить свои патчи перед их публичным показом, и на самом деле отладка намного проще, если у вас есть нормальные патчи, а не просто снимки "в конце дня".
Перед тем, как зафиксировать больший набор патчей, я обычно переупорядочиваю патчи и исправления ошибок в моем новом коде непосредственно в патче. Так что патчи выглядят так, будто я никогда не ошибался. После этого моя частная ветка перезагружается поверх HEAD, а затем выдвигается. Обычно я никогда не использую слияние, поскольку оно только загромождает историю.
Короче говоря: это позволяет сохранить вашу историю в чистоте.
Это дает вам совершенно иной взгляд на вашу работу. Это позволяет вам видеть текущее состояние как дополнение отдельных патчей, которые создают историю, которая является не просто журналом, а чем-то, что вы специально добавили туда. Наборы патчей - это кирпичики, из которых вы строите свое приложение, и, при необходимости, перемещайтесь в нужное место.
Я никогда не вернусь добровольно к любой другой системе управления версиями, которую я использовал до git, или к любой системе управления версиями, которая не поддерживает rebase и локальные ветки и коммиты.
Слияние в git намного проще, так как создание веток является по умолчанию, а не дополнительной опцией. Поэтому, когда вам нужно объединить что-то, вы просто фиксируете это, а затем объединяете две ветви (существующую и новую, которая автоматически создается git для вашей последней регистрации).
Кроме того, при использовании git у вас всегда есть целый репозиторий. Вы можете зарегистрироваться в автономном режиме и объединить позже (поскольку объединение намного проще).
Недостатком является то, что GIT его практически невозможно использовать на USB-накопителе в Windows. Windows отключает их кэширование, и GIT работает с миллионами крошечных файлов. Кроме того, поддержка IDE по-прежнему отсутствует. Я не уверен, что последнее действительно является проблемой. Пользовательский интерфейс, который поставляется с GIT, довольно хорош.
Кроме того, я не на 100% рад, что вам приходится все время "добавлять" существующие файлы [РЕДАКТИРОВАТЬ] и огромное количество функций. Для новичка они ошеломляют, и часто неясно, почему вы хотите использовать определенную опцию / команду. Я имею в виду, что CVS включает, скажем, 20 команд. GIT поставляется с 73, и у каждого есть много опций (и это не считая сантехнических команд...).
Другие соображения:
Плюсы:
- Гибкость: не обеспечивает единый, истинный рабочий процесс
- Настолько быстро, что контроль версий становится второстепенной задачей
- Легкие ветви, простота слияния и области подготовки позволяют персонализированные рабочие процессы
- Более могущественный
- Очень компактные репо
Минусы:
- Нет встроенного контроля доступа
- Слабые инструменты для бинарных файлов. Не сжимает изменения в бинарных файлах в репо, а хранение бинарных файлов предотвращает автоматическую обработку окончаний строк в Windows.
- Может быть труднее учиться, потому что он более гибкий и более мощный. Не всегда следует семантике CVS/SVN и не организован вокруг файлов.
Последняя версия Git может работать непосредственно в командной строке Window, как я ее использую. Процесс довольно тривиален для меня сейчас.
У меня также есть Git, установленный на внешнем жестком диске и на моем JumpDrive. Всякий раз, когда я на новом компьютере, я запускаю скрипт, который временно устанавливает путь для включения инструментов Git. Тогда вы можете продолжить развитие!
Отличный вопрос, я давно пользуюсь SVN и чувствую себя довольно комфортно. Но мне пришлось пару раз использовать Git для получения исходного кода из разных проектов с открытым исходным кодом. Тем не менее я не нашел время, чтобы действительно узнать об этом. Стоит ли оно того?
Я также хотел бы спросить, каковы преимущества использования распределенного контроля версий над обычным VCS в качестве subversion.
Скит имеет большинство из них, но:
Pro:
- Ветвление! Намного приятнее работать с кусками функциональности в отдельных ветвях и при этом иметь возможность управлять версиями, чем иметь несколько вещей, происходящих в одной ветке. И как только вы решили, что вам нравится ветвление, вам должно понравиться то, как легко это делает git по сравнению с SVN.
Плюсы:
- все упомянутое выше
Минусы:
странное поведение autocrlf в Windows
невозможность переместить / переименовать файл или dir insode репо и сохранить его историю коммитов (git mv просто удаляет файл из репо, переименовывает и снова добавляет его в репо, тем самым теряя всю историю)