GIT против Perforce - Два VCS войдут… один уйдет [закрыто]

Итак, я нахожусь в процессе продажи GIT на работе. Первое, что мне нужно, это убедить всех, что GIT лучше выполняет то, к чему они уже привыкли. В настоящее время мы используем Perforce. Кто-нибудь еще проходил подобную распродажу? Есть хорошие ссылки / советы?

Одним из больших преимуществ является то, что мы можем работать с ним без подключения к сети. Еще одна победа IMO - это способ обработки добавления / оформления заказа. Приветствуются дополнительные баллы! Также у нас около 10-20 разработчиков.

Исходный код интерпретатора Perl 5 в настоящее время переживает муки преобразования из Perforce в git. Может быть, git-p4rawинтересует импортер Сэма Вилейна .

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

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

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

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

Я использую Perforce на работе. Я также использую Git, потому что мне все равно нужна какая-то форма контроля версий, когда я работаю над кодом и не могу подключиться к серверу. Нет, согласовать оффлайн работу просто не одно и то же. Вот где я считаю git большим преимуществом:

1. Скорость ветвления - git занимает максимум несколько секунд.
2. Конфликты - автоматическое разрешение P4Merge однажды уничтожило недельный объем работы. С тех пор я предпочел бы решать вручную при слиянии. Когда Git сообщает мне о конфликте, на самом деле это конфликт. В остальное время git решает все правильно, и я экономлю кучу времени.
3. Отслеживание слияний - если у вас есть одна ветка, которая постоянно получает слияния из двух других веток, вы знаете, что это может быть головной болью, если это необходимо. С помощью git головная боль сводится к минимуму, потому что результатом слияния в git на самом деле является новый коммит, который знает, кто его предки.
4. Разрешения - я не помню, сколько раз я пытался работать с файлом, но не мог, потому что он не был получен в Perforce. Если вы работали с XCode (или любым редактором, не имеющим надежного плагина Perforce SCM) в автономном режиме, вы знаете, насколько это может раздражать. С Git мне не нужно об этом беспокоиться. Вношу свои изменения. Git меня не останавливает и отслеживает их в фоновом режиме.
5. Поддержание порядка в основном дереве - с помощью git я могу сортировать свои коммиты и приводить в порядок код, чтобы история выглядела аккуратно и аккуратно. Ничего из этого мусора "проверка этого файла, потому что он должен был быть частью предыдущей проверки". Я сквошу такие коммиты, потому что они никому не помогают.
6. Хранение - ваш perforce сервер должен быть версии 2010.1 или новее, чтобы использовать команду p4 shelve.
7. Создание патчей - легко сделать в git. Не знаю, возможно ли это в Perforce без использования командной строки.
8. Рассылка патчей из графического интерфейса - опять же, здесь выигрывает git.
9. Дисковое пространство - по желанию каждая ветвь является копией. Это означает, что если ваше исходное дерево огромно, ваше дисковое пространство быстро израсходуется. Это даже не считая дополнительного места после начала строительства. Зачем вообще есть связь между ветками и дисковым пространством? С git у вас может быть 100 веток, и одновременно существует только одна ветка. Если вы конкретно хотите работать над двумя версиями одновременно, вы можете клонировать, выполнять свою работу, а затем, если хотите, избавиться от одного клона, ничего не теряя.
10. Если вы используете XCode4, поддержка perforce была прекращена, а поддержка git теперь встроена. Если вы делаете кроссплатформенную работу, как я, это имеет большое значение. В Visual Studio вы можете использовать расширения git. С perforce это одинаково мерзко на обеих ОС. Ну, может быть, теперь немного больше о Mac с XCode4 на сцене.
11. Обнаружение ошибочной регистрации (или правил git bisect) - Вы когда-нибудь пытались выполнить бинарный поиск, чтобы выяснить, где была обнаружена ошибка? Довольно хлопотно, да? Еще больше хлопот, когда в середине были интеграции из других веток. Зачем? Потому что автоматики для таких задач нет. Вам нужно написать свой собственный инструмент, чтобы разговаривать с ним по необходимости, а у вас обычно нет времени. С помощью git вы задаете ему отправные точки («хороший» и «плохой»), и он автоматизирует поиск для вас. Еще лучше, если у вас есть сценарий, который может автоматизировать процесс сборки и тестирования, вы можете подключить git к сценарию, и весь процесс поиска отметки будет автоматизирован. Так должно быть.
12. Отслеживание изменений в рефакторах - попробуйте разделить BigClass на SmallClass1 и SmallClass2. Для Perforce BigClass прекратил свое существование, и к дереву исходных текстов присоединились два новых класса (SmallClass1 и SmallClass2). Для Perforce нет никакой связи между BigClass, SmallClass1 и SmallClass2. Git, с другой стороны, достаточно умен, чтобы знать, что x% BigClass теперь находится в SmallClass1, а y% BigClass находится в SmallClass2, и что BigClass прекратил свое существование. Теперь, с точки зрения того, кто просматривает изменения в нескольких ветках, вы говорите мне, какой подход вы найдете более полезным - Git или Perforce. Лично я предпочитаю подход Git, потому что он более точно отражает фактическое изменение кода. Git может это сделать, потому что он отслеживает содержимое внутри файла, а не сам файл.
13. Централизованный или децентрализованный: Git - это система DVCS , а perforce - централизованная. Централизованная VCS не может быть децентрализована позже, но DVCS (особенно git) может быть централизованной. Есть несколько продуктов, которые добавляют в git очень детальный контроль доступа, если это то, что нужно бизнесу. Лично я бы выбрал систему, которая дает мне большую гибкость в долгосрочной перспективе.
14. Сопоставления ветвей: если вы хотите выполнять ветвление прямо в Perforce, вам необходимо создать сопоставление ветвей. Для этого есть причины, но они связаны с тем, как Perforce концептуализирует ветвь. Для разработчика или команды это просто означает еще один шаг в рабочем процессе, который я вообще не считаю эффективным.
15. Распределение работы между командами: с Perforce вы не можете разделить заявку. Команда A работает над функцией A. Команда B над функцией B. Команда C работает над исправлением ошибок. Теперь командам A и B необходимо исправить кучу ошибок, чтобы реализовать свои функции. Единственное, они не были так дисциплинированы при фиксации своих изменений (вероятно, потому, что они спешат к крайнему сроку), и поэтому их «исправления ошибок» являются частями более крупных отправок, которые также содержат новые вещи в том, что касается контроля версий на их отрасли обеспокоены. Тем не менее, команда C сейчас делает точечный выпуск и хотела бы получить исправления ошибок от других команд. Если бы они использовали Git, команда C могла бы выбрать соответствующие изменения других команд, разделить их и взять только то, что им нужно, не беспокоясь о введении каких-либо частично реализованных функций. С Perforce,
16. Смена платформы. Если по какой-либо причине в будущем вы решите сменить выбранную платформу с помощью Perforce, вы будете зависеть от Perforce.com и доступности инструментов для платформы по вашему выбору.
17. Переход к будущему удивительному механизму управления версиями X.Если вы решите изменить то, что вы используете для управления версиями, извлечение истории управления исходным кодом из Perforce и перенос ее в новую систему X станет кошмаром, потому что это закрытый исходный код и лучший вы можете просто догадаться - просто переходите с Google для Perforce на Git, чтобы понять, о чем я говорю. По крайней мере, с Git, его открытым исходным кодом, поэтому он избавляет от многих догадок.

