Материал: ВВПИ. Лекции

Рис. 13.10. Область интеграции.

На первом шаге (рис. 13.10) разработчик задает откуда (source branch) и куда (target branch), а также изменения из какой области он хочет перенести (все вплоть до определенной версии, или только выбранные пакеты изменений).

111

Рис. 13.11. Версия для интеграции.

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

112

Рис. 13.12. Выбор пакетов для интеграции.

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

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

113

Рис. 13.13. Список конфликтов.

Достаточно часто при интеграции может возникнуть ситуация конфликта изменений, когда интегрируемый файл поменялся в обоих ветвях независимо друг от друга. В этом случае система контроля версий открывает окно со списком обнаруженных конфликтов (рис. 13.13) и предлагает выбрать способ разрешения.

Разработчик может выбрать автоматический способ разрешения, который сработает только для тех файлов, в которых были изменены разные части. В случае, если автоматическое разрешение невозможно, система откроет диалог ручного разрешения – см. рис. 13.14.

Рис 13.14. Разрешение конфликта.

114

Для разрешения конкретного конфликта разработчик может выбрать несколько способов: автоматически объединить изменения (если возможно), принять изменения из исходной ветки, сохранить изменения целевой ветки или вручную разрешить все внутренние конфликты в специальном инструменте рис. 13.15.

Рис. 13.15. Разрешение внутренних конфликтов.

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

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

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

115