Привет. Пытаюсь разобраться с тем, каким образом можно при групповой

разработке избежать одновременных изменений в одном и том же файле? Мне интересно понять, существуют какие-либо возможности блокировки файла? Просто если допустим несколько человек внесут свои правки в код, а другой вообще захотел вдруг просто рефакторинг сделать, как сводить концы с концами? Садить какого-то менеджера который бы мониторил все изменения и решал что нужно объединить в мейн? Даже если так, то как ему понять что нужно объединять и тд? Регулярно по таким вопросам собирать консилиум из чуваков которые вносили изменения в этот файл? Я только пытаюсь вкуривать как работать с гитом при групповой разработке. В соло мне все ясно

Не надо с этим разбираться, коллективная работа предполагает конфликты.

То есть необходимо регулярные согласования и условная привязка в джире как задача по модулю?

Нет

Конфликт возникает при мерже таски в dev или мастер бранч, тогда и разруливайте. Какой у вас flow?

Каждая задача отдельная ветка

Да, но как вы релиз готовите, как тестируете?

Причем тут гит? Это больше процессы разработки и они внезапно разные со своими плюсами и минусами

Поэтому я спросил про flow.

Если регулярно требуется разрешать сложные конфликты, то это первый звоночек сменить компанию. Конфликты в файлах конфига, импорты в модулях и подобное нормально, но если 2-3 и больше разработчиков делают одну и ту же работу или отсутствует модульность и все пишут в 1 файл, то процессом разработки явно что-то не то.

Существуют разные flow Многие думают что git flow silver bullet но мой опыт говорит что это нужно далеко не всем Существует например github flow более простой и гибкий

Они не регулярно, мы пока просто хотим использовать гит в команде, и встал вопрос который я задал в начале, типа а вот что если. Ну смысл то я понимаю, что таких конфликтов не должно возникать если правильно выстроить процессы))

Нет они возникают И решаются человеком что вливает общением с автором другова комита После разрешение конфликта ставить надо в ревью автора прошлых строк

А как вы сейчас без гита разруливаете конфликтные ситуации?

У нас есть встроенное хранилище версий которое использует блокировки. Я захватываю какой-либо модуль и вношу изменения. Отпускаю изменения помещаются в хранилище, а затем если следующий разработчик захочет внести изменения он либо столкнется с блокировкой либо, получит те изменения что вносил я. Ну и оно работает по принципу единой ветки без возможности разветвления и тд. Очень громоздкая штука и работать с ней затруднительно в плане просмотра каких-либо версий, сравнений))

Хм, ну буду знать теперь 😄

А в команде есть кто-нибудь, кто в гите шарит? Если таких нет, то внедрение и использование гита с нуля будет болью. Может не надо? Или может хотите прочесть книжку по гиту и стать таким человеком?

Работает над этим, пока просто изучаем как с ним работать, ветвление, сравнение истории, объединение и тд , мы не сразу планируем перейти типа раз с сегодняшнего дня будем работать с гитом. А пока ну только я больше всех разбираюсь как в целом он устроен и что можно делать. Пару тестов провели только. Пока очень понравилось в плане скорости работы с гитом.

Попробуйте тогда для тестов поделать мерж-конфликтные ситуации и порезолвить их трехсторонними резолверами. Типа как вы выше описывали. А потом команду научить.

А мы пробовали делать изменения в одном и том же файле и пушили, система не давала второму разработчику их отправлять до тех пор пока он не решит конфликт, ему нужно было сначала получить мои изменения, объединить и потом уже можно было это отправлять

Если это научились, то осталось про модели ветвления чекнуть. И как сказали выше, НЕ используйте “git flow”, а присмотритесь к любому другому ветвлению

Можно какой-нибудь пример? Или как загуглить?)

В гите есть несколько популярных. Тот же ”github flow”, так можете и загуглить. Или поищите просто какие-нибудь обзорные статьи про них. Только “git flow” не используйте. Чем более простое ветвление у вас в итоге будет, тем лучше.

Ну мы вот планировали оставить только ветку мейн и от нее ветвить задачи а потом просто сливать по завершению. Ну это как по мне такой простой вариант ветвления

А продумали, как будете релизы делать? И, к слову, насколько большие у вас обычно фичи?

Нет, пока еще не думали над релизами, наверно до этого дойдем по завершению продумывания всего процесса разработки. А фичи ну как правило они не большие, бывают конечно крупные и по времени могут занимать неделю-две. Но это редко такое

Норм 👍

> Садить какого-то менеджера Организационные проблемы технически не решаются (с) Разумеется, если как-то не договорились между собой (например, где чья зона ответственности, но есть и другие варианты), то менеджер - один из вариантов. Иначе да, придется бороться с техническими средствами, потому что они всего лишь инструмент, и в телепатию не умеют.

Я слышал, что иногда даже резолвить мерж-конфликты сажают одного человека.

Я про это читал просто

Не, обычно так не делают, каждый сам резолвит мерж-конфликты, с которыми сталкивается. Если это бы делал отдельный человек, то он стал бы незаменимым с бас-фактором 1.

Ну да, да и такому человеку сходу сложно понять, че тут надо че не надо и регулярный консилиум такое себе решение ну по крайней мере я так представляю такую работу 🤷🏼‍♂️