Почему все используют Git централизованно?

Я использовал Git в своих последних двух компаниях для контроля версий. Из того, что я слышал, кажется, что около 90% компаний используют Git поверх других систем контроля версий.

Один из главных плюсов Git в том, что он децентрализован, то есть все репозитории равны; нет центрального хранилища / источника правды. Эту особенность отстаивал Линус Торвальдс .

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

Мои вопросы:

1. Почему люди не используют распределенный рабочий процесс для Git на практике?
2. Является ли способность работать распределенным образом даже важной для современного контроля версий, или это просто звучит хорошо?

редактировать

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

Ааа, но на самом деле вы которые с помощью мерзавца децентрализованно!

Давайте сравним предшественника git в mindshare, svn. У Subversion было только одно «репо», один источник правды. Когда вы делали коммит, это было единственное центральное репо, к которому также привязывался любой другой разработчик.

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

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

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

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

Когда сборка сервер (вы которые используете CI, правильно?) Создает сборку, где это вытащить из? Конечно, сборка интеграции, на которую вы могли бы возразить, не нуждается в «одном истинном репо», но, безусловно, делает сборку дистрибутива (т.е. то, что вы даете клиенту).

Другими словами: фрагментация. Если вы назначите одно репо как «репо» и назначите опекунов, которые будут проверять запросы на извлечение, у вас будет простой способ удовлетворить запрос «дайте мне сборку программного обеспечения» или «я новичок в команде, где код?»

Сила DVCS заключается не столько в его одноранговом аспекте, сколько в том, что он иерархический . Я изменяю свое рабочее пространство, затем я фиксирую локальное. Как только у меня есть готовая функция, я объединяю свои коммиты и отправляю их на пульт. Затем любой желающий может увидеть мой предварительный код, оставить отзыв и т. Д., Прежде чем я создам запрос на извлечение, и администратор проекта объединяет его с репозиторием One True.

С традиционным CVCS вы либо фиксируете, либо нет. Это хорошо для некоторых рабочих процессов (я использую оба типа VCS для разных проектов), но не подходит для публичного проекта или проекта OSS. Ключевым моментом является то, что DVCS имеет несколько этапов, которые являются более трудоемкими, но обеспечивают лучший способ интеграции кода от незнакомых людей с помощью встроенного процесса, который обеспечивает лучшую видимость того, что проверяется. Использование его централизованно означает, что вы все еще можете иметь этот золотой стандарт текущего состояния проекта, а также обеспечивает лучший механизм совместного использования кода.

Я не знаю, как вы определяете «всех», но у моей команды есть «центральное репо на сервере», а также время от времени мы извлекаем репо других коллег, не проходя через это центральное репо. Когда мы делаем это, мы по-прежнему обращаемся к серверу, потому что мы решаем не рассылать исправления о месте, а не через центральный репозиторий. Обычно это происходит, когда группа сотрудничает над определенной функцией и хочет быть в курсе друг друга, но пока не заинтересована в публикации этой функции для всех. Естественно, поскольку мы не скрытные работники бункеров, такие ситуации продолжаются недолго, но DVCS предоставляет гибкость, позволяющую делать все, что угодно. Мы можем публиковать ветку или нет по вкусу.

Но 90% + времени, конечно, мы идем через центральное репо. Когда меня не волнуют какие-то конкретные изменения или работа конкретного коллеги, это более удобно и лучше масштабируется, чтобы извлекать «изменения всех моих коллег, которые были проверены в центральном репо», а не отдельно извлекать изменения из каждого из N коллеги. DVCS не пытается помешать «извлечению из основного репо», являющемуся наиболее распространенным рабочим процессом, он пытается не допустить, чтобы он был единственным доступным рабочим процессом.

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

Если «действительно децентрализованные» означает «нет специальных репо» , то я не думаю , что это то , что Линус значит чемпион, учитывая , что в действительности он делает поддерживать специальные операции РЕПО , которые являются более важными в великой схеме вещей, чем какой-то случайный клон Linux, который я сделал вчера и планирую использовать только для разработки небольшого патча, а затем удалить его, как только он примет патч. gitего привилегия не превосходит мою, но Линус делает это привилегией. Его "текущее состояние Linux", мое нет. Так естественно изменения имеют тенденциюпройти через Линуса. Сила DVCS над централизованными VCS не в том, что не должно быть фактического центра, а в том, что изменения не должны проходить через какой-либо центр, потому что (если позволяют конфликты) любой может объединить что угодно.

Системы DVCS также вынуждены , поскольку они децентрализованы, предоставлять определенные удобные функции, основанные на том факте, что вы обязательно должны иметь полную историю (то есть репо) локально, чтобы что-либо делать. Но если подумать, нет фундаментальной причины, по которой вы не могли бы настроить централизованную VCS с локальным кешем, который хранит всю историю операций, доступных только для чтения, которые могут быть устаревшими (я думаю, что у Perforce есть опция для этого режима, но я никогда не использовал Perforce). Или в принципе вы можете настроить gitс вашим.git/каталог на удаленно смонтированной файловой системе, чтобы эмулировать «особенность» SVN, которая не работает, если у вас нет сетевого подключения. По сути, DVCS заставляет сантехнику быть более надежной, чем в централизованной VCS. Это (очень приятный) побочный эффект, который помог мотивировать дизайн DVCS, но такое распределение ответственности на техническом уровне не то же самое, что полная децентрализация всей ответственности человека .

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

