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

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

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

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

Мои вопросы:

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

Изменить

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

279 голосов | спросил gardenhead 9 PMpSat, 09 Apr 2016 18:40:04 +030040Saturday 2016, 18:40:04

14 ответов


251

Ahh, но на самом деле вы , используя git децентрализованным образом!

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

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

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

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

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

ответил Michael Hampton 10 AMpSun, 10 Apr 2016 02:24:28 +030024Sunday 2016, 02:24:28
119

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

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

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

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

ответил 9 PMpSat, 09 Apr 2016 19:17:33 +030017Saturday 2016, 19:17:33
39

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

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

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

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

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

ответил Steve Jessop 10 AMpSun, 10 Apr 2016 02:57:38 +030057Sunday 2016, 02:57:38
27

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

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

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

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

ответил Karl Bielefeldt 10 AMpSun, 10 Apr 2016 00:40:17 +030040Sunday 2016, 00:40:17
18

Я думаю, что вы задаетесь вопросом (понятным) всегда подключенным мышлением. i.e. Центральный сервер «правда» ci всегда (или почти всегда) доступен. Хотя это верно в большинстве сред, я работал, по крайней мере, в том, что было далеко от этого.

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

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

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


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

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

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

ответил Tersosauros 10 PMpSun, 10 Apr 2016 22:04:16 +030004Sunday 2016, 22:04:16
17

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

ответил Bryan Oakley 10 AMpSun, 10 Apr 2016 01:20:10 +030020Sunday 2016, 01:20:10
14

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

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

ответил fluffy 10 AMpSun, 10 Apr 2016 06:04:35 +030004Sunday 2016, 06:04:35
9
  

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

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

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

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

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

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

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

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

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

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

Итак, возможно, децентрализованная манера не , что только функция, которая заставляет людей использовать ее.

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

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

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

  
  1. Способность работать в распределенной форме даже важна для современного контроля версий, ...
  2.   

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

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

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

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

  

... или это просто здорово?

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

ответил try-catch-finally 10 PMpSun, 10 Apr 2016 16:35:51 +030035Sunday 2016, 16:35:51
5

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

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

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

ответил MSalters 11 PMpMon, 11 Apr 2016 12:12:42 +030012Monday 2016, 12:12:42
4

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

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

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

ответил Cort Ammon 12 AMpTue, 12 Apr 2016 06:21:16 +030021Tuesday 2016, 06:21:16
3

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

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

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

ответил David Hammen 11 PMpMon, 11 Apr 2016 18:38:56 +030038Monday 2016, 18:38:56
2

Сложность:

В центральном репозитории типичный рабочий поток может быть

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).

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

ответил Theodore Norvell 13 PMpWed, 13 Apr 2016 20:17:09 +030017Wednesday 2016, 20:17:09
1

Простой:

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

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

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

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

ответил Agent_L 14 PMpThu, 14 Apr 2016 17:56:57 +030056Thursday 2016, 17:56:57
-2

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

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

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

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

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

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

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

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

ответил Ian 12 PMpTue, 12 Apr 2016 12:03:54 +030003Tuesday 2016, 12:03:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132