Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Вы решаете, что теперь вы будете заниматься задачей № 53 из вашей системы проектирования. Вы создаёте ветку feature/53 и сразу переключаетесь на неё командой .
Вы работаете над новой функциональностью и фиксируете изменения. Это приводит к тому, что ветка feature/53 движется вперед, так как вы переключились на нее ранее (HEAD указывает на нее).
Тут вы получаете сообщение об обнаружении критической ошибки, которую нужно немедленно устранить.
Благодаря Git'у не требуется размещать это исправление вместе с тем, что вы сделали в feature/53. Вам даже не придётся прилагать усилий, чтобы откатить все эти изменения для начала работы над исправлением. Все, что вам нужно, это переключиться на ветку master.
Но перед тем как сделать это имейте в виду, что если ваш рабочий каталог, либо область подготовленных файлов, содержат изменения, не попавшие в коммит и конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит вам переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (спрятать изменения или исправить коммиты), но об этом мы поговорим позже в главе Прятанье и очистка. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на основную ветку.
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над задачей № 53. Теперь вы можете сосредоточиться на работе над исправлением.
Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последней фиксации изменений в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда были зафиксированы последние изменения.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку bugfix/135 для исправления, в которой будем работать, пока не закончим исправление критической ошибки.
Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так, выполнить слияние с основной веткой для включения в продукт.
Для этого вам сначала нужно переключиться на основную ветку master, а затем выполнить .
В результате вы получите следующее информационное сообщение.
А история коммитов будет выглядеть у вас следующим образом.
Вы заметили фразу «перемотка вперёд» (Fast-forward) в информационном сообщении? Из-за того, что коммит, на который указывала ветка, которую вы слили, был прямым потомком того коммита, на котором вы находились, Git просто переместил указатель ветки вперед. Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории прямо, Git упрощает слияние, просто перенося указатель метки вперед (так как нет разветвления в работе). Это называется перемотка вперед (fast-forward) . Теперь ваши изменения находятся в снимке коммита, на который указывает ветка master, и исправления конфигурации можно внедрять.
После внедрения вашего критического исправления вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку bugfix/135, потому что она больше не нужна, ведь ветка master указывает на то же самое место.
Для удаления ветки в панели Навигатор выполните контекстную команду . При этом установите флажок Удалить информационную базу ..., т. к. эта база вам больше не понадобится.
После нажатия Готово ваша история будет выглядеть следующим образом:
Теперь вы можете переключить ветку и вернуться к работе над своей задачей № 53.
Стоит обратить внимание на то, что все изменения из ветки bugfix/135 не включены в вашу ветку feature/53. Если их нужно включить, вы можете влить ветку master в вашу ветку feature/53 командой , или же вы можете отложить слияние этих изменений до завершения работы и затем переключиться на ветку master и влить ветку feature/53 в master.