Курс или полный гайдлайн по git?

Всем привет, может кто встречал какой нибудь показательный материал который воспроизводит процесс разработки с гитом.

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

Сейчас вся разработка гита состоит из:

master -> prod
dev -> dev

От дев под каждый компонент создается ветка, которая потом мержится в дев, и после тестов сливается в мастер.
Проблема в том, что при разработке чего либо, нахожу много ошибок, которые сразу начинаю дебажить и убирать, в итоге через час имею полотно из коммитов вроде - delete old styles in "any component", "changing the behavior logic of the add text component"

В итоге всё в куче. И всё запутывается. Интересно было бы поглядеть как пишут и документируют свою работу профессионалы.
  • Вопрос задан
  • 1743 просмотра
Решения вопроса 5
andrhohlov
@andrhohlov
Ищем front-end dev'а https://hohlov.pro/fe.html
Попробуйте следовать https://www.atlassian.com/ru/git/tutorials/compari...

К проблеме которую вы описали:

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


Не сливайте feature-ветку пока она не будет полностью протестирована и code-rewiew'ирована.
Склеивайте комиты в feature-ветке, чтобы их в итоге было не больше 1-3.

Из собственного опыта могу сказать, что чем крупнее и неспешнее проект - тем проще следовать git-flow.
А вот когда 1-2 разработчика и нужно вот сейчас ещё вчера запилить 10 фич... бывает сложновато.

Это вопрос дисциплины и организованности. Как ставятся задачи, как вы фокусируетесь на текущей фиче (нельзя носиться по всему проекту и фиксить по пути всё что под руку попалось). Организации самого проекта в конце концов - как изолированы компоненты и т.д.
Ответ написан
@iMaximus
Можно делать а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 в серьезной конторе действительно могут побить :)
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Посмотри пару видяшек в ютубе о git-flow и зачем он нужен.

Буквально 2-3 примера разных флоу будет достаточно для ознакомления с преимуществами каждой. А дальше мутишь в своем проекте под свои нужды.

Кому-то нужно CI/CD прямо в продакшен каждый раз как закоммитил. Кому-то нужны коробочные релизы раз в полгода. Кому-то нужны простые регулярные релизы, но при этом распределенная команда из 100 разработчиков 300 тестеров, которые работают в разные спринты, и пока один релиз тестят, другой уже разрабатывают.

Но это не курс по git, а именно по git-flow (или другими словами настройка code-review/ci/cd процессов).

Например, если у вас CI с автоматическими тестами не настроен, то мерж любой фича ветки может ломать develop/master ветку. А CI это уже вообще не гит.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы