20:07
Как не закоммитить хуйню
Если над проектом работает много людей и все собирают проект у себя -- или централизованно -- то проблемы, которую я опишу ниже, скорее всего не будет.
А вот если программу пишет один человек, а к нему иногда подключается второй?
И вот я этот самый второй. Собираю проект. "Файл не найден".
*пингвин кланяется*
Когда собираешь проект только у себя и иногда коммитишь, то можешь не знать, что твои коммиты нерабочие. У тебя-то всё работает. И будет работать. А что ты файл какой-нибудь добавить забыл -- это ерунда. Я сам так попадался неоднократно.
Можно быть сколько угодно раз внимательным, но иногда такое будет происходить.
А чтобы такого не было -- надо всегда собирать проект по крайней мере на ещё одной машине, стянув изменения из репозитория.
А вот если программу пишет один человек, а к нему иногда подключается второй?
И вот я этот самый второй. Собираю проект. "Файл не найден".
*пингвин кланяется*
Когда собираешь проект только у себя и иногда коммитишь, то можешь не знать, что твои коммиты нерабочие. У тебя-то всё работает. И будет работать. А что ты файл какой-нибудь добавить забыл -- это ерунда. Я сам так попадался неоднократно.
Можно быть сколько угодно раз внимательным, но иногда такое будет происходить.
А чтобы такого не было -- надо всегда собирать проект по крайней мере на ещё одной машине, стянув изменения из репозитория.
18.12.2023 в 20:21
А лучше сразу настроить ci\cd)
19.12.2023 в 12:15
22.12.2023 в 15:43
22.12.2023 в 16:01
22.12.2023 в 22:54
23.12.2023 в 09:20
Кроме того, во время подготовки мержа я ещё раз просматриваю диффы и частенько замечаю ошибки или места, которые хочу улучшить.
25.12.2023 в 05:07
а это зачем?
ты ж удаляешь историю из гита
не смог перебороть старые привычки из SVN ? )))
в репе должна быть только одна ветка ))))
25.12.2023 в 05:42
Я использую что-то вроде github flow: habr.com/ru/articles/346066/
Каждый мерж - какая-то отдельная решенная проблема, которая превращается в один коммит в мастере. При этом в процессе подготовки мерж-реквеста делается 100500 коммитов, а общий дифф и результаты тестов я смотрю уже в гитлабе.
25.12.2023 в 15:34
да, в мастере каждый мёрж-коммит - это решение проблемы, которое было построено длинной цепочкой коммитов в боковой ветке
но сквашить-то зачем? пусть остаётся история, она хранит ценные комменты коммитов, поясняющие что там было сделано, и удалять их - грех
общий дифф ты всегда можешь посмотреть по мёрж-коммиту, сквашить для этого не нужно
я люблю gitflow, он хорош тем, что есть общее рабочее develop-окружение, у нас на нём работает фронт, бэк и БД, и всё это постоянно доступно
а в githubflow такого нет - там только прод, а где песочница?
25.12.2023 в 16:46
25.12.2023 в 16:53
> а в githubflow такого нет - там только прод, а где песочница?
В моём понимании, разработка отдельно, прод отдельно. Т.е. есть проект самого софта - там сборки и тесты (цель: собрать новую версию и залить в реп). А есть проект прода - там контейнеры, базы, фронт и бэк (цель: выкатить новую версию из репа на боевые сервера).
Ничто не мешает в одном проекте использовать github flow, а в другом another flow.
26.12.2023 в 11:06
не понял, как это ты вычеркнул БД из "проект самого софта"
как вообще можно тестировать сборку без БД?
твои изменения в кодовой базе идут вместе с изменениями структуры БД, причём при переходе к новой структуре БД нужно выполнить некоторое заполнение или перемещение данных в этой БД, которое ты описываешь в деплой-скриптах, которые должны применяться одновременно с изменением кодовой базы.
короче, неизбежно всё это идёт в одном мёрж-коммите: и код, и скрипты БД
но в целом понятно: ты используешь гитхабфлоу как урезанный гитфлоу, у которого удалена прод-ветка
проблема, которая остаётся - как пронести в релиз только то что хочешь, а не вообще всё что накопилось в репе
в гитфлоу для этого добавлена возможность выборочного переноса доработок между ветками девелоп и тест (тест уходит в прод-ветку) в течение подготовки релиза
а в гитхабфлоу - никак. жри что дают )))
Начали обсуждение с "если программу пишет один человек, а к нему иногда подключается второй?" и докатились до девелоп-окружений и песочниц)
весь гит - это и есть решение проблемы участия двух человек в одном проекте
Мой типичный мерж-реквест состоит из одного жирного коммита
а вот за жирные коммиты нужно наказывать, потому что это затрудняет понимание другими участниками что ты там сделал
посмотри известные опенсорс-репы - там каждая отдельная по смыслу мелкая задача занимает 1 коммит.
1 коммит никогда не решает 2 задачи одновременно
это сходно по смыслу с разделением методов у ООП-объекта: 1 метод решает только одну задачу