Чтобы заняться редактированием, возможно, вам нужен некоторый опыт работы с реальным централизованным управлением версиями, чтобы оценить различия, потому что, хотя они могут показаться неуловимыми, они широко распространены. Это все, что моя команда фактически делает на работе, чего мы не могли сделать, когда у нас была централизованная VCS:

• Иметь очень маленький список основных разработчиков с коммитным доступом к «центральному» репо для каждого микросервиса. Все остальные могут работать из вилок и отправлять запросы по запросу.
• Может совершать гораздо чаще, обычно несколько раз в час, а не один или два раза в день.
• Может создавать ветви по любой причине, чтобы временно координировать свои действия с коллегами, нажимать на них и извлекать из них несколько раз в день, а затем раздавливать их, когда они готовы поделиться с большой группой. Вы хоть представляете, как сложно получить разрешение на создание временной ветки для чего-то подобного в традиционной CVCS?

Рискнувшись звучать старо, чтобы сказать это, вы действительно не знаете, как легко это у вас получается.

Я думаю, что ваш вопрос исходит из (понятного) всегда связанного мышления. т.е. центральный сервер 'true' ci всегда (или почти всегда) доступен. Хотя это верно в большинстве сред, я работал по крайней мере в одной, которая была далека от этого.

Проект военной симуляции, над которым моя команда работала несколько лет назад. Весь код (речь идет о кодовой базе> 1 млрд. Долл. США) должен был (по закону / международному соглашению, люди в темных костюмах, если вы этого не сделаете) находиться на машинах, физически изолированных от любого подключения к Интернету . Это означало, что у каждого из нас было по 2 компьютера: один для написания / запуска / тестирования кода, другой для работы с Google, проверки электронной почты и тому подобное. И в команде этих машин была локальная сеть, очевидно, никак не связанная с Интернетом.

«Центральным источником правды» была машина на военной базе, в подземной комнате без окон (без железобетона) (усиленное здание, яда-яда). Эта машина также не имела подключения к Интернету.

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

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

Кроме того, если вы рассматриваете что-то в масштабе ядра Linux ... Разработчики не просто отправляют запрос на извлечение самого Линуса. По сути, это иерархия репо - каждый из которых был / является «центральным» для кого-то / какой-то команды.

Отключенная природа git означает, что его можно использовать в средах, где подключенные инструменты управления исходным кодом модели ( например, SVN) не могут быть использованы или не могут использоваться так же легко.

В конечном счете, вы создаете продукт. Этот продукт представляет ваш код в определенный момент времени. Учитывая , что ваш код должен сливаться где - то . Естественной точкой является ci-сервер или центральный сервер, из которого построен продукт, и имеет смысл, что эта центральная точка является git-репозиторием.

Распределенный аспект DVCS все время проявляется в разработке с открытым исходным кодом в виде разветвления. Например, некоторые проекты, в которые я помогаю, были заброшены первоначальным автором, и теперь у них есть куча вилок, в которых сопровождающие иногда извлекают определенные функции друг из друга. Даже в целом, проекты OSS принимают внешние взносы посредством запроса извлечения, а не путем предоставления случайным людям принудительного доступа к репо «правда-земля».

Это не очень распространенный случай использования при создании конкретного продукта с определенным официальным выпуском, но в мире F / OSS это норма, а не исключение.

Почему все используют git централизованно?

Мы никогда не встречались, как получается, что вы говорите всем? ;)

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

Конечно, многие люди могут использовать его централизованно, как CVS или SVN. Но не забывайте о другой функции, которая по своей природе поставляется с распределенной VCS: все копии более или менее «завершены» (доступны все ветви и полная история), и все ветви можно извлечь без подключения к серверу.

Я считаю, что это еще одна особенность, которая не должна быть забыта.

Хотя вы не можете сделать это с готовыми CVS и SVN, Git можно использовать централизованно, как и предыдущие, без каких-либо проблем.

Таким образом, я могу зафиксировать свои изменения, возможно, сквошить текущие коммиты, а затем загрузить и переназначить свою работу в основную ветку разработки.

Другие функции, которые выходят из коробки с Git:

• криптографически подписывает коммиты
• перебазирование (изменение порядка и сквоша; редактирование коммитов, а не только сообщения)
• сбор вишни
• делить историю пополам
• местные отделения и скрытые изменения (так называемые "стеллажи" в Википедии)

Также посмотрите эти три таблицы в Википедии - Сравнение программного обеспечения для контроля версий :

• Особенности

• Основные команды

• Расширенные команды

