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

Я использую SVN прямо сейчас, и раньше я использовал CVS и VSS. Сейчас в моих книгах фаворитом является SVN, но я много слышал о git. Какие плюсы и минусы из вашего опыта у людей, которые использовали git?

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

Petr 30.07.2014 10:24

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

Chance 02.06.2015 16:14
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
41
2
21 255
13
Перейти к ответу Данный вопрос помечен как решенный

Ответы 13

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

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

Ответ принят как подходящий

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

Плюсы:

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

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

Минусы:

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

Что касается книг - это бета-книга от программистов-прагматиков: pragprog.com/titles/tsgit/pragmatic-version-control-using-gi‌ t

Abizern 09.12.2008 17:35

На самом деле нет проблем с использованием Git из командной строки Windows. Некоторое время я без проблем использую msys Git из Powershell и cmd.exe. Что касается отсутствия интеграции с проводником, то для меня это профи :-))).

Milan Gardian 13.01.2009 17:19

Ох ... Я не понимал, что git подходит для обычного cmd.exe. Надо попробовать это ...

Jon Skeet 13.01.2009 17:25

При использовании установки msys Git 1.6.0.2 все, что вам нужно, это иметь "(git_install_dir) \ cmd" в вашем PATH. Я также рекомендую установить для параметров "color.interactive", "color.branch" и "color.status" значение "always" (git config) - так вы получите цветной вывод в "git status" (и других) даже при запуске из cmd.exe.

Milan Gardian 13.01.2009 18:04

TortoiseGIT, кажется, отлично работает, если вам нравится интеграция с проводником.

davenpcj 13.06.2009 18:00

@Jon, мне было бы интересно узнать, изменился ли вообще ваш ответ за последние 18 месяцев ...

Benjol 04.05.2010 10:20

@Benjol: Я считаю, что интеграция с Windows теперь лучше, и есть больше вариантов графического интерфейса. В настоящее время мне нравится Mercurial - я обнаружил, что это легче понять, чем Git.

Jon Skeet 04.05.2010 10:56

@Jon. Хм, да, это еще один, который мне еще предстоит попробовать. Мой мозг тает в водовороте git, AccuRev, Mercurial, Perforce, PlasticSCM, Bazaar! Спасибо за обновление.

Benjol 04.05.2010 16:23

Этому ответу уже более двух лет, и многое изменилось. Возможно, стоит обновить.

Nathan Ridley 23.01.2011 18:21

Если этап подготовки избыточен в вашем рабочем процессе, вы можете пропустить его, добавив -a в commit, например: $ git commit -a -m 'this commits all changed tracked files, staged or not'

Saeb Amini 28.04.2011 09:04

Это поворот ума! но как только вы к этому привыкнете, вы подумаете. "Как я вообще без него работал!" Почти как мобильный телефон сейчас, после того, как вы пережили эпоху поворотных телефонов :) Готов поспорить, вы думали, что вам тогда не нужен был смартфон, чтобы выжить.

WeSam Abdallah 06.11.2015 01:09

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

Pro:

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

Мне всегда было достаточно просто в svn (и я часто им пользовался), но я еще не пробовал это в git.

Jon Skeet 05.12.2008 15:57

Ветвление не намного проще, чем SVN, но слияние в git тривиально. Это огромная разница.

Colonel Sponsz 05.12.2008 16:01

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

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

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

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

Git commit -a в сочетании с приличным .gitignore решает проблему добавления существующих файлов.

Colonel Sponsz 05.12.2008 16:03

Поддержка 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-gui и qgit

Benedikt Waldvogel 06.12.2008 16:46

Вы не можете проверить часть репо, потому что это концепция распределенного контроля версий, что вы, как пользователь, должны иметь полное репо на вашем локальном компьютере. Имейте в виду, что только один раз, когда вы клонируете проект на локальную машину, вы извлекаете все данные. Следующее нажатие даст вам только изменения.

Marcin Waśniowski 24.01.2013 03:58

Работа с 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 нет большой разницы в том, как получить ваши патчи. Это не только техническое преимущество, но и избавляет от сложных дискуссий, должен ли этот новичок действительно иметь доступ для записи.

По крайней мере, некоторые из перечисленных вами команд не уникальны. Mercurial имеет команду bisect (hgbook.red-bean.com/hgbookch9.html#x13-1880009.5), Subversion имеет svndumpfilter.

Constantin 03.01.2009 14:17

Плюсы:

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

Минусы:

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

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

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

Bob Kerns 05.10.2012 00:38

Другие вопросы по теме