Итак, я нахожусь в процессе продажи GIT на работе. Прежде всего мне нужно убедить всех, что GIT лучше того, что они уже привыкли делать. В настоящее время мы используем Perforce. Кто-нибудь еще проходит аналогичную продажу? Любые хорошие ссылки/советы?
Одним из больших выигрышей является то, что мы можем работать с ним, отключенным от сети. Другой выигрыш IMO - это способ добавления/проверки. Больше очков приветствуется! Также у нас около 10-20 делений.
Исходный код интерпретатора Perl 5 в настоящее время проходит через процесс преобразования из Perforce в git. Возможно, интерес представляет импортер Sam Vilains git-p4raw.
В любом случае, одна из главных побед, которую вы будете иметь над всеми централизованными VCS и наиболее распространенными, также является сырой, волнистой скоростью. Вы не можете себе представить, как освободить его, чтобы иметь всю историю проекта под рукой, всего лишь доли доли секунды, пока вы не испытали это. Даже генерация журнала фиксации всей истории проекта, которая включает полный diff для каждой фиксации, может измеряться в доли секунды. Git настолько быстро, что ваша шляпа улетит. VCS, которые должны совершать кругооборот по сети, просто не имеют возможности конкурировать, даже не по каналу Gigabit Ethernet.
Кроме того, Git позволяет очень осторожно выбирать при совершении коммитов, тем самым позволяя изменять вашу рабочую копию (или даже в пределах одного файла) на несколько коммитов - и через разные ветки, если вам нужно что. Это позволяет вам делать меньше умственных заметок во время работы - вам не нужно тщательно планировать свою работу, решив перед собой, какой набор изменений вы совершаете, и отложите что-нибудь еще. Вы можете просто внести любые изменения, которые вам нужны по мере их возникновения, и все равно распутать их - почти всегда довольно легко - когда пришло время совершить. Закладка может быть очень большой помощью здесь.
Я обнаружил, что вместе эти факты заставляют меня, естественно, сделать гораздо больше и гораздо более целенаправленные, чем раньше, чем я использовал git. Это, в свою очередь, не только делает вашу историю более полезной, но особенно полезно для инструментов с добавленной стоимостью, таких как git bisect.
Я уверен, что сейчас есть больше вещей, о которых я не думаю. Одна из проблем с предложением продажи вашей команды на Git заключается в том, что многие преимущества взаимосвязаны и играют друг с другом, как я намекал выше, так что трудно просто взглянуть на список функций и преимуществ Git и вывести, как они собираются изменить ваш рабочий процесс, и какие изменения будут улучшены. Вы должны принять это во внимание, и вам также необходимо явно указать на это.
Я использую Perforce на работе. Я также использую Git, потому что мне все равно нравится какая-то форма контроля версий, когда я работаю над кодом и не могу подключиться к серверу. Нет, реконфигурировать автономную работу просто не то же самое. Вот где я нашел Git большую пользу:
Хорошо, что мои 2 цента. В защите Perforce я должен сказать, что их правила поддержки клиентов, а также их инструмент Time Lapse View. Я не знаю, как получить временный просмотр с помощью Git. Но для удобства и времени, сохраненных, я бы пошел с Git в любой день.
Мне потребовалось бы много убеждений, чтобы переключиться с любой силы. В двух компаниях, которые я использовал, это было более чем достаточно. Это были обе компании с разрозненными офисами, но офисы были созданы с большим количеством инфраструктуры, поэтому не было необходимости иметь несвязанные/отключенные функции.
Сколько разработчиков вы говорите об изменении?
Реальный вопрос: что это такое, что не соответствует потребностям вашей организации, которую может предоставить git? И аналогичным образом, какие недостатки git по сравнению с perforce? Если вы не можете ответить на этот вопрос, то просьба здесь не поможет. Вам нужно найти бизнес-кейс для вашей компании. (например, возможно, это связано с более низкой общей стоимостью владения (включая потерю производительности для промежуточной стадии обучения, более высокие затраты на администрирование (по крайней мере, на начальном этапе) и т.д.).
Я думаю, что вы находитесь в жесткой сделке с продажей - это довольно хорошая попытка заменить. Это не проблема, если вы пытаетесь загрузить pvcs или ssafe.
Я думаю, что с точки зрения того, чтобы люди были счастливы во время/после переезда, одна из вещей, которые нужно встретить на ранней стадии, - это то, насколько частная локальная ветка может быть в Git, и насколько свобода дает им ошибки. Получить их всех, чтобы клонировать себя несколько частных ветвей из текущего кода, а затем отправиться в дикую природу, экспериментируя. Переименуйте некоторые файлы, проверьте содержимое, слейте вещи из другой ветки, перемотайте историю, замените один набор изменений поверх другого и так далее. Покажите, как даже их худшие аварии на местном уровне не имеют последствий для их коллег. То, что вам нужно, - это ситуация, когда разработчики чувствуют себя в безопасности, поэтому они могут учиться быстрее (поскольку Git имеет крутую кривую обучения, которая важна), а затем в конечном итоге, чтобы они были более эффективными в качестве разработчиков.
Когда вы пытаетесь изучить централизованный инструмент, очевидно, что вас беспокоит проблема с некоторыми проблемами, которые создают проблемы для других пользователей репозитория. Одного страха перед смущением достаточно, чтобы помешать людям экспериментировать. Даже наличие специального учебного репозитория не помогает, потому что неизбежно разработчики столкнутся с ситуацией в производственной системе, которую они никогда не видели во время обучения, и поэтому они снова беспокоятся.
Но Git распределенная природа справляется с этим. Вы можете попробовать любой эксперимент в локальной ветке, и если он идет ужасно неправильно, просто отбросьте ветку, и никто не должен знать. Поскольку вы можете создать локальную ветвь чего-либо, вы можете реплицировать проблему, которую вы видите с помощью реального живого репозитория, но не имеете опасности "взломать сборку" или иначе сделать себя дураком. Вы можете проверить абсолютно все, как только вы это сделаете, не пытаясь начать работу в аккуратные небольшие пакеты. Таким образом, не только два основных изменения кода, которые вы потратили сегодня на четыре часа, но также и исправление сборки, которое вы помнили на полпути, и ошибка орфографии в документации, которую вы заметили, объясняя что-то коллеге и т.д. И если основные изменения будут отменены, потому что проект меняет направление, вы можете вишневым выбрать исправление сборки и орфографическую ошибку из своей ветки и сохранить их без хлопот.
Команда, которая продала меня на git лично, была bisect. Я не думаю, что эта функция доступна в любой другой системе управления версиями.
При этом, если люди привыкли к GUI-клиенту для контроля источника, они не будут впечатлены git. Сейчас единственным полнофункциональным клиентом является командная строка.
Какие функции Perforce используются людьми?
Я спрашиваю, потому что, если все люди делают, это get и put из командной строки, git имеет это, и все остальные RTS.
По-видимому GitHub теперь предлагает git учебные курсы для компаний. Quoth их сообщение в блоге об этом:
В последние несколько недель я был в кампусе Google несколько раз, помогая обучать андроидов там в Git. Меня спросил Шон Пирс (вы можете узнать его от его git и славы EGit/JGit - он является героем, который берет на себя заботу, когда Юнио покидает город), чтобы помочь ему обучить инженеров Google, работающих в Andriod в переход от Perforce к Git, поэтому Android можно было бы разделить с массами. Я могу сказать, что я был более чем счастлив сделать это.
[...]
Логическое Awesome теперь официально предлагает этот тип персонализированной службы обучения всем компаниям, где мы можем помочь вашей организации в обучении и планировании, если вы думают также о переключении на git.
Акцент на мой.
Я использую Perforce в течение длительного времени, и недавно я также начал использовать GIT. Вот мое "объективное" мнение:
Функции Perforce:
GIT функции:
В целом для OpenSource/распределенных проектов я всегда рекомендую GIT, потому что это больше похоже на приложение P2P, и все могут участвовать в разработке. Например, я помню, что когда я занимался дистанционной разработкой с Perforce, я один раз в неделю синхронизовал проекты 4GB через канал 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 - это как выполнение открытого -heart, это должны делать только эксперты: P) (http://stevehanov.ca/blog/index.php?id=50)
Любые другие преимущества, которые компании, использующие прирост Perforce, пришли только потому, что Perforce - это не только VCS, но и файловый сервер, а также множество других функций для тестирования производительности сборок и т.д.
Наконец: git является открытым исходным кодом и гораздо более гибким для загрузки, было бы не так сложно запланировать git, чтобы разгрузить важные операции на центральный сервер, запустив кучи дорогостоящего оборудования.
Я думаю, что одна вещь, которую я знаю, GIT выигрывает, это способность "сохранять окончание строк" во всех файлах, тогда как perforce, похоже, настаивает на том, чтобы перевести их в формат 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 большое преимущество, и о котором я не думаю, упоминалось выше.
EDIT: после использования Perforce немного дольше, я хотел бы добавить еще пару комментариев:
A) Что-то, что я действительно пропустил в Perforce, - это четкое различие экземпляров, включая измененные, удаленные и добавленные файлы. Это доступно в GIT с помощью команды git diff, но в Perforce файлы должны быть проверены до того, как их изменения будут записаны, и, хотя у вас могут быть ваши основные редакторы (например, Eclipse), настроенные на автоматическую проверку файлов, когда вы их редактируете, иногда вы можете редактировать файлы другими способами (блокнот, команды unix и т.д.). И новые файлы, кажется, не добавляются автоматически вообще, даже используя Eclipse и p4eclipse, что может быть довольно раздражающим. Поэтому, чтобы найти все изменения, вам нужно запустить "Diff to..." на всей рабочей области, что в первую очередь требует времени для запуска, а во-вторых, включает в себя все виды нерелевантных вещей, если вы не настроите очень сложные списки исключений, что приводит меня к следующему пункту.
B) В GIT я нахожу .gitignore очень простым и простым в управлении, чтении и понимании. Тем не менее, рабочие полосы игнорировать/исключать списки, настраиваемые в Perforce, кажутся громоздкими и излишне сложными. Я не смог получить никаких исключений с помощью подстановочных знаков. Я хотел бы сделать что-то вроде
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Чтобы исключить все целевые папки во всех проектах внутри Сервера/основной линии. Однако, похоже, это не работает, как я ожидал, и я добавил строку для каждого проекта, например:
-//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, делают это централизованно, даже Линус Торвальдс. Если ядро управлялось распределенным способом, это означало бы, что я не мог загрузить "официальные" источники ядра - их не было бы - мне пришлось бы решить, хочу ли я версию Linus или версию Joe, или Билл версии. Это, очевидно, было бы смешно, и поэтому существует официальное определение, которое Linus контролирует, используя централизованный рабочий процесс.
Если вы согласны с тем, что хотите централизованное определение ваших вещей, тогда становится ясно, что роли сервера и клиента совершенно разные, поэтому догма о том, что клиентское и серверное программное обеспечение должна быть одинаковой, становится исключительно ограничивающей. Догма о том, что данные клиента и сервера должны быть одинаковыми, становится явно смешной, особенно в кодовой базе, которая получила пятнадцать лет истории, которой никто не заботится, но все должны были бы клонировать.
То, что мы на самом деле хотим делать со всем этим старым материалом, забивается в шкаф и забывает, что оно там, как и любой обычный VCS. Тот факт, что git перемещает все по сети каждый день, очень опасен, потому что он заставляет вас обрезать его. Эта обрезка включает в себя множество утомительных решений, и это может пойти не так. Таким образом, люди, вероятно, будут хранить целую серию снимков с моментальным снимком из разных точек истории, но разве это не то, для чего исходный контроль был в первую очередь? Эта проблема не существовала, пока кто-то не изобрел распределенную модель.
Git активно побуждает людей переписывать историю, и, возможно, это одна из причин. Каждая нормальная VCS делает историю перезаписи невозможной для всех, кроме администраторов, и гарантирует, что у администраторов нет причин ее рассматривать. Исправьте меня, если я ошибаюсь, но, насколько я знаю, git не предоставляет возможности для обычного доступа пользователей к записи, но запрещает их переписывать историю. Это означает, что любой разработчик с недовольством (или который все еще борется с кривой обучения) может уничтожить всю кодовую базу. Как мы затягиваем это? Ну, либо вы делаете регулярные резервные копии всей истории, т.е. Сохраняете квадрат истории, либо запрещаете доступ на запись ко всем, кроме какого-то плохого дерна, который получит все различия по электронной почте и объединит их вручную.
Возьмем пример хорошо финансируемого крупного проекта и посмотрим, как работает git для них: Android. Однажды я решил сыграть с самой системой андроидов. Я узнал, что я должен использовать кучу скриптов, называемых репо, чтобы получить их git. Некоторые из repo работают на клиенте, а некоторые на сервере, но оба они сами по себе иллюстрируют тот факт, что git является неполным в любой емкости. Случилось так, что я не мог вытащить источники около недели, а потом вообще отказался. Мне пришлось бы вытащить по-настоящему огромное количество данных из нескольких разных репозиториев, но сервер был полностью перегружен такими людьми, как я. Репо был тайм-аут и не смог возобновить работу с того момента, когда он был исчерпан. Если git настолько распространен, вы бы подумали, что они сделали бы что-то одноранговое, чтобы сбросить нагрузку на один сервер. git является распространяемым, но это не сервер. Git + repo - это сервер, но репо не распространяется, потому что это просто специальная коллекция хаков.
Подобной иллюстрацией неадекватности git является гитолит (и его предк, который, по-видимому, не так хорошо работает.) Гитолит описывает свою работу как облегчение развертывания сервера git. Опять же, само существование этой вещи доказывает, что git не сервер, не более, чем клиент. Что еще, этого никогда не будет, потому что, если оно перерастет в это, оно будет предать его основополагающим принципам.
Даже если вы поверили в распределенную вещь, git все равно будет беспорядок. Что такое, например, ветка? Они говорят, что вы неявно создаете ветвь каждый раз, когда клонируете репозиторий, но это не может быть тем же самым, что и ветка в одном репозитории. Так что по крайней мере две разные вещи называются ветвями. Но тогда вы также можете перемотать назад в репо и начать редактирование. Это похоже на второй тип ветки или что-то другое? Возможно, это зависит от того, какой тип репо у вас есть - о да - видимо, репо тоже не очень четкое понятие. Есть нормальные и голые. Вы не можете нажать на обычный, потому что голая часть может выйти из синхронизации с исходным деревом. Но вы не можете cvsimport для голого, потому что они не думали об этом. Таким образом, вы должны cvsimport к нормальному, клонировать то, что было на самом деле, которое разработчики ударили, и cvsexport, что для рабочей копии cvs, которую еще нужно проверить в cvs. Кто может быть обеспокоен? Откуда взялись все эти осложнения? Из самой распределенной идеи. В конце концов я бросил гитолит, потому что это налагало на меня еще больше этих ограничений.
Git говорит, что ветвление должно быть легким, но многие компании уже сталкиваются с серьезной проблемой ветки изгоев, поэтому я подумал бы, что ветвление должно быть важным решением со строгой охраной. Это то, где perforce действительно светит...
В perforce вам редко нужны ветки, потому что вы можете очень легко манипулировать наборами изменений. Например, обычным рабочим процессом является синхронизация с последней известной хорошей версией на главной линии, а затем запись вашей функции. Всякий раз, когда вы пытаетесь изменить файл, diff этого файла добавляется в ваш "набор изменений по умолчанию". Когда вы пытаетесь проверить набор изменений, он автоматически пытается объединить новости из mainline в ваш набор изменений (эффективно переустанавливая его), а затем совершает транзакции. Этот рабочий процесс применяется без необходимости даже его понимания. Таким образом, Mainline собирает историю изменений, которые вы можете довольно легко вишневым выбрать свой путь через позже. Например, предположим, что вы хотите вернуть старый, скажем, тот, который был до последнего. Вы синхронизируете до момента нарушения, отмечаете затронутые файлы как часть набора изменений, синхронизируете с моментом после и объединяетесь с "всегда мой". (Там было что-то очень интересное: синхронизация не означает одно и то же - если файл доступен для редактирования (т.е. В активном наборе изменений), он не будет скреплен синхронизацией, но будет отмечен как подлежащий разрешению.) Теперь у вас есть список изменений, который отменяет оскорбительный. Объединитесь в последующих новостях, и у вас есть список изменений, который вы можете плюнуть на верхнюю линию, чтобы иметь желаемый эффект. Ни в коем случае мы не переписывали какую-либо историю.
Теперь, предположив половину этого процесса, кто-то подбежит к вам и попросит вас все бросить и исправить ошибку. Вы просто даете своему списку изменений по умолчанию имя (фактически число), затем "приостановите" его, исправьте ошибку в теперь пустом списке изменений по умолчанию, зафиксируйте ее и возобновите имя списка изменений. Это типично, когда несколько списков изменений приостановлены в то время, когда вы пытаетесь разобраться. Это легко и конфиденциально. Вы получаете то, что действительно хотите от ветрового режима, без соблазна отложить или вымыть из слива в магистраль.
Я предполагаю, что теоретически возможно сделать что-то подобное в git, но git делает практически все возможное, а не утверждает рабочий процесс, который мы одобряем. Централизованная модель представляет собой набор допустимых упрощений относительно распределенной модели, которая является недействительным обобщением. Это так сильно обобщило, что в основном предполагается, что вы будете использовать контроль источника поверх него, как это делает репо.
Другое дело - репликация. В git все возможно, поэтому вам нужно разобраться в себе. В perforce вы получаете эффективный кеш без учета состояния. Единственная конфигурация, которую ему нужно знать, - это то, где находится мастер, и клиенты могут указывать либо на мастер, либо на кеш по своему усмотрению. Это пятиминутная работа, и это не может пойти не так.
У вас также есть триггеры и настраиваемые формы для утверждения обзоров кода, ссылок bugzilla и т.д., и, конечно же, у вас есть ветки, когда они вам действительно нужны. Это не понятно, но это близко, и он мертв легко настраивается и поддерживается.
В целом, я думаю, что если вы знаете, что собираетесь работать централизованно, что все делают, вы можете использовать инструмент, который был разработан с учетом этого. git переоценивается из-за страшного остроумия Линуса, а также склонности людей следовать друг за другом, как овцы, но его основной смысл не на самом деле не соответствует здравому смыслу и, следуя ему, git связывает своими руками с двумя огромными догмами, которые: а) программное обеспечение и (б) данные должны быть одинаковыми как на клиенте, так и на сервере, и это всегда будет усложнять и хромает при централизованном задании.
Использование GIT в качестве замены для плохого управления строкой кода является обычным явлением. Многие из недостатков Perforce являются результатом плохой стратегии ветвления. То же самое для любого другого централизованного инструмента. Если вам нужно создать тонну ветвей, вы делаете что-то неправильно. Почему разработчикам необходимо создать так много ветвей?
Кроме того, почему так важно отключить работу? Просто чтобы кто-то мог работать на поезде? Что касается единственного места в эти дни, вы не можете получить беспроводное соединение. И даже у большинства поездов есть приличный Wi-Fi.