Allegro75
@Allegro75
SummaryTables.ru - сайт с футбольной статистикой

Создать новую ветку, правильно ли я себе представляю, что нужно делать?

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

Типовая ситуация на работе.
Есть главная ветка master; есть моя ветка разработки под названием, скажем, dev.

У меня есть некое задание, я начинаю работу по нему в ветке dev - работаю над каким-то блоком кода А. В процессе работы мои изменения как-то ломают наше приложение, наш продукт - но нестрашно, я ж пока отлаживаю, я в процессе, всё норм.
Тут прибегает начальник и говорит, что нужно срочно изменить что-то ещё, какой-то блок кода B.

Я (оставаясь в ветке dev) начинаю лихорадочно комментировать или ещё как-то обезвреживать изменения в блоке кода А - чтоб восстановилась работа продукта. Потом вношу требуемые изменения в блок кода B. Потом все дела, гит пуш, и можно возвращаться к блоку коду А.

Интуиция подсказывает. что это неправильный способ жить, и на самом деле надо создавать некую третью ветку, назовём её fast, которая отпочковывалась бы непосредственно от master (т.е. в ней отсутствовали бы те поломки, которые я внёс в блок кода А).
Потом работаем в fast, коммит-пуш, вернулись к dev, работаем над блоком кода А дальше.

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

(dev)
1. git add, git commit
(Сразу возникает вопрос, а надо ли это, ведь у меня пока не готов мой блок А. Но вроде git как-то протестует, если уходить из ветки, не закоммитив)

(dev)
2. git checkout master

(master)
3. git checkout -b fast
(Создаю fast. Именно так надо, с '-b'?)

Поработали на fast, сделали блок кода B.
(fast)
4. git add, git commit, git checkout master

(master)
5. git pull
(Здесь нам могут ещё прилететь изменения в мастер с удалённого репозитория)

(master)
6. git merge fast, git push

(master)
7. git checkout dev

(dev)
8. git rebase master
(Тут я вообще не уверен, так и надо? Мой коммит из пункта 1 тут корректно сольётся с моими изменениями из fast плюс возможными изменениями из пункта 5 (исходим из того, что конфликтов там нет)?)
  • Вопрос задан
  • 98 просмотров
Решения вопроса 3
firedragon
@firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
https://www.atlassian.com/ru/git/tutorials/saving-...

Временное сохранение кода

После этого делаете ветку на основе dev
Вносите изменения и после теста делаете merge или rebase

После возвращаетесь к сохранённым в начале изменениям
Ответ написан
Комментировать
rozhnev
@rozhnev
Fullstack programmer, DBA, медленно, дорого
Я использую следующий подход:
1. Для каждого задания создается отдельная ветка из мастера. То есть если параллельно в разработке Х заданий - создается Х веток.
2. Если нужно переключиться между заданиями - коммитим текущие изменения и переключаемся (или создаем) на ветку с новым заданием
3. При переключении на ветку задания актуализируемся из мастера
4. При окончании разработки сливаем ветку в QA для тестирования
5. По окончании тестирования сливаем ветку в мастер и удаляем (или нет :) исходную
Ответ написан
sergey-kuznetsov
@sergey-kuznetsov Куратор тега Git
Автоматизатор
Ты в общих чертах описал рабочий процесс git-flow, но rebase там неуместен, синхронизация делается исключительно через merge, так как ветки master и dev долгоиграющие.
Погугли. На эту тему много хороших статей, но не факт что вашей компании такая модель идеально подойдёт.
Такие вопросы решаются до начала разработки обычно, так как схем ветвления можно придумать много и не существует единственно правильной.

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

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

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