Как правильно коллективно производить разработку?

Как правильно коллективно производить разработку?

Пять человек, а стул ОДИН …

как правило per-commit-review вообще невозможно делать

Так и не надо.

адекватно отревьювить большой кусок кода состоящий из 20 комитов почти нереально

Гм. Размер кода не меряется в коммитах. Я тебе могу тот же самый огромный кусок кода в один коммит засунуть, легче тебе от этого не станет.

И сквош во время мерджа всю ету кашу малашу превращает вообще в нечто неуправляемое.

Э-э-э? Ты просил чистую историю — вот тебе чистая история.

Если кто-то сделал дурной PR/CR, в котором чёрт ногу сломит, то это не связано с герритом/гитхабом.

А то любят от джунов +1 нахвататься и все по-быстрому померджить а потом весь следующий день ревертить...

По-моему, у вас там в команде проблема не с центральным репозиторием, а с девелоперами.

Ваша руский терминология хромой.

Мне глубоко плевать на терминологию, мне интересна суть. А суть та, что патчсеты по отношению к CR-ам выполняют ровно ту же функцию, что коммиты по отношению к PR-ам. Только в геррите сквошить их обязан юзер, а гитхаб может это сделать сам.

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

Как-то начальник рассказывал такую хохму.
Приходит б-ша и жалуется на то, что она лист Excel настраивает, а он через пол часа становится иным.
Оказалось, что две б-ши правили один и тот же файл одновременно …

как правило per-commit-review вообще невозможно делать

Так и не надо.

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

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

Не-не-не. Я только за то, чтобы ревьюить мелкими частями. Но «мелкими частями» — не значит по одному коммиту. Ты почему-то считаешь, что чем больше коммитов, тем больше кода. Это совершенно не так, я видел, как PR с добавлением новых коммитов уменьшался.

А когда зарплата?

Во сне.

Не зарплата, а распределение доходов, готовый софт лицензируем/продаём/поддерживаем и число людей в комнате N, весь доход $, общий счёт для общих нужд X. На руки = ((($/N) / 100) * 90); Общий счёт на железо, хавчик, соки и прочее X = ((($/N) / 100) * 10) * N.

Все по Марксу, кооператив.

Опять какой то Маркс у меня идею спёр!

Не надо советовать ребейз для коллективной разработки. Он дальше локального репозитория не должен применяться

Он дальше локального репозитория не должен применяться

Он там и применяется

разрабатывает фичу в локальной ветке, потом она проходит code review и ребейзится в мастер

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

лично мои требования в командной разработке сводятся к двум вещам - в своих клонах разрабы могут делать все что угодно и как угодно, но MR/PR должен быть одним куском. и второе - никогда, ни при каких условиях, на основном гите не должны делаться ребейзы.