Комментарии 34
За 15 лет разработки наблюдал две миграции, svn->mercurial, mercurial->git. По опыту разработчики быстро делятся на две фракции, кто прочитал официальную документацию, и им всё понятно и работают они с системой контроля версий через консоль, и тех кто поставил какой-то gui tool, не читал документацию, пытается применять подходы из старой системы контроля версий в новой. По факту же даже между git и mercurial есть значительные различия, не говоря уже о том что в svn существовали подходы которые в новых системах крайне неудобны (например частичный мердж подпапок и ветвление тоже подпапок а не всей репы). Короче важно как-то сделать так чтобы побольше людей глубоко прониклось новой системой контроля версий, изучили доки, и тогда новые подходы будут выработаны быстро и эффективно.
По факту же даже между git и mercurial есть значительные различия
Ага. Mercurial – система контроля версий, git – конструктор для сборки системы контроля версий :-)
ну типа того. Хотя супер наполенный контентом проект у нас так и сидел на svn, проигнорировав миграцию на hg. А с гитом ребята хорошо изучили вопрос, перестроили workflow и всё стало ок, только вместо одной svn репы, стало 8, как раз из-за мерджа отдельных кусков проекта
Прикольно. Для меня выглядит так, будто вы попали на тот редкий случай, когда конструктор удобнее готового решения.
У меня при пользовании гитом в основном подгорает из-за отсутствия полноценных веток (указатель на голову ветки – это немного не то, он не позволяет увидеть, какие коммиты делались в эту ветку, а какие пришли со стороны).
Ну и, конечно, поначалу бесило отсутствие "святости истории" (очень быстро пришлось освоить git reflog) и то, что pull/push не обрабатывают все ветки.
Но в целом git – стандарт де-факто, в случае отсутствия каких-то фатальных проблем нет резона использовать другую vcs.
ну там примерно полмиллиона файлов в том гите, так что да, нестандартно. А про ветки вы очень верно подметили, да в гите именно указатели на головы и всё.
кстати, у нас да, алиасов понаписано много, и отдельно бесит что нельзя простым образом гитконфиг просунуть через ssh как ключи, на произвольнос сервере без алиасов чувствуешь как будто в каменный век попал, всё руками набирать, тот же git submodule update —init —recursive просто неимоверно бесит, у меня это алиас git sup.
git создан для опенсорс разработки, для всего остального он совершенно не годен. используйте свн, он умеет делать все тоже самое что и гит. открою секрет можно сделать клн репо у себя на компе и тоже будут локальные камиты
Чем же, позвольте полюбопытствовать, опенсорц разработка так принципиально отличается от "всего остального"?
Концепция гит: куча ветвей, сделанная программистами неизвестного качества, которые интегрирует в мастер-ветвь гуру продукта. В принципе, неплохо ложиться на процесс разработки в компании, которые постоянно нанимают джунов, немного их эксплуатируют и заменяют на новых. Плохо ложиться на организацию, которая нанимает опытных программистов, в случае, когда над отдельным подпродуктом работает 1-2 программиста максимум.
Распределённая разработка в гит не имеет особого смысла для корпоративного применения (скорее, опасна и неудобна для корпораций), но очень востребована в опенсоурсе.
Концепция гит: один репозитарий - один продукт. Ветвление репозитария целиком. Отлично подходит для опенсоурсной разработки, но в корпоративной среде возникают проблемы с зависимостями: продукты не являются независимыми. Т.е. крупные организации очень редко разрабатывают самодостаточный продукт, использующий только "чужие" библиотеки. Обычно он состоит их кучи библиотек и кучи экзешников, каждый из которых - отдельные подпродукты с собственным циклом выпуска релизов. В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Гит может работать с бинарными файлами. Но - всегда криво и с косяками, с дополнительными нашлёпками.
В общем и целом, гит отлично подходит для компаний, чьи разработки не требуют системы управления конфигурации (сonfiguration management).
Т.е. если версия вашего продукта "живёт" полгода, релизы выпускаются часто-часто, долгосрочной поддержки нет, цена ошибки низкая - гит для этого отлично подходит.
Отлично гит подходит для веб-разработки, когда конечный продукт вы же и поддерживаете (т.е. предоставляете доступ к своему хостингу, но не даёте клиенту автономный хостинг).
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
С моей точки зрения, идеальной системой управления версиями была бы централизованная система с кластером серверов, похожая на Perforce или SVN, но с возможностью выделять/маркировать отдельные папки/подпродукты/каталоги так, чтобы слияние изменений можно было выполнять только на папку целиком.
Если ваш цикл технической поддержки продукта - десятилетия, если продукты сложные и взаимно-зависимые, если вам в любой момент может понадобиться точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик, и вы не можете заставить заказчика обновиться на текущую версию продукта, потому что обновление стоит очень больших ресурсов, если вместе с продуктом вы разрабатываете документацию в разных форматах (бинарных форматах редакторов и CADов) - гит не для вас.
Назовите пожалуйства нормальные системы контроля версий, работающие с бинарными файлами. И как в таких системах выглядит просмотр изменений между файлами. И частичное применение изменений заодно.
Perforce, например. Разумеется, изменения в бинарных файлах произвольного типа просмотреть/объединить сама система не может (точнее, может для ограниченного количества форматов, в основном картинки) - но если есть внешние средства - можно использовать их.
При этом, например, хранение проектной документации в том же Word/Autocad/Visio - запросто. Одна возможность хранить историю изменений бинарных файлов (и сами файлы) - это уже очень много.
А в чём разница с гитом?
Ну например, выложив в Perforce бинарный файл (который не получиться смержить) вы сможете поставить ему тип "binary+l". Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз. Соответственно, необходимости "сливать" конкурентные изменения - не будет.
Разумеется, скорее всего для git можно сколхозить что-то подобное. Или использовать отдельную систему "управления документацией" - но это, как надеюсь вы понимаете, набор из резиновых костылей.
Ещё раз - в git можно сделать всё. Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Кстати, с этой точки зрения точно то же самое и в Perforce. Разрабатывать классический опенсоурсный продукт в Perforce - с получением патчей от неопределённого круга лиц, с разработчиками работающими независимо и самостоятельно - ну, больше всего похоже на мазохизм.
Так как Perforce - система централизованная, после этого данный файл сможет редактировать только один человек за один раз.
Вообще с моей точки зрения блокирование одновременной работы - это само по себе один большой костыль.
Но предназначен git для специфической модели разработки и специфических целей - как только вы пытаетесь его приспособить за пределы его исходной концепции - получается хреново.
Под эту концепцию вполне попадает процентов восемдесят современной разработки ПО.
точно повторить сборку вашего продукта 10-летней давности и исправить там ошибку, которую обнаружил заказчик,
А в чем проблема то? В этом вашем git через полгода коммиты превращаются в тыкву? Или никто не знает как пролистать историю на 10 лет назад?
В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях
Ну, субмодули, например. Не слышали? :)
В гит немедленно возникает проблема зависимостей между подпродуктами в разных репозиториях.
Это проблемы билдовой системы, в которой расписываются зависимости между версиями подпродуктов и откуда их брать - в общем случае разные подпродукты могут лежать в разных системах контроля версий.
Какие-то странные аргументы, куча компаний использует гит и радуется жизни, вспоминают svn и mercurial как страшный сон. Гит в первую очередь даёт свободу команде, она сама ведёт свой проект и сама выбирает как будет синхронизароваться с другими проектами, как правило для этого есть контракты иного уровня. Так же что делать если вы вдруг решили вывести часть своих библиотек в open source? А для решения приведённых вами проблем есть монорепозитории, гит модули и иные средства гита для синхронизации кода между проектам. Гит стал практически стандартом разработки не просто так.
Ага, svn сервер не доступен и приехали. Разработка стала. Так по корпоротивному
Так разработка это не только в vim код херячить. gitlab/jenkins/файлопомойка/любой компонент отвалится - разработка стала.
Так разработка это не только в vim код херячить. gitlab/jenkins/файлопомойка/любой компонент отвалится - разработка стала.
Что мешает писать код локально, пока что то из этого недоступно ? Мы же не рассматриваем цикл CI/CD, а лишь написание кода. В случае с svn даже историю изменений локально не получится сохранить
git создан для опенсорс разработки, для всего остального он совершенно не годен.
Hidden text
Ваш покорный слуга мигрировал проект лет семь назад. Сначала пытались использовать rtcTo/rtc2git, но там совсем было тускло. А rtc2gitcli оказался вполне себе рабочим, правда, пришлось какие-то мелочи править. А так, судя по оповещениям с GitHub, проект все ещё развивается, значит, сидят ещё терпеливые люди на RTC =)
Переход на другую систему контроля версий