Ну это мои 2 цента. В защиту Perforce я должен сказать, что их правила поддержки клиентов, а также их инструмент Time Lapse View. Я не знаю, как получить покадровый просмотр с помощью git. Но для удобства и экономии времени я бы выбрал git в любой день.

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

Сколько разработчиков вы говорите о смене?

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

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

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

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

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

Команда, которая продала меня лично на git, была разделена пополам . Я не думаю, что на данный момент эта функция доступна в какой-либо другой системе контроля версий.

При этом, если люди привыкли к GUI-клиенту для управления версиями, они не будут впечатлены git. На данный момент единственным полнофункциональным клиентом является командная строка.

Какие функции Perforce используют люди?

• Несколько рабочих мест на одной машине
• Пронумерованные списки изменений
• Ветки разработчиков
• Интеграция с IDE (Visual Studio, Eclipse, SlickEdit, ...)
• Множество вариантов сборки
• Составные рабочие пространства
• Интеграция одних исправлений, но не других
• так далее

Я спрашиваю, потому что, если все люди делают это из командной строки, git покрывает это, как и все остальные RTS.

Судя по всему, GitHub теперь предлагает компаниям учебные курсы по git . Процитировал об этом сообщение в блоге :

За последние несколько недель я несколько раз бывал в кампусе Google, помогая обучать андроидов работе с Git. Шон Пирс (вы, возможно, знаете его по славе Git и EGit / JGit - он герой, который берет на себя обслуживание, когда Джунио уезжает из города) попросил меня помочь ему обучить инженеров Google, работающих над Andriod, переходу от Perforce к Git , чтобы Android можно было делить с массами. Могу сказать, что был более чем счастлив сделать это.

