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

289

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

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

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

Мои вопросы:

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

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

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

gardenhead
источник
31
Я чувствую точно так же и не понимаю этого.
Снуп
57
Лично я просто не знаю ни одного варианта использования для нескольких пультов, кроме вилок для создания PR на главном пульте. Распределенная вещь все еще полезна, потому что это означает, что я получаю полную историю на моей машине без необходимости общаться с сетью, и я могу выполнять некоторую работу в автономном режиме, если я действительно этого хочу, и намного проще перейти с одного хоста онлайн-репо на еще один. Что именно вы имеете в виду, когда ссылаетесь на «распределенный рабочий процесс»?
Ixrec
43
Я вполне уверен, что Торвальдс с самого начала намеревался иметь один «источник правды» репозиторий ядра Linux.
Стивен Бернап,
67
В конечном счете, само программное обеспечение является централизованным. Клиенты не покупают филиалы или пульты, они покупают готовый, собранный продукт. Всегда должен быть какой-то центральный путь вперед.
Брэндон
37
Для меня «децентрализованность» в git - это одна из наименее важных функций, которые его рекомендуют. Возможность делать частые коммиты и откаты локально, не влияя ни на кого, или мощные методы, такие как перебазирование, - вот где git действительно сияет в моем рабочем процессе. Возможно (действительно вероятно), что все это стало возможным благодаря децентрализации, но буква «D» в DVCS сама по себе не так важна для меня.
Джей

Ответы:

257

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

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

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

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

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

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

Майкл Хэмптон
источник
15
Слияния SVN также влияют только на разработчиков, связанных с конфликтующими изменениями. Один коммит попадает в репозиторий, никакое конфликтующее слияние не может войти в репо, пока конфликты не будут разрешены (вы также можете зафиксировать параллель с отдельной веткой / путем, но это на самом деле не конфликтует, не так ли?)
Бен Фойгт
30
Я считаю, что основное различие, когда существует центральный сервер, состоит в том, что GIT позволяет осуществлять текущее локальное управление версиями, когда сеть не работает, а SVN - нет (некоторые другие системы контроля версий еще хуже и останавливают всю работу, когда сеть недоступна). потому что они не позволяют вам изменить файл, пока вы не проверите его).
Бен Фойгт
17
@BenVoigt О, это работа останавливается все в порядке. Помните, что вы должны svn upбыть в курсе репо, прежде чем сможете регистрироваться. Когда другие продолжают регистрироваться, пока вы пытаетесь разрешить конфликты слияния, и даете вам еще один набор конфликтов слияния ... вы либо прекращаете это или вы потеряете то, что осталось от вашего здравомыслия.
Майкл Хэмптон
21
Нет, люди могут продолжать вносить изменения в ветку, из которой вы вносите изменения, не прерывая рабочий процесс.
Бен Фойгт
29
Бен прав. Репозиторий SVN управляется должным образом и используется командой, которая была должным образом обучена тому, как разрабатывать программное обеспечение, и в действительности никогда не должно иметь конфликтов слияния на соединительной линии. Вы получите их только тогда, когда кто-то сделал что-то не так и должен быть уволен (: P). inb4 легче, когда вам не нужно учить людей, как использовать их инструменты. Да, ну, о Git можно многому научить больше, чем о SVN!
Гонки легкости на орбите
118

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

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

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

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


источник
2
В целом хороший ответ, но я уверен, что Git широко использовался до Continuous Integration; Кстати, наша команда использует CI, спасибо за проверку: D.
садовник
5
@gardenhead: вы упустили суть: тот же аргумент верен, если интегрирование выполняется вручную. «CI» - это просто автоматизация процесса, который намного старше, чем Git.
Док Браун
25
«любой может увидеть мой предварительный код» - и они также могут извлечь ваш предварительный код, объединить его с предварительным кодом и запустить тесты. Это боль в централизованных VCS, так как для этого требуются ветви и изменения в One True Copy. Распределенный, вы просто настраиваете дополнительные пульты, затем начинаете слияние, исправление и сбор вишни. У вас есть отслеживание того, что вы сделали, но никто больше не должен видеть, какие у вас махинации, если вы не решите их опубликовать. В общем, я рекомендую никому не объявлять DVCS бессмысленным, пока они на самом деле не используют SVN для большого проекта ...
Стив Джессоп
9
Потому что не существует «единой верной сборки» ядра Linux. Поскольку все строят его самостоятельно, репо Линуса не более канонично, чем у кого-либо еще. Если вы продаете продукт, который не работает так хорошо.
Майлз Буднек
2
@Superbest: большая часть (если не все) дизайна git была основана на Bitkeeper. Git был создан после того, как разгорелся спор о linux-bitkeeper.
whatsisname
40

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

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

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

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

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

Стив Джессоп
источник
7
Они технически эквивалентны, а не социально эквивалентны.
curiousdannii
3
Отправка патчей по электронной почте довольно безболезненно, на всякий случай, если кто-то подумает об этом, просто используйте git format-patch и затем git send-email . Сделал это, когда я не хотел возиться с контролем доступа Github, и это было очень просто, у всех есть электронная почта в конце концов.
Рудольф Олах
1
«обязательно должен иметь полную историю [...] локально, чтобы что-то делать» - неправда; современные DSCM поддерживают частичное репо («мелкие кассы» в терминах bzr, «мелкие клоны» в терминах git).
Чарльз Даффи
27

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

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

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

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

