Каковы ваши плюсы и минусы git после его использования?

Ответ 1

У меня нет большого опыта работы с git, но:

Плюсы:

• Это действительно быстро
• Локальный коммит рок
• Быстрый запуск нового репозитория (без конфигурации и т.д.)
• github прост в использовании

(Я еще не "нуждался" в распределенной стороне вещей, кроме возможности иметь локальный репозиторий и нажимать на публичный.)

Минусы:

• Поддержка Windows по-прежнему отстает, я полагаю, и вы не можете просто использовать ее из обычной командной строки
• Отсутствие интеграции с IDE и Explorer
• Мне потребовалось некоторое время, чтобы найти хороший вводный текст в соответствии с книгой-редактором.
• Тот факт, что "добавление" измененного файла только добавляет содержимое в этот момент времени (поэтому он может отображаться как поставленный для фиксации и все еще иметь модификации, для которых требуется другой git add), потребовалось некоторое время, чтобы понять

Ответ 2

Количество команд

В то время как svn и другие современные VCS, такие как hg или другие, являются приятными и полезными инструментами git - это магазин, полный станков. В то же время это означает, что вы и профессионалы. Хотя svn имеет 30 команд (согласно "svn help" ) git отправляет 130 man-страниц с более или менее каждым из них, описывающим одну команду. Одна из причин этого заключается в том, что git предоставляет функции нижнего уровня, которые большинство пользователей будут когда-либо использовать в качестве инструментов командной строки. Но даже без этих команд низкого уровня git поставляется много очень мощных инструментов и не встречается ни в одном другом VCS, который я знаю (см. git-bisect, git-filter-branch, git-cherry или git-reset для примера). Хотя очень полезно иметь эти инструменты под рукой, для начинающего очень сложно понять, какую команду им нужно и что нужно знать, а какие нет.

Модель разработки

Аналогичная тема состоит в том, что git достаточно мощный, чтобы поддерживать очень разные режимы работы. Это затрудняет для новичков, поскольку на самом деле нет документа "лучшей практики", поскольку наилучшая практика не строится на git. Поэтому вы должны сами решить,

• Просто используйте слияния, чтобы избежать конфликтов с вами, работая с dir
• Используйте частные ветки, которые переустанавливаются вверх по HEAD
• Использовать ветки upstream
  • которые регулярно сливаются (летающая рыба)
  • слито при завершении
• Используйте дерево одного поддерживающего проекта, поддерживающие дерево, поддерживающие вспомогательные системы, поддерживающие драйверы и вкладчики с каждым уровнем, вытягивающим патчи с уровня ниже (ядро linux).

Поскольку у вас есть локальный репозиторий, вы можете даже использовать совершенно другой режим работы, чем проект, над которым работаете, и просто корректировать свои наборы изменений, прежде чем нажимать/публиковать их.

Путь изменений

Еще одна вещь, которая также рассчитывается как pro и con в зависимости от вашей точки зрения, заключается в том, что работа с git сложнее, чем с любым централизованным VCS и еще более сложным большинством других распределенных VCS.

При централизованном VCS вы обычно делаете фиксацию, и внесенные вами изменения переходят в репозиторий. В git изменения могут пройти довольно большое количество шагов, прежде чем они попадут в конечный пункт назначения. Типичные шаги (не столь распространенные шаги в скобках):

• Рабочий каталог (редактирование)
• Указатель aka промежуточная область (git добавить)
• Локальный репозиторий (git commit)
• (Другая локальная ветка) (git rebase, git cherry-pick, git merge)
• (вспомогательный репозиторий поддержки) (git push, git pull, mail)
• Репозиторий upstream (git push, git pull, mail)

Как вы можете пропустить индекс, есть как минимум 2 шага, но обычно их больше. Это требует более глубокого понимания того, что вы делаете, и ввода большего количества команд. С другой стороны, это дает вам контроль над каждым из этих шагов. Вы можете

• решить, какие компиляторы/строки входят в коммит и которые не являются
• решить, какие исправления вы хотите, в каких из ваших веток
• выберите, какие из ваших патчей будут опубликованы.
• переделка, сквош, исправление, разделение, изменение порядка исправлений перед публикацией их
• решить, какие люди вам доверяют, и принимать патчи от
• делегировать часть проекта другому доверенному лицу, которому вы доверяете.

Вся эта сила и решения мешают начинающим начинать с git. После освоения они дают огромный контроль над кодом.

Доступ к записи

Один из основных профи для любого распределенного VCS заключается в том, что вкладчики не требуют доступа на запись, чтобы воспользоваться преимуществами VCS. Каждый, у кого есть доступ на чтение, может просто клонировать репозиторий, создавать ветки, когда это необходимо, и начинать сборку наборов патчей. Работа с cvs без доступа на запись - настоящая боль - с git нет большого различия, как получить свои исправления. Это не только техническое преимущество, но и экономия сложных обсуждений, действительно ли этот noobie должен получить доступ на запись.

Ответ 3

Pro:

• Быстро - очень быстро.
• Создание нового репо очень легко по сравнению с SVN
• Полное репо содержится только в одной папке .git - она ​​не добавит папку .SVN в каждую папку вашего кода (неважно, но мне она нравится).
• Ветвление проще
• GitHub!

Минусы:

• Невозможно проверить часть репозитория (например, только одну папку или только один файл).
• Не отслеживает пустые папки
• Плохая поддержка Windows (не сильно меня беспокоит - я использую Linux)
• Я все еще не нашел хорошего инструмента GUI для Git (я использую KDESVN для SVN). Не большая проблема, если вам комфортно с CLI.

Ответ 4