[…]

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

Акцент мой.

Я давно использую Perforce, а недавно начал использовать и GIT. Вот мое «объективное» мнение:

Возможности Perforce:

1. Инструменты графического интерфейса кажутся более многофункциональными (например, покадровый просмотр, график изменений)
2. Скорость при синхронизации с головной ревизией (без накладных расходов на перенос всей истории)
3. Интеграция Eclipse / Visual Studio действительно хороша
4. Вы можете разработать несколько функций в одной ветке для каждого Changelist (я все еще не уверен на 100%, является ли это преимуществом перед GIT)
5. Вы можете «следить» за тем, что делают другие разработчики - какие файлы они извлекли.

Возможности GIT:

1. У меня сложилось впечатление, что командная строка GIT намного проще, чем Perforce (инициализация / клонирование, добавление, фиксация. Никакой настройки сложных рабочих пространств)
2. Скорость доступа к истории проекта после оформления заказа (достигается за счет копирования всей истории при синхронизации)
3. Автономный режим (разработчики не будут жаловаться, что недоступный сервер P4 запретит им кодирование)
4. Создание новых веток происходит намного быстрее
5. «Основному» серверу GIT не требуется много ТБ хранилища, потому что у каждого разработчика может быть своя собственная локальная песочница.
6. GIT - это OpenSource - без лицензионных сборов
7. Если ваша компания также участвует в проектах OpenSource, то делиться патчами с GIT намного проще.

В целом для проектов OpenSource / Distributed я всегда рекомендую GIT, потому что это больше похоже на приложение P2P, и каждый может участвовать в разработке. Например, я помню, что когда я занимался удаленной разработкой с помощью Perforce, я синхронизировал проекты размером 4 ГБ по каналу 1 Мбит / с один раз в неделю. Из-за этого было просто потрачено много времени. Также для этого нам нужно было настроить VPN.

Если у вас небольшая компания и сервер P4 всегда будет работать, я бы сказал, что Perforce - тоже очень хороший вариант.

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

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

Как, например, в этом блоге сотрудника компании по разработке видеоигр: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

Однако важно то, что разница в скорости между git и perforce, когда у вас есть огромный репозиторий на 6 ГБ, содержащий все, от документации до каждого когда-либо созданного двоичного файла (и, наконец, о да! Фактическая история исходного кода), обычно исходит из Дело в том, что огромные компании, как правило, используют Perforce, и поэтому они настроили его так, чтобы переложить все важные операции на огромный серверный банк в подвале.

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

