Предыдущий ролик Следующий ролик  

Видео урок: Ветвление и слияние

Принципы контроля версий

Одна из наиболее полезных функций ПО контроля версий - это ветвление (бранчинг). Но в то же время она является и наиболее сложной. В некоторых централизованных системах процесс слияния бранчей немного запутанный, и некоторым людям трудно его понять, хотя на самом деле ничего сложного в нем нет. Вы начинаете с основного бранча и существующих файлов, затем вы создаете новый бранч, и у вас появляется другой набор файлов, идентичный существующему, которые вы можете изменить. Ветвление означает только то, что вы берете текущее состояние хранилища и создаете его копию.

В новой ветке (в отличие от основного бранча, который также иногда называется стволом) вы можете делать любые изменения, и они не повлияют на уже существующий рабочий продукт. Это отличная "песочница", в которой вы можете экспериментировать и проводить рефакторинг кода. Вы можете удалять старые ненужные функции и добавлять новые. Вы сможете совершенно свободно делать все, что захотите. В нашем примере хранилище содержит файл с функциями A, B и C. Когда вы создадите бранч, вы увидите, что в основном бранче по-прежнему есть функции A, B и C, и такой же и новый бранч.

Далее мы можем удалить C и добавить функцию D. И это никак не повлияет на основной бранч, где мы можем, например, добавить функцию F. Затем в нашем бранче мы можем удалить функцию B и добавить E. И все эти изменения не затронут наш основной производственный код. В распределенных системах, таких как Git и Mercurial, ветвление - это действительно очень простая и быстрая функция, потому что она на самом деле только создает файл размером 40 байт с новым GUID, указывающим новый путь изменений, и не выполняет копирование файлов.

Рука об руку с ветвлением идет обратный процесс, который называется слиянием. Он позволяет вам взять изменения, которые вы сделали в бранче, и добавить их обратно в основной или какой-то другой бранч. Итак, давайте посмотрим. У нас есть основной бранч, в котором находится файл main, и мы создадим новую ветку, как мы это делали ранее, под названием feature 1, и добавим в нее функцию D. Теперь в основном бранче мы добавим функцию F. И параллельно в бранче feature 1 мы добавим функцию E.

Сделав все эти изменения, вы можете решить, что вам нравятся оба набора изменений, и вы хотите объединить их. В данном случае у нас нет никаких конфликтующих изменений, потому что мы ничего не удаляли, а только добавляли. Так что теперь мы просим нашу систему контроля версий слить два бранча, и получаем новый file 1 в основном бранче со всеми функциями как из основного бранча, так и из бранча feature 1. Конфликты могут возникать, когда два изменения в каждой ветке выполняют одно и то же. Например, если мы удалили функцию B в обоих бранчах, ПО контроля версий иногда не может определить точно, что вы хотели сделать, и поэтому оно объявляет конфликт слияния и требует, чтобы вы разрешили его вручную.

Оно открывает инструмент дифференциации, чтобы вы могли просмотреть строки, которые были изменены в контексте, и решить, хотите ли вы взять версию из основного бранча, из feature 1 или из них обоих. В Windows я настоятельно рекомендую качестве инструмента дифференциации использовать Beyond Compare. Для Mac и Linux есть много эффективных инструментов. Одним из важных преимуществ ПО контроля версий помимо дифференциации является то, что оно не только требует от вас просматривать внесенные изменения, но и показывает сообщения коммитов, по которым вы можете определить намерения разработчика, который их сделал, чтобы понять, как эффективно слить две ветки вместе.

Ветвление и слияние являются двумя наиболее мощными функциями в любой системе контроля версий, и если подойти к ним с умом, они будут самыми полезными из доступных вам функций, потому что они позволяют вам экспериментировать или работать параллельно, а затем объединить результаты своей работы и создать законченный продукт или проект. Поэтому используйте бранчи всегда, когда вам нужно гарантировать, что основной или любой другой бранч останутся нетронутыми.