Многие люди отрицают это, но выбор инструмента управления исходным кодом влияет на то, как вы работаете. Раньше я много работал с Subversion, пока не обнаружил Git для меня. В основном я избегал ветвления в Subversion. Всякий раз, когда я не мог этого избежать, я предпочитал настраивать локальное зеркало (используя svk). Хотя разветвление легко выполняется как в Subversion, так и в Git, только Git делает слияние (и rebasing!) Весело, Subversion всегда была королевской болью, когда дело доходило до времени слияния.

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

Ответ 5

Поддержка Windows ужасна, поэтому я перешел на Mercurial, еще один DVCS, который так хорош.

Преимущества DVCS становятся очевидными, когда вы, например, имеете репозиторий на своем сервере в офисе и работаете на сайте. Возможность совершать локально без доступа к серверному офису (и этот откат при необходимости) является блестящим!

Ответ 6

Плюсы: Почему Git лучше, чем X

Ответ 7

Работа с git очень отличается от работы с другими системами управления версиями.

Наличие локального репозитория очень важно. Это означает, что вы можете использовать всю мощь системы управления версиями (и это много с git), никому не мешая. Если в вашем проекте есть спорная проблема, вы можете просто работать над ней в частном порядке - создавая ветки, складывая патчи и полируя их. Таким образом, вы можете вернуться с помощью сглаженного набора патчей. Но даже в "нормальной работе" гораздо лучше, если вы можете очистить свои патчи, прежде чем показывать их публике, и на самом деле отладка намного проще, если у вас есть нормальные исправления, а не только "концевые" снимки.

Прежде чем я совершу больший набор исправлений, я обычно переупорядочиваю исправления и исправления squash на свой новый код непосредственно в патч. Поэтому патчи выглядят так, как будто я никогда не ошибался. После этого мой частный филиал перевыполнен поверх HEAD, а затем толкнул. Обычно я никогда не использую слияние, поскольку он только загромождает историю.

Вкратце: он позволяет сохранить вашу историю чистой.

Это дает вам совсем другое представление о вашей работе. Он позволяет вам видеть текущее состояние как дополнение отдельных патчей, которые создают историю, которая не является только журналом, а тем, что вы ставите там специально. Патч-наборы - это кирпичи, из которых вы создаете свое приложение, и, если необходимо, переместитесь в нужное место.

Я никогда бы не добровольно возвращался к любой другой системе управления версиями, которую я использовал до git, или к любой системе управления версиями, которая не поддерживает rebase и локальные ветки и фиксирует.

Ответ 8

Слияние гораздо проще в git, так как создание ветвей является значением по умолчанию, а не дополнительной опцией. Поэтому, когда вам нужно что-то слить, вы просто фиксируете его, а затем вы объединяете две ветки (существующую и новую, которая git автоматически создается для вашей последней проверки).

Кроме того, при использовании git у вас всегда есть весь репозиторий. Вы можете зарегистрироваться в автономном режиме и слить позже (поскольку слияние намного проще).

Недостатком является то, что git он практически не используется на USB-накопителе в Windows. Windows отключает кеширование для них, а git работает с миллионами крошечных файлов. Кроме того, поддержка IDE по-прежнему отсутствует. Я не уверен, что последнее действительно проблема. Пользовательский интерфейс, который поставляется с git, довольно приятный.

Кроме того, я не на 100% счастлив, что вам нужно "добавлять" существующие файлы все время [EDIT] и огромное количество функций. Для новичков они подавляющие, и часто неясно, почему вы хотите использовать определенную команду option/. Я имею в виду, что CVS поставляется с, скажем, 20 командами. git поставляется с 73 и каждый имеет множество опций (и это не считается командами сантехники...).

Ответ 9

Другие соображения:

Плюсы:

• Гибкость: не применяется один, настоящий рабочий процесс
• Так быстро, что управление версиями становится второстепенной задачей
• Легкие ветки, легкая слияния и промежуточная область позволяют персонализировать рабочие процессы.
• Более мощный
• Очень компактные репозитории

Минусы:

• Нет встроенных элементов управления доступом
• Слабые инструменты для двоичных файлов. Не компактно изменяет двоичные файлы в репо и хранение двоичных файлов предотвращает автоматическую обработку окончаний строк в Windows.
• Может быть труднее учиться, потому что он более гибкий и более мощный. Не всегда соответствует семантике CVS/SVN и не организован вокруг файлов.

Ответ 10

Последняя версия Git может работать непосредственно в командной строке Window, так как я ее использую. Сейчас процесс довольно тривиальный.

У меня также есть Git, установленный на внешний жесткий диск и на моем переходе. Всякий раз, когда на новом компьютере я запускаю script, который временно устанавливает путь для включения инструментов Git. Затем вы можете продолжить разработку!

Ответ 11

Отличный вопрос, я давно использую SVN и чувствую себя довольно комфортно с ним. Но мне пришлось использовать Git пару раз, чтобы получить исходный код из разных проектов с открытым исходным кодом. Тем не менее, я не нашел времени, чтобы действительно узнать об этом. Стоит ли это?

Я также спрашиваю, в чем преимущества использования распределенного контроля версий над обычным VCS в качестве подрывной деятельности.

Ответ 12

У Skeet есть большинство из них, но:

Pro:

• Ветвление! Гораздо удобнее работать над кусками функциональности в отдельных ветвях и по-прежнему иметь возможность управлять версиями, чем иметь несколько вещей, происходящих в одной ветке. И как только вы решили, что вам нравится ветвление, вам нужно любить, как легко git делает его по сравнению с SVN

Ответ 13

Плюсы:

• все упомянутое выше

Минусы:

• странное поведение autocrlf в Windows

• невозможно переместить/переименовать репозиторий файла или dir insode и kepp его историю фиксации ( git mv просто удаляет файл из репо, переименовывает и снова добавляет его в репо, тем самым теряя все история)