В любом случае, Perforce и git - это разные продукты. Git был разработан исключительно как VCS, и он делает это намного лучше, чем Perforce (в том смысле, что он имеет больше функций, которые, как правило, проще использовать, в частности, по словам другого, ветвление в Perforce похоже на выполнение открытого сердца). операция, это должны делать только специалисты: P) ( http://stevehanov.ca/blog/index.php?id=50 )

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

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

Я думаю, что единственное, в чем я знаю, что GIT выигрывает, - это его способность «сохранять окончания строк» ​​во всех файлах, в то время как в силу воли, кажется, настаивает на их переводе в формат Unix, Dos / Windows или MacOS9 ("\ n", "\ r \ n "или" \ r).

Это настоящая боль, если вы пишете сценарии Unix в среде Windows или смешанной среде ОС. Невозможно даже установить правило для каждого расширения файла. Например, он преобразует файлы .sh, .bash, .unix в формат Unix и конвертирует файлы .ccp, .bat или .com в формат Dos / Windows.

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

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

«Решение», к которому мы пришли на данный момент, - это запускать команду sed для удаления всех символов возврата каретки из сценариев каждый раз, когда они развертываются в среде Unix. Это тоже не идеально, особенно с учетом того, что некоторые из них развернуты внутри файлов WAR, и строку sed нужно запускать снова, когда они распаковываются.

Я думаю, что это дает GIT большое преимущество, и я не думаю, что это было упомянуто выше.

РЕДАКТИРОВАТЬ: после использования Perforce немного дольше, я хотел бы добавить еще пару комментариев:

A) В Perforce мне очень не хватает четкого различия экземпляров, включая измененные, удаленные и добавленные файлы. Это доступно в GIT с помощью git diffкоманды, но в Perforce файлы должны быть извлечены до того, как их изменения будут записаны, и хотя у вас могут быть настроены ваши основные редакторы (например, Eclipse) для автоматической проверки файлов при их редактировании, вы может иногда редактировать файлы другими способами (блокнотом, командами unix и т. д.). И кажется, что новые файлы вообще не добавляются автоматически, даже при использовании Eclipse и p4eclipse, что может сильно раздражать. Итак, чтобы найти все изменения, вы должны запустить «Различия против ...» во всей рабочей области, что, во-первых, требует времени для запуска, а во-вторых, включает все виды нерелевантных вещей, если вы не настроили очень сложные списки исключений, что подводит меня к следующему пункту.

Б) В GIT я нахожу .gitignore очень простым и легким в управлении, чтении и понимании. Однако списки игнорирования / исключения рабочей области, настраиваемые в Perforce, кажутся громоздкими и излишне сложными. Мне не удалось получить никаких исключений с работающими подстановочными знаками. Я бы хотел сделать что-то вроде

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

Чтобы исключить все целевые папки из всех проектов внутри Server / mainline. Однако, похоже, это не работает так, как я ожидал, и в итоге я добавил строку для каждого проекта, например:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

И аналогичные строки для папок bin, файлов .classpath и .projet и т. Д.

