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

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

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

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

Плюсы:

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

(На самом деле мне еще не «нужна» распределенная сторона вещей, кроме возможности иметь локальный репозиторий и передавать его в общедоступный.)

Минусы:

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

В Ските их больше всего, но:

Pro:

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

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

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

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

Кроме того, я не на 100% счастлив, что вам нужно постоянно «добавлять» существующие файлы [РЕДАКТИРОВАТЬ] и огромное количество функций. Для новичка они ошеломляют, и часто непонятно, почему вы хотите использовать определенную опцию / команду. Я имею в виду, что в CVS есть, скажем, 20 команд. GIT поставляется с 73, и у каждого есть множество опций (и это не считая сантехнических команд ...).

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

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

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

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

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

У меня также установлен Git на внешнем жестком диске и на моем джамп-драйвере. На новом компьютере я запускаю сценарий, который временно устанавливает путь для включения инструментов Git. Тогда можно продолжать развиваться!

Pro:

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

Минусы:

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

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

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

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

Короче говоря: это позволяет сохранить вашу историю в чистоте.

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

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

Прочие соображения:

Плюсы:

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

Минусы:

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

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

Хотя svn и другие современные VCS, такие как hg или другие, являются хорошими и полезными инструментами, git - это магазин, полный станков. Это одновременно и плюсы, и минусы. В то время как svn имеет 30 команд (согласно svn help), git содержит 130 справочных страниц, каждая из которых более или менее описывает одну команду. Одна из причин этого заключается в том, что git предоставляет функции нижнего уровня, которые когда-либо понадобятся большинству пользователей, как инструменты командной строки. Но даже без этих низкоуровневых команд git поставляет множество очень мощных инструментов и не встречается ни в одной другой известной мне VCS (см. Примеры git-bisect, git-filter-branch, мерзавец или 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)

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

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

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

Доступ для записи

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

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

Плюсы:

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

Минусы:

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

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