Всем привет, может кто встречал какой нибудь показательный материал который воспроизводит процесс разработки с гитом.
Интересует именно "показательная боевая" разработка, которая эмулирует или воспроизводит то, как хорошие разработчики структурируют ветки, как убирают лишние коммиты(оставляя только ключевые), в каких случаях причищают гит, какие ветки от каких наследуют, показывают воркфлоу который не вызывает боль в глазах когда смотришь на репозиторий джуна.
Сейчас вся разработка гита состоит из:
master -> prod
dev -> dev
От дев под каждый компонент создается ветка, которая потом мержится в дев, и после тестов сливается в мастер.
Проблема в том, что при разработке чего либо, нахожу много ошибок, которые сразу начинаю дебажить и убирать, в итоге через час имею полотно из коммитов вроде - delete old styles in "any component", "changing the behavior logic of the add text component"
В итоге всё в куче. И всё запутывается. Интересно было бы поглядеть как пишут и документируют свою работу профессионалы.
От дев под каждый компонент создается ветка, которая потом мержится в дев, и после тестов сливается в мастер.
Проблема в том, что при разработке чего либо, нахожу много ошибок, которые сразу начинаю дебажить и ...
Не сливайте feature-ветку пока она не будет полностью протестирована и code-rewiew'ирована.
Склеивайте комиты в feature-ветке, чтобы их в итоге было не больше 1-3.
Из собственного опыта могу сказать, что чем крупнее и неспешнее проект - тем проще следовать git-flow.
А вот когда 1-2 разработчика и нужно вот сейчас ещё вчера запилить 10 фич... бывает сложновато.
Это вопрос дисциплины и организованности. Как ставятся задачи, как вы фокусируетесь на текущей фиче (нельзя носиться по всему проекту и фиксить по пути всё что под руку попалось). Организации самого проекта в конце концов - как изолированы компоненты и т.д.
Можно делать аmend если сделали commit потом внесли какие то изменения и хотите чтобы они попали в последний commit. Если commits несколько можно сделать squash commits т.e. из 5 сделать один.
Лично я обычно поступаю следующим образом. Отвожу ветку от dev например dev_new_1 творю там любую дичь хоть 20 commits с идиотскими названиями. Когда понимаю что задача готова отвожу из последней версии dev свежую ветку допустим dev_new_2 в данный момент она равна dev
Далее
git checkout dev_new_2
git merge --squash dev_new_1
Смотрите что там все ваши изменения и проверяете еще раз
git commit -m 'merged dev_new_1'
Получается ветка со всеми вашими изменениями и одним commit.
Эту ветку уже выставляю на pull request
А за портянку из мусорных commits в серьезной конторе действительно могут побить :)
Посмотри пару видяшек в ютубе о git-flow и зачем он нужен.
Буквально 2-3 примера разных флоу будет достаточно для ознакомления с преимуществами каждой. А дальше мутишь в своем проекте под свои нужды.
Кому-то нужно CI/CD прямо в продакшен каждый раз как закоммитил. Кому-то нужны коробочные релизы раз в полгода. Кому-то нужны простые регулярные релизы, но при этом распределенная команда из 100 разработчиков 300 тестеров, которые работают в разные спринты, и пока один релиз тестят, другой уже разрабатывают.
Но это не курс по git, а именно по git-flow (или другими словами настройка code-review/ci/cd процессов).
Например, если у вас CI с автоматическими тестами не настроен, то мерж любой фича ветки может ломать develop/master ветку. А CI это уже вообще не гит.