Итак, еще раз, возможно, децентрализованная манера - не единственная особенность, которая заставляет людей использовать это.

1. Почему люди не используют распределенный рабочий процесс для Git на практике?

Любой, кто вносит свой вклад или организует большой проект на Bitbucked, GitHub и т. Д., Сделает это точно. Сопровождающие хранят «основной» репозиторий, а клонатор-участник клонирует, фиксирует, а затем отправляет запрос на извлечение.

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

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

Как всегда: это зависит от требований.

Используйте децентрализованную VCS, если применимо какое-либо условие:

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

Есть еще несколько, но четыре должно быть достаточно.

... или это просто красиво звучит?

Конечно, это звучит хорошо - для начинающих.

Гибкость - это и проклятие, и благословение. И как Git является чрезвычайно гибким, это почти всегда далеко слишком гибким для типичной ситуации. В частности, большинство проектов Git не являются Linux.

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

Однако ваш git-клиент почти наверняка по умолчанию использует модель «единственного предка». А графики, в которых узлы имеют одного предка (кроме корневого узла), являются в точности деревьями. Таким образом, ваш клиент git по умолчанию использует древовидную модель и, следовательно, централизованные репозитории.

Бизнес-логика вознаграждает централизованный сервер. Почти для всех реалистичных бизнес-сценариев централизованный сервер является фундаментальной особенностью рабочего процесса.

Тот факт, что у вас есть возможность создавать DVCS, не означает, что основным рабочим процессом должна быть DVCS. Когда я использую git на работе, мы используем его централизованно, за исключением тех странных странных случаев, когда распределенный бит был необходим для продолжения работы.

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

Чтобы коллега мог вытащить git-репозиторий на моей машине, мне нужно, чтобы git-демон работал на корневом уровне в качестве фоновой задачи. Я очень осторожен с демонами, работающими на моем собственном компьютере или на ноутбуке, предоставленном компанией. Самое простое решение - «НЕТ»! Для того, чтобы коллега вытащил git-репо на моей машине, это также означает, что мой интернет-адрес должен быть исправлен. Я путешествую, я работаю из дома, и я иногда работаю из своего офиса.

С другой стороны, VPN-соединение с корпоративным сайтом и продвижение филиала к центральному репо занимает меньше минуты. Мне даже не нужен VPN, если я в офисе. Мои коллеги могут легко вытащить из этой ветви.

С третьей стороны, мой локальный репозиторий Git - это полнофункциональный репозиторий. Я могу поручить новую работу, создать новую ветку для экспериментальной работы и вернуться к работе, когда я что-то путаю, даже когда я работаю в самолете, летящем на высоте 30 000 футов над серединой нигде. Попробуйте сделать это с централизованной системой контроля версий.

Сложность:

С центральным хранилищем типичный рабочий процесс может быть

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

Сложность по отношению к числу разработчиков в O (1).

Если вместо этого у каждого разработчика есть собственная ветка master, то для разработчика это становится 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Одноранговый подход - O (N).

Последовательность:

Теперь рассмотрим, существует ли конфликт слияния между главной ветвью Алисы и главной ветвью Боба. Каждый из N разработчиков может разрешить конфликт по-своему. Результат: хаос. Существуют способы достижения возможной согласованности, но пока это не произойдет, все виды времени разработчика могут быть потрачены впустую.

Просто:

Компании - это централизованные организации с централизованным рабочим процессом.

У каждого программиста есть босс, и у него есть свой босс и т. Д. До технического директора. CTO - основной источник технической правды. Какой бы инструмент компания ни использовала, она должна отражать эту цепочку команд. Компания похожа на армию - вы не можете позволить рядовым переиграть генерала.

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

Чтобы ответить на ваш вопрос: распределенная часть действительно лучше в распределенной среде, например, с открытым исходным кодом. Результаты варьируются в зависимости от того, кто говорит. Линус Торвальдс - не совсем ваша крыса, поэтому для него важны различные функции GIT, а не для вашей компании, ориентированной на github.

Возможно, это потому, что он обрабатывает платежную ведомость централизованно, поэтому нам нужно, чтобы центральный человек был доволен, если мы хотим получать оплату.

Возможно, это потому, что мы создаем один продукт, поэтому нам нужна мастер-копия программного обеспечения для клиентов.

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

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

Быть централизованным - это прекрасно, пока не возникнет проблема ...

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

Возможность выполнять слияние и т. Д. На локальной копии репозитория, когда сеть не работает, это здорово, но не требует распределенной системы; ему просто нужна система, которая хранит локальную копию всех данных. Аналогично проверке кода с полетом и т. Д.

В конце концов, есть небольшие затраты на распространение и некоторые преимущества. Большая часть затрат на распространение приходится на область, которая необходима, если вы хотите иметь отличное отслеживание филиалов и т. Д. Если бы вы разрабатывали систему для использования в большинстве компаний, вы бы не планировали ее распространение, как централизованное управление исходным кодом. явно является основным «вариантом использования».