Comments 73
как мне нравятся прогнозы вида: история закончилась сегодня, дальше будет как сегодня.
Слышали когда-нибудь о CVS?
Не только слышали, но и вовсю использовали. Более того, использовали и ее предшественницу - систему rcs.
Слышали когда-нибудь о CVS
Помню как на работе на него переходили как на прогрессивное решение - после чего были и svn и git (с внутривидовым переходом gitlab->github)...
«Лучше, чем CVS» в те времена подразумевало ... сколько-нибудь улучшенную поддержку ветвления.
Не довелось работать с CVS, и не могу представить себе на сколько там была плохая система работы с ветками, если то что было в SVN называют "улучшенной поддержкой" - пользоваться ветками в свн было просто невозможно. В проекте среднего размера создание ветки занимало полторы вечности. И даже если хватало терпения дождаться ее создания и синхронизации с сервером, то пользоваться ими для разработки фич было невозможно.
Тогда, ребятки, мы о большем и не мечтали.
Очень даже мечтали - например, не терять изменения, когда несколько человек работали над одним файлом. Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
В CVS всё - коммиты, история, ветки - было на уровне отдельных файлов (т.е. у каждого файла своя последовательность версий, коммит изменений в несколких файлов по сути распадался на последовательность независимых коммитов), какое то версионирование репозитория в целом делалось только тегами.
В проекте среднего размера создание ветки занимало полторы вечности
А зачем делать ветки для всего проекта? Обычно он разбивается на компоненты обозримого размера и ветка делается для отдельной компоненты. Работал над продуктом, который с нуля компилировался несколько часов, проблем с ветками в период времени, когда жили на svn, не помню. И в любом случае там же COW, реально svn copy полную копию не создаёт.
В проекте среднего размера создание ветки занимало полторы вечности.
На сервере должна мгновенно создаваться. На клиенте switch тоже быстро должен работать.
> Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
А в git что изменилось с этим?
А в git что изменилось с этим?
Гит был заметно догадливей по поводу тех изменений, которые уже успели слить.
SVN до какого-то момента, если попадал на ромбовидную схему слияния (т.е. A в B, A в C и теперь хочешь B и C слить) - практически гарантированно давал конфликты. Или если руками кусок кода скопировал. В точность такой же, как в той ветке, что сливаешь.
Потом в нем это исправили, но было уже поздно.
то как слил (в рамках одного файла как минимум) GIT все равно приходится проверять глазами. Иначе, если доверять, возникают неожиданности в прикладной логике.
Редко. Но возникают.
О да! Особенно в этом плане отличаются IF-ELSE с условиями на несколько строк.
Разные коммиты затрагивают разную часть условия и по отдельности корректны. А слитые воедино без конфликтов - уже нет.
Одно дело проверять, другое дело - плеваться и рычать "Да тут же совершенно одинаковый, с точностью до пробелов, код на вершине двух веток, где тут конфликт?"
Оно и работало быстро. В svn создание ветки было очень быстрой и дешевой операцией, что в те времена было на острие технического прогресса, потому что так умели тогда далеко не все системы контроля версий, даже платные. Это ускоряло и облегчало разработку просто в разы. Репозиторий хранился в централизованной БД на сервере, и для работы требовалась связь с ним - это да, но при работе над маленькими и средними проектами в рамках одной компании это абсолютно не мешало. Хотя сверхогромные проекты, такие как Windows NT, svn скорее всего не потянул бы.
Я и с git'ом commit и push всегда вместе запускаю, мало ли что с локальной машиной случится.
ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
А я RCS и сегодня использую, в основном для некоторых конфиг-файлов, Git в простейших, но при этом требующих контроля версий, ситуациях очень уж похож на пушку при охоте на воробьёв, рогатки достаточно :)
А ещё visual sourcesafe, perforce, tfs..
Использовали CVS, RCS, Perforce, SVN, Mercurial, TFS. Ничего отвратительнее git не встречал. Но приходится использовать, потому что всё на нём, в современном мире только так... Ведь и сам автор, Торвальдс, в первом коммите написал, что это будет отвратительная система, так оно и получилось. То же самое с современной архитектурой зданий, дизайном автомобилей типа Cybertruck и т.д. Уродство вываливается на нас, а мы рады его принять.
Monotone пришлось попользоваться. Кажется, самое ужасное творение. Хотя нет, ещё был arch.
Git превратился в франкенштейна. Оброс огромным количеством костылей из-за которых его использование превратилось в хождение по минному полю.
Самый яркий(но не единственный) пример - LFS:- У нас децентрализованная система для работы с исходниками!
- Нам нужно хранение больших файлов.
- Берите другую систему контроля версий.
- Они дорогие. И вообще мы привыкли к гиту.
- Ну ладно. Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет. И, кстати, вам теперь отдельно придется резолвить работу с LFS поинтерами.
Проблема гита в том, что вместо того чтобы развиваться отбрасывая легаси - он обрастает новыми фичами, противоречащими старым фичам, оставляя поддержку старых. Все боятся что-нибудь отрезать от гита, в итоге получается монстр.
Ни одна команда не использует все возможности гита. Обычно выбирается список гит фичей, которые разрешены к использованию и строго придерживаются флоу.
Отдельно "доставляет" гит комьюнити. Есть прослойка людей, которые что-то знают про гит и они чертовски ЧСВшные. Не дай бог покритикуешь гит, они прибегут и расскажут что ты идиот и не правильно используешь гит. Иди кури маны.
Но есть нюанс, я идиот и не знаю гит, несмотря на то что вынужден был влизть в его кишки, делать форки того же LFS и в течении года в компании писал гит клиент. И, повторюсь, я гит не знаю, даже после того как ознакомился с ним куда как глубже рядового пользователя. А что говорить, о рядовых пользователях? 99% из них знают про гит еще меньше меня, и при этом вынуждены как-то им пользоваться.
Гит предназначался для хранения сорсов и обмена патчами по почте, и все это из консоли. Из-за того что он стал корпоративным стандартом - он заполонил буквально всё.
Никакая новая система контроля версий не потеснит гит до тех пор, пока не появится какой-то совершенно новый подход к версионности(ну или мощная корпорация, которая будет продвигать другой VCS). Так что придется жить с гитом. Вероятность появления популярной альтернативы ИМХО мала. Надежда только на то, что у кого-то хватит смелости пофичекатить гит, выкинуть из него легаси, которое не нужно большинству и превратит его наконец в цельный продукт. Но вероятность этого крайне мала.
Нужен минигит с clone, checkout, add, commit push, reset и флагом --force :)
+merge, rebase... а потом еще что-то захочется
Так, стоп, у нас же уже есть гит :)
Вот rebase уже еретическая команда, переписывающая историю.
Подуло свежим ветерком fossil-а.
На "ГитСпике" это называется не переписывание истории (что-то плохое), а её "решание" или "определение" :)
Вот в каждом обсуждении git вижу критику этой команды. Но что мешает просто ее не использовать и запретить форспуши в мастер? После того как я освоил rebase, я не представляю себе жизнь без этой команды, т.к. промежуточные коммиты на самом деле никому не нужны, куда важнее чистота истории и атомарность.
промежуточные коммиты на самом деле никому не нужны
Иногда через пару лет после написания кода бывает полезно посмотреть историю развития и комментарии, что бы вспомнить, как оно появилось. Я поэтому и локальные бранчи после мёрджа никогда не удаляю. А в мастер заносятся оттестированные фичи целиком одним коммитом, отсюда чистота истории и атомарность без rebase.
Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
ровно противоположный экспириенс, каждый тул пытается изобрести какие-то свои абстракции и подходы вместо нативных для гита. Стоит один раз прочитать git book и гит станет прозрачен как слеза, и так со всем системами контроля версий, я профессионально лет по 5 пользовался svn, hg, git и на всех них можно нормально жить только из консоли, всё работает чётко и без ошибок, ты точно понимаешь что делаешь, отдельно могу признавать только вьюверы которые дерево красивое нарисуют, не более того.
Это была замечательная иллюстрация исходному комменту :)
Совершенно с вами согласен. Именно поэтмоу мы и сами начали делать свой гит тул, потому что абстракции других тулов нас не устроили.
Про git book вы хорошо сказали, только людям работать надо, а не достаточно сложный технический материал усваивать. Поэтому проще предложить тул, чем условному художнику сказать "да ты просто прочитай git book".
Ох уж опять console-only свидетели. С git можно жить не вылезая из GUI, за редким исключением. Неужели удобно делать интерактивный rebase через консоль?
а почему вы решили что вам нужен LFS? Гит прекрасно хранит бинари. LFS нужен если вы постоянно меняете большие бинари и они дофига весят в клоне. Но если вам нужна распределённость и вы готов за неё платить, то пожалуйста, всё будет работать. Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично. На LFS эта штука бы еле еле шевелилиась, т.к. LFS чудовищно плохо работает с большим(10k и больше) количеством файлов
Геймдев. Большие бинари постоянно меняются. Ну и локи, конечно.
Так, и у меня геймдев, так что коллеги. Если говорить про исходники с которыми работают художники то они у нас частично всё ещё в svn сидят, там есть репы по теру, sparse checkout и всякое такое. Вы говорите что хотите распределённости, так она есть, и для больших бинарей она реально будет стоить места. Хотя git pack вроде учился более эффективно работать с бинарями если меняется только часть, хотя новость не могу найти сходу. Любая распределённая система, в который вы захотите хранить много больших часто меняющихся бинарей будет жрать место. В играх с огромным количеством контента мы прямо дизайнили архитектуру игры и её деплоя так, чтобы было удобно это всё поддерживать, быстро релизить, и не лочить ресурсы для работы(чтобы несколько человек не пересекались на одном файле)
Я не хочу распределенности. Я хочу консистентности: чтобы инструмент единообразно работал, если децентрализованная система, то децентрализованная. Если с единым сервером, то с единым сервером. А не так, что над каждой командой надо думать: а как она отработает в данном случае?
Смотришь в документацию: "команда достает из коммита содержимое файла", выполняешь её и получаешь какой-то мусор(по факту LFS pointer). То есть команда не соответсвует документации. Вернее формально соответствует: в гите лежит поинтер, получил поинтер. Но это не ожидаемое поведение.
lFS либо часть гита, либо не часть гита.... А по факту это костыль, которые болтается вместе с гитом, аффектит поведение гита, документирован отдельно...
Извините что я так много про LFS, просто это самый яркий пример костылей в гите.
Я знаю о чём говорю, у меня есть гит репо с почти миллионом бинарей, десятью тысячами коммитов и весом в несколько десятков гигабайт, и всё работает просто отлично.
На масштабах десятков гигабайт действительно работает безо всяких lfs. Но вот на масштабах в единицы терабайт уже нет.
ну так логично, если вы хотите положить туда терабайты и не хотите держать их в каждом клоне, то вариантов то больше нет, их же надо где-то хранить, тогда выбирается сервер для хранения и мы получаем так или иначе что-то типа LFS. Я не понимаю чего можно ожидать, вы или храните всё в каждом клоне(кстати, на сервере у нас у разных клонов гит кеш общий, это сильно экономит место), либо храните "где-то там" и тогда нет никакой распределённости.
Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет.
вот я этого понять не могу. Да, или децентрализованная но жирная, или централизованная, тогда история больших файлов только на сервере и за её хранение расплачивается только сервер, другого не дано.
Я в принципе готов держать терабайты в каждом клоне. Но вот операции типа git gc - это очень больно. Или например отсутствие докачки в git pull. Или то что всё утыкается в проц из-за того что git до сих пор использует gzip.
да, тут со всем соглашусь, особенно zstd бы не помешал, там модно всякое творить, типа сжатия с переиспользованием прошлого архива как словаря, в случае с гитом это могло бы дать значительный буст https://developer.chrome.com/blog/shared-dictionary-compression
я тут подумал, было бы гораздо удобнее работать с большими репами если бы каждый живой чекаут сам бы в фоне подтягивал новые файлы и раздавал как торрент, тогда и проблем с закачкой быть не должно, и с нагрузкой на сервер
Самый яркий(но не единственный) пример - LFS:
LFS — это плагин. Не нравится — не пользуйтесь. Я вот не пользуюсь. Пара гигов истории тарболов просто лежат в репе
Вот вам LFS. У нас как бы децентрализованная система, но без центрального сервера она работать не будет
Децентрализованность системы важна для распределённой разработки. Громадное большинство разработчиков заняты в централизованной разработке и не нуждаются в децентрализации
Но есть нюанс, я идиот и не знаю гит, несмотря на то что вынужден был влизть в его кишки
Простите за прямоту, но тут нечем гордиться. Если отбросить свистоперделки, то гит очень прост. База данных на файлах из трёх видов объектов: блобов, деревьев и коммитов соединённых известным образом.
А я и не горжусь.
Я указываю на то, что если сеньор в компании занимающийся гит клиентом всё еще много чего не знает про гит, то ожидать адекватных знаний от рядовых сотрудников - сущий бред.
Принцип парето работает, поэтому гит так популярен. 80% фич освоить способен практически любой, и этого более чем достаточно для эффективной работы, а обгадить можно все что угодно, не нравится гит - предложите варианты лучше, возможно за вами народ потянется и в конечном итоге ваш вариант уделает его.
На мой взгляд, стыдно в 2024 знать Гит ТАК глубоко. Это будет означать, что профессионал занимается НЕ ТЕМ.
Это точно чушь.
Вам в любом случае в компании нужен как минимум один человек, который глубоко знает гит, чтобы решать вопросы когда всё пойдет не так. А оно обязательно пойдет. Когда кто-то не то зальет и надо будет срочно откатить, когда кто-то использует rebase вместо мерджа, да еще и не правильно. Когда кто-то зальет через force всё.
Да и банально когда вы захотите локи, а окажется что ваш битбакет клауд их не поддерживает.
Я считаю, что гит задумывался Франкенштейном. Торвальдс – чувак с проблемами психики и контролем гнева. Он просто хотел создать такого Франкенштейна, и чтобы все на него подсели. Он выбрал правильную аудиторию – профессионалов-идеалистов, ценящих ненужную инженерную сложность. Он не прогадал.
Довелось еще поработать на проекте без гита или хотя-бы svn. Впрочем, там была какая-то система контроля версий, не знаю самописная или какая-то сторонняя. Был веб интерфейс с файлами проекта. Если тебе надо было поработать с одним из них, ты скачивал его с флажком "заблокировать", и до тех пор пока ты не заливал исправленную версию, никто не мог его заблокировать (скачать можно было).
Обычно качали весь проект на свой комп, дорабатывали или фиксили баги, потом все эти исправления пофайлово заливались в репозиторий.. Думаю не стоит долго рассказывать насколько это было неудобно и сколько разных неприятных инцидентов вызывало, но ничего лучшего у нас не было.
ты скачивал его с флажком "заблокировать", и до тех пор пока ты не заливал исправленную версию, никто не мог его заблокировать
В Visual SourceSafe такой же подход, в конце 90x-начале 2000х с ним работали.
Да, спасало только то, что у нас народа не так много над проектом работало, и если какой-то файл надолго в блоке зависал, то можно было просто подойти к автору блокировки и попросить ее снять..
просто подойти к автору блокировки
А он вдруг в отпуске ) Так то да, тоже был маленький проект человек из десяти и сидели рядом.
Я работал с примерно десятком таких систем. Git - самый сложный из них и запутанный. Для новичка труднее всего освоить и работать так, чтобы не запутаться.
Как не парадоксально, я думаю, что это один из секретов его популярности. Кто потратил кучу сил и времени на его освоение, тому уже не хочется осваивать ничего больше чтобы работа не пропала зря.
И да, 99% человечества распределенная система не нужна. Всегда есть какой-то master repository, из которого строятся версии для пользователей, и все работают напрямую с ним. Иначе кому-то придётся делать merge на чужие изменения, что весьма неприятно.
Не взлетит, как не взлетел Darcs в своё время, у которого релиз аж в 2003 случился. Хорошо если на уровне Mercurial окажется, но прям супер сомнительно.
У darcs были проблемы с подлежащей теорией. Они там раза два меняли коней на переправе, переписывая основные компоненты чуть ли не с нуля, чтобы закрыть неконсистентность. У pijul в этом плане больше шансов.
Как мне кажется, основная проблема darcs была в том, что люди были не очень готовы к нему: когда darcs стал стабильным, общий запрос был на СКВ ревизионного типа, потому что все СКВ того времени были такими.
При этом я обожаю darcs.
Двадцать лет — ничто