Comments 17
Папка
.git/lfsзанимает 90% репозитория
Что если отключать синхронизацию lfs на время ваших операций? `export GIT_LFS_SKIP_SMUDGE=1`
Во-первых, мы говорим об объемах репозитория, который перевалил за терабайт.
Что же там такое, что аж на терабайт и почему в таком случае это все еще git?
геймдев :) больше всего весят ассеты. только не спрашивайте “А почему не X?”. ответ будет где-то между “NDA” и “обстоятельства”, т.е. по факту с чем приходится работать, с тем приходится
геймдев :) больше всего весят ассеты.
Так и подумал, но решил что лучше уточнить)
только не спрашивайте “А почему не X?”.
Ну на самом деле да, следующим хотел про perforce helix спросить "а чего не он, он как раз под геймдев позиционируется"
ответ будет где-то между “NDA” и “обстоятельства”
Как говорится - "так исторически сложилось"
Поддерживаю комментаторов, стало интересно. Что за проекты хранят терабайт в гит.
Касаемо террабайт не знаю, но в геймдеве ассеты спокойно могут весить несколько гигабайт, а то и десятков. Так же подобное встречается в вебе. Правда для подобного обычно используют git lfs, а тысячи коммитов относительно текста, даже с самой раздутой архитектурой больше гига вряд ли весить будут) Я бы даже сказал в реальности несколько сотен мегабайт с учётом хранения всех дифов.
Да и проблем с мерждем тех же ассетов обычно нет, если грамотно выстроена работа в команде)
Вы про ребейз никогда не слышали?))
Я попробовал "Обратный локальный мерж" на моем небольшом демо репозитории.
Во-первых, тут происходит схлопывание всей истории ветки в один коммит поверх ветки main. То есть по сути rebase + squash.
Во-вторых, мне пришлось явно выйти из мерджа:
% git switch -C feature
fatal: cannot switch branch while merging
Consider "git merge --quit" or "git worktree add".
% git merge --quitИ я также согласен, что форс-пуш лучше избегать. Можно изменить этот подход без потери истории, не создавая rebase, и не делая форс-пуш.
# уходим в detached state
git switch --detach origin/main
# мержим ветку в detached HEAD
git merge -n feature
# выходим из мерджа, решаем конфликты, добавляем файлы
git merge --quit
git add -A
# создаем временный коммит чтобы зафиксировать результат как HEAD
git commit -m "Temp commit"
# самый главный трюк: создаем merge commit используя HEAD с двумя парентами, полчаем его хэш и
# сразу переносим ветку на этот новый коммит (по сути fast-forward)
git switch -C feature $(git commit-tree HEAD^{tree} -p feature -p origin/main -m "Merged branch 'main' into 'feature'")
# обычный пуш без форса
git push origin featureВ общем я использовал тот же прием, про который писал на Хабре тут и тут.
вы знаете - это гениальный трюк! и, пожалуй, именно то, что я хотел: совершить feature -> main, а потом притвориться, что это был main -> feature. и без форса.
в комментариях к вашим статьям люди писали, что не понимают, зачем нужно спускаться к низкоуровневым гит-командам, но вот живой пример, где commit-tree решает плохо решаемую задачу.
так же спасибо, что указали на упущенный мной git merge --quit - я поправлю статью
Если в ветке понятное небольшое количество коммитов, я бы сделал просто новую ветку, черри-пиком забрал в неё нужные коммиты, удалил бы старую ветку и запушил новую на её место. Правда тут нужно действовать крайне осторожно, чтобы ничего не потерять случайно.
Хочу высказаться про rebase.
В данном случае rebase не является решением, просто потому, что мешать rebase-flow и merge-flow - плохая идея и ребейзить ветку с десятком мержей в неё существенно больнее (и опаснее) чем просто подождать пару часиков на два git checkout'а (т.к. придётся перемерживать все конфликты).
Но последний пункт "git rebase это сложно" является вариацией "git это сложно", который часто можно услышать в геймдеве, и зачастую говорит о проблемах с организацией процесса в студии. Можно использовать как маркер при собеседовании - если на вопрос "git rebase-flow или merge-flow" вам пассивно-агрессивно отвечают что-то в духе "попробуйте обучить художника гиту" или "куа будет делать git pull и всё сломается" - то технологический уровень студии, скорее всего, будет крайне низкий. Типа там ревью в слаке скриншотами, отсутствие ci/cd, скомпиленные бинари в репозитории и прочие радости.
git как самостоятельный инструмент применим только программистами и нужен только программистам. Художники и куа вообще не должны трогать комманду git (или любой другой VCS) - им не нужно 99.9% его функционала. Им нужно делать специальные тулы:
Для левел-дизайнеров, гейм-дизайнеров и т.п. обычно какой-то интерфейс встроенный в редактор, который позволяет отсматривать изменённые ассеты, а не индивидуальные файлы (которых может быть очень много и непонятных).
Для художников работу с VCS обычно встраивают в экспорт-пайплайн. Ну и там гит вообще не особо нужен/применим, проще сразу в s3/сетевую шару кидать и лочить файлы.
Обычный qa, который не собирает проект, качает билды со стима и/или с CI/CD - различных хранилищ артефактов и скачивалок с них вагон. У того же эпика есть Horde с UGS и Toolbox.
Техкуа, который собирает проект, пользуется гитом, но не локальными ветками.
git fetch origin; git checkout remote/branch. И никаких проблем сgit pull. Но даже тут проще сделать простенький гуи из двух с половиной кнопок, который автоматизирует этот процесс.
Проблемы обычно исходят из того, что VCS используют как универсальное файлохранилище с версионированием, вместо того чтобы использовать правильные инструменты для конкретных задач.
А так автору можно только и посочувствовать и порадоваться. В гите хотя бы есть обходные пути, если очень надо. Временное отключение lfs - самое простое. С p4 только "два часа ждать" без вариантов.
Спасибо за большой обстоятельный комментарий! Он несет собой истину и описывает то, как действительно должно быть. Я бы, правда, признал, что все таки компании с низким технологическим уровнем-таки существуют, и они не обязательно плохие или отсталые: это может быть и небольшой размер студии без неограниченного бюджета; и исторически сложившиеся пайплайны, которые пока не смогли сменить, потому что на середине проекта делать такие маневры может быть губительно. Да и сама технологическая отсталось - вещь неоднородная: что-то может быть сделано по уму, а где-то откровенно плохо.
С p4 нам тоже приходится сталкиваться помимо git, так что и его нюансы нам в какой-то степени приходится учитывать, так что спасибо за всестороннее сочувствие :)
Git: проблема длинного прыжка