Корпоративный уровень принятия Git?
Недавно среди коллег возникла дискуссия о том, что в современной индустрии программного обеспечения существуют два отдельных мира:
- FOSS ориентированный
- корпоративный
Вопрос
Сколько Git используется в корпоративных средах?
Какой у вас опыт работы с Git в корпоративной среде?
6 ответов
Для чего это стоит, мы используем git на моем рабочем месте. Все вполне довольны этим. Конечно, ни один человек не сможет сказать вам, как часто это происходит.
Я подозреваю, что распространенность cvs/svn в большей степени связана с инерцией, чем с чем-либо еще. Они определенно были одними из лучших (если не самыми лучшими) вариантами в течение длительного времени **, и у большого числа разработчиков была возможность научиться правильно их использовать. Если большая часть вашей рабочей силы уже знакома с ними, и они достаточно хороши, сколько компаний мы можем ожидать, чтобы попробовать что-то новое?
Другой распространенный фактор в решениях корпораций связан со своего рода стигмой, связанной с свободным программным обеспечением. Люди склонны связывать денежную стоимость и стоимость, воспринимая более дорогие продукты как лучшие (например, я читал об одном психологическом исследовании, в котором людям давали одно и то же вино дважды, и говорили, что одно было более дорогим сортом. Они склонны оценивать его как дегустация лучше). С программным обеспечением в этом отношении есть определенная доля правды - вы часто можете купить некоторую гарантию поддержки и обслуживания продукта. Мы все знаем, что признанные проекты с открытым исходным кодом могут легко победить (больше тестеров, больше авторов документации, более быстрых выпусков исправлений...), но я уверен, что это все еще мотивирует многие компании покупать продукты VCS/SCM. Однако это явно не причина, по которой люди используют cvs/svn.
** Пожалуйста, никаких огненных войн! Я несгибаемый фанат мерзавцев, но я знаю, что это не всегда существовало. Конечно, некоторые все еще не согласны, как, например, Линус Торвальдс:
В течение первых 10 лет обслуживания ядра мы буквально использовали tarballs и патчи, которые являются намного более совершенной системой управления исходным кодом, чем CVS ... Некоторое время девизом Subversion было "CVS сделано правильно", или что-то в этом роде, и Если вы начнете с такого рода лозунгов, вам некуда идти. Нет способа сделать CVS правильно.
Я не думаю, что мнение имеет значение, но факты. Кроме того, компании с закрытым исходным кодом обычно не любят раскрывать детали своей внутренней архитектуры. Так что... я не думаю, что есть полный и правильный ответ на этот вопрос.
Для недавно созданных компаний или компаний, которые никогда ранее не использовали контроль версий, сбор мер по переносу не требуется.
А для начинающих разработчиков git больше подходит, потому что старшие разработчики / менеджеры могут направить их, чтобы "манипулировать" лучшей историей изменений, прежде чем отправлять на центральный сервер. Скажи им git commit --amend если они найдут что-то не так в истории.
Если используется CVCS, хаос может произойти, когда несколько пользователей зафиксировали свой код. Негде практиковать, как создать хороший коммит.
Единственная проблема - это номер редакции, если вам нужен этот номер в качестве номера версии продукта. Потому что git использует хеш. Вам может понадобиться git describe или другой метод в качестве обходного пути.
Отказ от ответственности: вышеупомянутый пост - просто мое скромное мнение, я не знаю, как принимаются решения.
Я подозреваю, что сила, лежащая в основе не перехода к мерзавцу, заключается не в том, что "бесплатно - это зло", а в огромных миграционных расходах. Если большая корпорация попытается перейти на другую систему, она рискует что-то сломать.
Денежная отдача от перехода к более совершенной системе должна быть предсказана и сопоставлена с прямыми (простыми в расчете) и косвенными (временными потерями производительности, нарушением процесса сборки, интеграцией с системой отслеживания ошибок...). Поскольку никто не знает, как рассчитать косвенные затраты, лица, принимающие решения, могут предпочесть предположить, что затраты огромны.
Наткнулся на это, когда искал способ использовать Git на моем рабочем месте. Извините, что разочаровал, но я не "против" свободного программного обеспечения, просто Git не будет работать для нас без посторонней помощи. Вы можете иметь некоторое представление о скором прибытии Git, если попытаетесь понять, прежде чем называть имена.
Я не знаю, но мы используем Microsoft Visual Source Safe 6.0. Они смотрят на покупку новой версии. Когда я предложил git или же svn, они махали рукой, говоря мне, что они были свободны (как в пиве), поэтому плохо.
Я могу ожидать, что корпорации будут использовать любые POS, которые есть вокруг, и с тех пор стоят денег.