Частота корпоративного принятия Git?

Ответ 1

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

Я подозреваю, что продолжающаяся распространенность cvs/svn гораздо больше связана с инерцией, чем с чем-либо еще. Они были, безусловно, одним из лучших (если не лучшим) выбором в течение длительного времени **, и у большого числа разработчиков была возможность научиться хорошо их использовать. Если большая часть вашей рабочей силы уже им удобна, и они достаточно хороши, сколько компаний мы действительно можем попробовать что-то новое?

Другой распространенный фактор в решениях корпораций связан с каким-то стигмой, связанным с бесплатным программным обеспечением. Люди склонны связывать денежные затраты и стоимость, воспринимая более дорогие продукты как лучше (например, я читал о психологическом исследовании, в котором людям было дано одно и то же вино дважды, и сказал, что один из них был более дорогим. как дегустация лучше). С программным обеспечением в этом отношении есть определенная доля правды - вы можете часто покупать некоторую гарантию поддержки и обслуживания продуктом. Мы все знаем, что созданные проекты с открытым исходным кодом могут легко победить (больше тестировщиков, больше разработчиков документации, более быстрые выпуски исправлений...), но я уверен, что это все еще мотивирует многие компании покупать продукты VCS/SCM. Однако это явно не причина, по которой люди используют cvs/svn.

<суб > ** Пожалуйста, никаких огней! Я фанатик git, но я знаю, что он не всегда существовал. Конечно, некоторые до сих пор не согласны, как Линус Торвальдс:

В течение первых 10 лет поддержки ядра мы буквально использовали tarballs и патчи, что намного превосходит систему управления исходным кодом, чем CVS... Лозунг Subversion на некоторое время был "CVS done right" или что-то вроде что, и если вы начнете с такого рода лозунга, вам некуда идти. Нет никакого способа сделать CVS право.Суб >

Ответ 2

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

Ответ 3

Для вновь созданных компаний или компаний, которые ранее не использовали контроль версий, стоимость перехода на git не существует.

И для начинающих разработчиков git более подходит, потому что старшие разработчики/менеджер могут помочь им "манипулировать" лучшей историей изменений до нажатия на центральный сервер. Сообщите им git commit --amend, если они найдут что-то неправильное в истории.

Если используется CVCS, может произойти хаос, когда несколько пользователей передали свой код. Нигде не следует практиковать, как создавать хорошие фиксации.

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

Ответ 4

Я не знаю, но мы используем Microsoft Visual Source Safe 6.0. Они ищут новую версию. Когда я предложил git или svn, они махнули рукой, сказав мне, что они свободны (как в пиве), поэтому плохо.

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

Ответ 5

Отказ от ответственности: вышеупомянутая статья - это просто мое скромное мнение, я не знаю, как принимаются решения.

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

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

Ответ 6

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