Создать новую ветку, правильно ли я себе представляю, что нужно делать?
Прошу прощения, вопрос, видимо, элементарный. Но человек я неопытный, нужно подтверждение, что я понимаю дело верно.
Типовая ситуация на работе.
Есть главная ветка 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 (исходим из того, что конфликтов там нет)?)
Я использую следующий подход:
1. Для каждого задания создается отдельная ветка из мастера. То есть если параллельно в разработке Х заданий - создается Х веток.
2. Если нужно переключиться между заданиями - коммитим текущие изменения и переключаемся (или создаем) на ветку с новым заданием
3. При переключении на ветку задания актуализируемся из мастера
4. При окончании разработки сливаем ветку в QA для тестирования
5. По окончании тестирования сливаем ветку в мастер и удаляем (или нет :) исходную
Спасибо, правильно ли я понимаю, что описанный подход примерно совпадает с моей процедурой?
Отмечу, что у нас компания мелкая, специального этапа тестирования нет: написал код, сам как-то протестировал - и пушишь сразу в бой.
Ты в общих чертах описал рабочий процесс git-flow, но rebase там неуместен, синхронизация делается исключительно через merge, так как ветки master и dev долгоиграющие.
Погугли. На эту тему много хороших статей, но не факт что вашей компании такая модель идеально подойдёт.
Такие вопросы решаются до начала разработки обычно, так как схем ветвления можно придумать много и не существует единственно правильной.
А судя про то, что пишешь про комментирование кода чтобы временно скрыть и про перебазирование для синхронизации — ты похоже не понимаешь зачем нужен и как работает Git.
Почитай документацию или посмотри Git-курс на Ютубе.
Спасибо.
Почитал я пару статей по ссылкам, и, по-моему, у нас не git-flow.
У нас устроено так, что есть главная ветка master, и есть ветки разработчиков - например, моя, которую я вообще-то назвал даже в честь себя oleg (а не dev).
Мою ветку oleg никто не видит, кроме меня (а в git-flow, насколько я понял, предполагается, что все видят вторую ветку dev).
Сейчас я работаю так: корплю над самыми разными текущими задачами в своём этом oleg'e - когда решаю задачу - мерджу oleg в master. Потом пушу этот master в удалённое хранилище. (Там потом надо ещё зайти с паролем и сделать git pull, но я не знаю, насколько это стандартная процедура).
Да, и в начале работы, я должен на мастере git pull, потом на своём oleg'e git rebase master.
Так меня научили старшие коллеги, это не я придумал.
Имени нет, но схема рабочая.
Тогда твой алгоритм правильный. Возможно есть слегка непонимание того, что именно происходит. Рекомендую пройтись по плейлисту по ссылке на ютубе. Особенно про ветки.
Не бойся коммитить в свою ветку, ничего страшного не произойдёт. Ты же всегда потом сможешь причесать коммиты перед слиянием в мастер и отправкой наверх.
Перебазировать свою тематическую ветку на актуальный мастер это тоже нормальная практика. Сам так делаю.
И ты не обязан работать в одной ветке. Можешь отпочковать себе хоть сколько веток под эксперименты с кодом.
3. git checkout -b fast
(Создаю fast. Именно так надо, с '-b'?)
Ты объединил две операции в одну, поэтому тут важен ключ указывающий что ветку нужно ещё и создать перед переключением на неё.
по факту твоя команда делает две вещи
git branch fast — создать
git checkout fast — переключиться
без предварительного создания (или без -b) некуда будет переключиться.