C) В Perforce есть довольно полезные списки изменений. Однако предположим, что я вношу группу изменений, проверяю их все и помещаю в список изменений, чтобы затем поработать над чем-то еще перед отправкой этого списка. Если позже я внесу изменения в один из файлов, включенных в первый список изменений, этот файл все равно будет в этом списке изменений, и я не могу позже отправить список изменений, предполагая, что он содержит только те изменения, которые я изначально добавил (хотя он будут такие же файлы). В GIT, если вы добавите файл, и они внесут в него дальнейшие изменения, эти изменения не будут добавлены (и все равно будут отображаться вgit diffи вы не сможете зафиксировать файл, не добавив сначала новые изменения. Конечно, это не так полезно, как список изменений, поскольку у вас есть только один набор добавленных файлов, но в GIT вы можете просто зафиксировать изменения, так как это на самом деле их не подталкивает. Вы можете поработать над другими изменениями перед их продвижением, но вы не сможете продвигать что-либо еще, что добавите позже, без внесения предыдущих изменений.

У меня нет опыта работы с Git, но у меня есть Mercurial, который также является распределенной VCS. На самом деле это зависит от проекта, но в нашем случае распределенная VCS подходит для проекта, поскольку в основном устраняет частые поломки сборки.

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

Вот что мне не нравится в git:

Прежде всего, я считаю, что распространенная идея противоречит реальности. Все, кто на самом деле использует git, делают это централизованно, даже Линус Торвальдс. Если бы ядро ​​управлялось распределенным образом, это означало бы, что я не мог фактически загрузить "официальные" исходные коды ядра - их не было бы - мне пришлось бы решать, хочу ли я версию Линуса или версию Джо, или версия Билла. Это, очевидно, было бы нелепо, и поэтому существует официальное определение, которое Линус контролирует с помощью централизованного рабочего процесса.

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

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

Git активно поощряет людей переписывать историю, и это, вероятно, одна из причин этого. Каждый нормальный VCS делает переписывание истории невозможным для всех, кроме администраторов, и гарантирует, что у админов нет причин рассматривать это. Поправьте меня, если я ошибаюсь, но, насколько я знаю, git не дает возможности предоставить обычным пользователям доступ на запись, но запрещает им переписывать историю. Это означает, что любой разработчик с недовольством (или все еще испытывающий трудности с кривой обучения) может выбросить всю кодовую базу на мусор. Как нам это затянуть? Что ж, либо вы делаете регулярные резервные копии всей истории, то есть сохраняете ее в квадрате, либо вы запрещаете доступ на запись всем, кроме какого-то бедняги, который получит все различия по электронной почте и объединит их вручную.

Давайте возьмем пример хорошо финансируемого большого проекта и посмотрим, как git для них работает: Android. Однажды я решил поиграться с самой системой андроид. Я узнал, что должен был использовать кучу скриптов под названием repo, чтобы добраться до их git. Некоторые из репозиториев работают на клиенте, а некоторые на сервере, но и то, и другое самим своим существованием иллюстрирует тот факт, что git неполон в любой из этих возможностей. Случилось так, что я не мог получить исходники около недели, а затем полностью сдался. Мне пришлось бы вытаскивать действительно огромный объем данных из нескольких разных репозиториев, но сервер был полностью перегружен такими людьми, как я. Время репо истекло, и его не удалось возобновить с того места, где он истек. Если git настолько распространен, можно подумать, что они Я сделал что-то вроде одноранговой сети, чтобы уменьшить нагрузку на этот сервер. Git распространяется, но это не сервер. Git + repo - это сервер, но репо не распространяется, потому что это просто специальная коллекция хаков.

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

Даже если бы вы действительно верили в распределенную вещь, git все равно был бы беспорядком. Что, например, такое ветка? Они говорят, что вы неявно создаете ветвь каждый раз, когда клонируете репозиторий, но это не может быть то же самое, что ветка в одном репозитории. Так что это как минимум две разные вещи, называемые ветвями. Но тогда вы также можете перемотать репо и просто начать редактирование. Это похоже на второй тип ветки или опять что-то другое? Может быть, это зависит от того, какой тип репо у вас есть - о да - очевидно, репо тоже не очень ясная концепция. Есть нормальные и голые. Вы не можете перейти к обычному, потому что голая часть может не синхронизироваться с исходным деревом. Но вы не можете cvsimport на голый, потому что они не думали об этом. Так что вам нужно cvsimport на нормальный, клонируйте это в голую копию, которую ударили разработчики, и cvsexport это в рабочую копию cvs, которую еще нужно зарегистрировать в cvs. Кого можно беспокоить? Откуда все эти сложности? Из самой распространенной идеи. В конце концов, я отказался от гитолита, потому что он накладывал на меня еще больше ограничений.

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

По желанию вам редко нужны ветки, потому что вы можете очень быстро манипулировать наборами изменений. Например, обычный рабочий процесс заключается в том, что вы синхронизируете с последней удачной версией в основной сети, а затем пишете свою функцию. Всякий раз, когда вы пытаетесь изменить файл, разница этого файла добавляется в ваш «набор изменений по умолчанию». Когда вы пытаетесь проверить набор изменений, он автоматически пытается объединить новости из основной ветки с вашим набором изменений (фактически перебазируя его), а затем фиксируется. Этот рабочий процесс осуществляется принудительно, вам даже не нужно его понимать. Таким образом, Mainline собирает историю изменений, которую вы можете легко исправить позже. Например, предположим, что вы хотите восстановить старую, скажем, предшествующую предпоследней. Вы выполняете синхронизацию с моментом перед нарушением изменений, помечаете затронутые файлы как часть набора изменений, синхронизировать с моментом после и объединиться с «всегда моим». (Там было кое-что очень интересное: синхронизация не означает наличия того же самого - если файл доступен для редактирования (то есть в активном наборе изменений), он не будет затираться синхронизацией, но будет помечен как подлежащий разрешению.) Теперь у вас есть список изменений, который отменяет нарушение. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю. Слияние с последующими новостями, и у вас есть список изменений, который вы можете поместить поверх основной линии, чтобы добиться желаемого эффекта. Мы ни разу не переписали историю.

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

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

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

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

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

Использование GIT в качестве замены плохого управления строкой кода является обычным явлением. Многие недостатки Perforce являются результатом плохих стратегий ветвления. То же самое и с любым другим централизованным инструментом. Если вам нужно создать множество веток, вы делаете что-то не так. Зачем разработчикам создавать столько веток?

Кроме того, почему в любом случае так важно работать без подключения к сети? Просто чтобы кто-то мог работать в поезде? Это почти единственное место, где в наши дни нет беспроводного подключения. И даже в большинстве поездов есть приличный Wi-Fi.