Да, все верно прямо готового решения нет, поэтому стараемся вести разработку и работу в ветках так, чтобы изменений одного и того же ассета в разных ветках не было. Тут как раз Trunk-Based development подход очень сильно помогает нам жить.
Я должен извиниться за не совсем корректную формулировку у себя в статье. Ввиду того что в большинстве случаев после коммита следует push, речь именно о нем и шла, а не сколько о самой операции commit, да, я понимаю, что все работают по-разному, сам зачастую делаю множество коммитов и только потом их пушу, поэтому и извиняюсь что не совсем точно указал саму точку хука.
Сейчас мы используем клиентский pre-push hook, это не лучшее решение, над улучшением которого мы работаем, основная проблема в том, что pre-push не гарантирует доставку данных на сервер и бывают случаи, когда локи снимаются прежде временно.
Сразу же процитирую сам себя: "У нас внутри работают независимые друг от друга команды, у каждой из которых есть своя история, свой опыт и набитые шишки, а соответственно, и свои стандарты."
И тут все дело обстоит точно также, поэтому расскажу именно за опыт своей команды: - При работе с ветками у нас принята Trunk-Based development модель, но со своими допущениями, например некоторые фиче-ветки могут жить больше 2–3 дней, над этим мы пока что работаем. - По причине того, что мы используем File Locking (часть Git LFS) у нас, очень редко возникает необходимость "мерджа" ассетов, потому что это как никак бинарные файлы, которые конфликтят и резолв таких конфликт как правило ой как больно обходится. - Что касаемо Data Assets, то тут мы идем по пути парсеров, все DA которые используются нами, могут парсится в тот же самый json (json — это как пример, тип данных может отличаться в зависимости от задачи и места использования), и сами исходные json'ы мы уже и храним в репе и их собственно в случае чего и мерджим. - В случае работы с картами то мы придерживаемся разделению на множество необходимых sublevel's, что помогает нам избежать конфликтов - В случае если уже конфликт возник, то пробуем решить его встроенным в UE solver'ом, но честно говоря за счет локов, Trunk-Based development модели и правильного планирования у нас очень редко возникают конфликты ассетов.
Привет! Я хоть в рекрутменте и не работаю, но все таки заинтересован в том чтобы подобные ситуации не происходили, если тебе не сложно напиши мне в ЛС подробности твоей ситуации, а я уже дальше попробую сделать все что в моих силах чтобы подобных ситуаций больше не было!
Привет, поставлю плюсик у DDC. А с Perforce могу пожелать только лишь терпения, помню как в свое время тоже переезжал после N-лет работы с Git на Perforce, но спустя примерно месяц уже адаптировался.
Тут только лишь время и терпение на адаптацию к другой технологии вам поможет! А в остальном ничего сложного.
Привет!
На этот счет советую посмотреть Fantastic Bottlenecks and Where to Find Them на YouTube, там хоть и немного, но отражает саму суть.
Привет!
Да, все верно прямо готового решения нет, поэтому стараемся вести разработку и работу в ветках так, чтобы изменений одного и того же ассета в разных ветках не было.
Тут как раз Trunk-Based development подход очень сильно помогает нам жить.
Я должен извиниться за не совсем корректную формулировку у себя в статье. Ввиду того что в большинстве случаев после коммита следует push, речь именно о нем и шла, а не сколько о самой операции commit, да, я понимаю, что все работают по-разному, сам зачастую делаю множество коммитов и только потом их пушу, поэтому и извиняюсь что не совсем точно указал саму точку хука.
Сейчас мы используем клиентский pre-push hook, это не лучшее решение, над улучшением которого мы работаем, основная проблема в том, что pre-push не гарантирует доставку данных на сервер и бывают случаи, когда локи снимаются прежде временно.
Сразу же процитирую сам себя:
"У нас внутри работают независимые друг от друга команды, у каждой из которых есть своя история, свой опыт и набитые шишки, а соответственно, и свои стандарты."
И тут все дело обстоит точно также, поэтому расскажу именно за опыт своей команды:
- При работе с ветками у нас принята Trunk-Based development модель, но со своими допущениями, например некоторые фиче-ветки могут жить больше 2–3 дней, над этим мы пока что работаем.
- По причине того, что мы используем File Locking (часть Git LFS) у нас, очень редко возникает необходимость "мерджа" ассетов, потому что это как никак бинарные файлы, которые конфликтят и резолв таких конфликт как правило ой как больно обходится.
- Что касаемо Data Assets, то тут мы идем по пути парсеров, все DA которые используются нами, могут парсится в тот же самый json (json — это как пример, тип данных может отличаться в зависимости от задачи и места использования), и сами исходные json'ы мы уже и храним в репе и их собственно в случае чего и мерджим.
- В случае работы с картами то мы придерживаемся разделению на множество необходимых sublevel's, что помогает нам избежать конфликтов
- В случае если уже конфликт возник, то пробуем решить его встроенным в UE solver'ом, но честно говоря за счет локов, Trunk-Based development модели и правильного планирования у нас очень редко возникают конфликты ассетов.
Привет!
Я хоть в рекрутменте и не работаю, но все таки заинтересован в том чтобы подобные ситуации не происходили, если тебе не сложно напиши мне в ЛС подробности твоей ситуации, а я уже дальше попробую сделать все что в моих силах чтобы подобных ситуаций больше не было!
Привет, поставлю плюсик у DDC.
А с Perforce могу пожелать только лишь терпения, помню как в свое время тоже переезжал после N-лет работы с Git на Perforce, но спустя примерно месяц уже адаптировался.
Тут только лишь время и терпение на адаптацию к другой технологии вам поможет! А в остальном ничего сложного.