Карл Билефельдт
источник
1
Вопрос о том, насколько сложно создать ветку в традиционной CVCS, полностью зависит от политики: мне довелось работать с репозиторием SVN восходящего направления (естественно, через клон git-svn!), И я имею полное право создавать любые ветки, которые я использую. хочу, хотя это довольно большой проект. Мне просто не разрешено трогать несколько назначенных веток интеграции, не говоря уже о магистрали, не поговорив сначала с начальством. Другие компании могут иметь другие политики, которые могут быть более строгими, но они, безусловно, не должны быть.
cmaster
7
Ты прав, я не знаю, как легко у меня это получается. Хотелось бы мне быть во времена господства SVN, чтобы оценить, как далеко мы продвинулись. Как очень молодой разработчик программного обеспечения, я нахожу этот шаблон довольно часто повторяющимся: более опытные разработчики говорят мне, что старый способ сделать что-то был плохим, а этот новый способ / технология намного проще. Но я просто должен поверить им на слово; Я никогда не смогу по-настоящему оценить преимущества. Мне всегда было трудно преодолеть этот диссонанс.
садовник
1
@gardenhead, вы всегда можете создать свой собственный репозиторий SVN и попытаться сломать его;) (и заметить, насколько это сложнее, чем создать репозиторий git и клонировать его ...) - Еще одна важная особенность, которую я заметил (по крайней мере, в особенно в корпоративной среде), так как совместное использование файлов немного неудобно или выполняется таким образом, что создает хранилища (например, потому что антивирусный сканер блокирует сетевой диск).
Уэйн Вернер
4
@gardenhead: ну, считайте, что вам повезло, что вы не застряли в унаследованном проекте, со старыми разработчиками программного обеспечения, которые говорят вам, что старый способ делать что-то просто замечательно ... иногда вы не можете не чувствовать, что они просто Рад, что им не нужно изучать новые технологии!
оставил около
1
@gardenhead, очевидно, проекты выпускаются с довольно безумной скоростью. Способность продолжать обучение необходима, если вы хотите найти отличную работу.
Уэйн Вернер
19

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

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

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

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


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

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

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

Tersosauros
источник
3
Я являюсь членом клуба Mile High (Software) - я написал код на 35 000 футов. Конечно, у самолетов сейчас есть Wi-Fi , но это было не всегда так. И приятно знать, что, по крайней мере, если мы потерпим крах, есть вероятность, что моя команда исправит мой код.
Уэйн Вернер
@WayneWerner это правда. Я думал о создании более общих ситуаций, в которых невозможно (почти) всегда быть на связи. Например, на самолете, в лодке в море, на космической станции, в отдаленных местах в Африке и т. Д.
Tersosauros
18

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

Брайан Оукли
источник
14

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

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

пушистый
источник
4
Это правильный ответ, также с исторической точки зрения. Ядро Linux долгое время имело несколько исходных репозиториев (называемых разработчиками «деревьями», такими как «дерево Линуса» или «дерево Эндрю»). Linux хотел что-то, чтобы поддерживать этот тип распределенной разработки, когда он разрабатывал git.
Слеське
@Luaan Подумав немного, я понял, что ты прав. Я немного изменил формулировку - это лучше отражает разницу?
пушистый
@ fluffy Звучит хорошо для меня;)
Luaan
9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

попробуй поймать, наконец,
источник
Разве SVN не выиграл svn initв какой-то момент?
immibis
5

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

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

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

MSalters
источник
1
Я согласен, что гибкость Git должна быть снижена для большинства случаев использования. На моей последней работе у нас не было рекомендаций по использованию git, и из-за этого были постоянные конфликты и поломки. В моей новой компании мы используем модель Git Flow, и это делает разработку намного более упорядоченной и свободной от стресса.
садовник
1
Это не «теоретическая гибкость», позволяющая не деревья. Ограничьте себя только деревьями, и вы никогда не сможете объединить свои изменения, что сделает вашу VCS несколько бессмысленной.
Wildcard
2
@Wildcard: Слияние вообще не проблема с деревьями, с чего бы это случилось? Конечно, вы не можете объединяться между случайными узлами, просто между родителем / ребенком.
MSalters
1
Я не был достаточно ясен, очевидно. Я имел в виду дерево коммитов, а не дерево файловой системы. По определению, коммит слияния имеет более одного родителя, и поэтому ваш график истории больше не является деревом, а вместо этого является DAG.
Wildcard
2
@Wildcard: MSalters сказал, что репозитории обычно связаны как деревья, а не коммиты. Он говорит, что у репозиториев обычно есть только один «восходящий» пульт, на который они отправляют (или выдают запросы на извлечение). У меня нет никаких статистических данных о том, правда это или нет, но это совершенно отдельное утверждение о том, сколько родителей имеет коммит слияния.
Стив Джессоп
4

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

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

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

Корт Аммон
источник
3

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

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

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

Дэвид Хаммен
источник
«Я очень осторожен с демонами, работающими на моем собственном компьютере или на ноутбуке, предоставленном моей компанией». - потому что помимо всего прочего запуск службы на моем ноутбуке означает, что служба недоступна, когда я закрываю крышку! DynDNS может помочь с несколькими местоположениями (в некоторой степени, вы все еще можете быть пойманы в ловушку за NAT), но это не помогает с отключением питания вашей сетевой карты ...
Steve Jessop
Существует множество способов сделать видимым git-репо без запуска какого-либо специального демона; доступ к нему можно получить практически через любой общий файловый ресурс (smb, sshfs и т. д.), а также сделать его доступным как обычное HTTP-хранилище.
пушистый
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).

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

Теодор Норвелл
источник
Если вы собираетесь голосовать против, не могли бы вы оставить комментарий, почему?
Теодор Норвелл,
Не то чтобы я возражал против отрицательных голосов. Я просто хочу знать, если ответ каким-то образом неправильный.
Теодор Норвелл
1

Просто:

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

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

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

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

Agent_L
источник
-2

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

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

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

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

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

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

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

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

Ян
источник