Git. Система контроля версий
В этом видеооуроке мы рассмотрим такую важную тему в системе контроля версия как ветки, ветвления и какие преимущества это нам дает.
Итак у нас есть репозиторий и по-умолчанию в Git-е основная ветка master.
Мы ведем разработку в этой ветке. Периодически выполняем коммиты. И уже какой-то функционал у нас есть на боевом сервере. И допустим заказчик хочет разработать новый (или переделать старый) функционал. Допустим переделать логику платежных систем. Платежные системы у нас уже есть на сайте. И исправно работают. Заказчик хочет совсем иную логику работы. Процесс реализации трудоемкий и достаточно длителен по времени. А между тем идет разработка над другими фишками которых много и которые достаточно быстро реализовываются и их надо периодически переносить на боевой сервер.
То есть мы не можем параллельно в одной ветке осуществлять работу и над текущими задачами и над новой. Так как выкатывая текущине, небольшие задачи мы тем самым выкатим новый, не доработанный функционал новых платежных систем.
Эту проблему мы можем решить с помощью веток - branches. Как это работает?
Мы создаем новую ветку от последнего стабильного коммита. И даем ей имя. Например "new_feature".
Программист который будет реализовывать задачу новых платежных систем будет работать в новой ветке.
А остальная команда в ветке master.
Наступил тот день когда работа над веткой new_feature закончена. И на текущий момент ветка master достаточно сильно обросла новым функционалом которого нет в new_feature (и наоборот соответственно). Осталось дело за малым - сделать так чтобы в ветке мастер оказался весь новый функционал из ветки new_feature. И уже после этого (и после тестирования) выкатить всю проделанную работу на боевой сервер.
Разработчик который работал над новым функционалом в ветке new_feature делает merge (осуществляет слияние) своей ветки с веткой мастер. Устраняет конфликты если таковые были, проводит тестирование. После этого ветка new_feature у нас содержит весь новый функционал который был в ветке master. Затем разработчик переходит в ветку мастер и уже в нее заливает ветку new_feature. Данное слияние уже произойдет без конфликтов. И как результат мы получим в ветке мастер новый функционал платежных систем.
Возможно кому-то из вас покажется что мы сделали лишние манипуляции и можно было бы сразу ветку new_feature заливать в master. Но если вы хотите более безопасно разрешить конфликты, то лучше сделать как было описано выше. Так как конфликты могут иметь место. Так же может получиться что Git сам разрешит некоторые конфликты, но разрешит их не верно и будут баги. Их можно будет безопасно исправить в ветке new_feature и уже без косяков залить все в мастер.
Более подробно и "на пальцах" смотрите в видео. Так же из видео узнаете как делать так называетмые хотфиксы.
