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

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

  

Типовая ситуация на работе.  

Есть главная ветка **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 (исходим из того, что конфликтов там нет)?) 

[https://www.atlassian.com/ru/git/tutorials/saving-...](https://www.atlassian.com/ru/git/tutorials/saving-changes/git-stash)  

  

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

  

После этого делаете ветку на основе dev  

Вносите изменения и после теста делаете merge или rebase   

  

После возвращаетесь к сохранённым в начале изменениям 

 Я использую следующий подход:  

1. Для каждого задания создается отдельная ветка из мастера. То есть если параллельно в разработке Х заданий - создается Х веток.  

2. Если нужно переключиться между заданиями - коммитим текущие изменения и переключаемся (или создаем) на ветку с новым заданием  

3. При переключении на ветку задания актуализируемся из мастера  

4. При окончании разработки сливаем ветку в QA для тестирования  

5. По окончании тестирования сливаем ветку в мастер и удаляем (или нет :) исходную 

 Ты в общих чертах описал рабочий процесс [git-flow](http://danielkummer.github.io/git-flow-cheatsheet/index.ru_RU.html), но rebase там неуместен, синхронизация делается исключительно через merge, так как ветки master и dev долгоиграющие.  

Погугли. На эту тему много хороших [статей](https://bitworks.software/2019-03-12-gitflow-workflow.html), но не факт что вашей компании такая модель идеально подойдёт.  

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

  

А судя про то, что пишешь про комментирование кода чтобы временно скрыть и про перебазирование для синхронизации — ты похоже не понимаешь зачем нужен и как работает Git.   

Почитай [документацию](https://git-scm.com/book/ru/v2) или посмотри [Git-курс](https://www.youtube.com/playlist?list=PLDyvV36pndZFHXjXuwA_NywNrVQO0aQqb)  на Ютубе.