• База знаний
  • /
  • Блог
  • /
  • Wiki
  • /
  • ONLINE CHAT
+380 (44) 364 05 71

Статья также доступна на украинском (перейти к просмотру).

Оглавление

Разветвленная разработка веб-приложений под управлением Git обычно приводит к необходимости иметь сложную структуру дерева разработки, отдельные ветви которого подчиняются ветвям более высокого уровня. На практике это означает наличие отдельных подпроектов в пределах одного суперпроекта, размещенных во вложенных подкаталогах локальных репозиториев.Такая структура затрудняет процесс синхронизации внесенных изменений и требует использования различных стратегий, чтобы исключить появление конфликтов, в частности, при слиянии ветвей дерева разработки. Одной из таких стратегий является средство управления поддеревьями git subtree, позволяющее частично автоматизировать обмен данными в рамках супер проекта и организовать полноценную работу с неограниченным количеством подпроектов. Рассмотрим более подробно указанный механизм и продемонстрируем работу с ним на практике.

Возможности Git-системы по управлению отдельными подпроектами

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

Git предоставляет следующие рекомендации и инструменты для успешного осуществления операций по управлению ветвями разработки:

  • Необходимо периодически фиксировать внесенные изменения в рабочем каталоге с помощью коммитов;
  • Перед выполнением операции слияния желательно сохранить внесенные в локальный подпроект изменения во временной ветви, чтобы, в случае совершения неудачной операции, обновление или слияние позволит сохранить данные;
  • Периодически совершать операции слияния для быстро растущих ветвей;
  • При возникновении сомнений относительно корректности операции слияния, всегда можно ее отменить с помощью команды git merge --abort;
  • Следует использовать возможности управления процессом слияния ветвей дерева с помощью аргументов командной строки, например, это касается настроек игнорирования изменений пустых символов с использованием опции -Xignore-all-space;
  • отдельных сложных случаях можно применять так называемое ручное слияние, например, с использованием программы dos2unix для предварительного прогона файла через «фильтр»;
  • Для выявления причин возникновения конфликтов всегда можно использовать команду git checkout с опцией –conflict, которая предоставит дополнительную информацию для выяснения причин возникновения конфликтов;
  • Для выявления причин возникновения конфликтов можно использовать логи с помощью команды git log;
  • Выполнять постанализ данных сразу же после возникновения конфликта с помощью команды git diff, что позволит увидеть конфликтующие объекты.

Можно выделить три основные стратегии или механизмы Git по управлению поддеревьями одного суперпроекта:

  • механизм подмодулей (команда git submodule);
  • Классический механизм слияния ветвей (команда git merge);
  • Средство упрощенного управления процессом (команда git subtree).

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

Механизм подмодулей более консервативный и требует большого опыта от Администратора и временных затрат. Однако, в некоторых ситуациях, его использование может быть целесообразным.

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

Средство упрощенного управления процессом лучше подходит для организации работы несложных проектов Администраторами с небольшим опытом работы. Именно для таких случаев он наиболее приемлем. Он может пригодиться при использовании библиотек функций в качестве самостоятельных подпроектов.

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

Упрощенное управление поддеревьями проекта

Рассмотрим применение упрощенного механизма управления подпроектами с помощью git subtree. Выделим основные его преимущества над другими стратегиями управления:

  • Простота освоения и применения;
  • Поддержка предыдущих версий программы;
  • Отсутствие дополнительных файлов метаданных;
  • Код подпроекта доступен сразу после клонирования главного проекта;
  • Содержимое каталога может быть изменено без необходимости копирования программной зависимости в отдельный репозиторий.

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

  • Создание и активация локального Git-репозитория с именем reposit_lesson;
  • Создание в рамках репозитория подпроекта, содержащего данные удаленного публичного репозитория;
  • Обеспечение обновления данных подпроекта.

Итак, начнем с создания локального репозитория. Для этого введем в терминале следующие команды:

$ mkdir reposit_lesson
$ cd reposit_lesson

Инициируем пустой репозиторий:

$ git init

Инициализация прошла успешно – «Initialized empty Git repository in /root/reposit_lesson/.git/».

С целью внесения изменений создадим файл с именем .testfile:

$ touch .testfile

Добавим созданный файл к индексу Git:

$ git add .testfile

Зафиксируем внесенные в репозиторий изменения с помощью исполненного коммита:

$ git commit -m "Initial commit lesson repository"

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

$ git subtree add --prefix js_node https://github.com/nodejs/node.git  main

git fetch https://github.com/nodejs/node.git main
warning: no common commits
remote: Enumerating objects: 642893, done.
remote: Counting objects: 100% (124/124), done.
remote: Compressing objects: 100% (108/108), done.
remote: Total 642893 (delta 67), reused 45 (delta 16), pack-reused 642769
Receiving objects: 100% (642893/642893), 905.01 MiB | 11.01 MiB/s, done.
Resolving deltas: 100% (469670/469670), done.
From https://github.com/nodejs/node
 * branch        	main   	-> FETCH_HEAD
Added dir 'js_node'

Для периодического обновления кода подпроекта данными из удаленной первоначальной ветви можно воспользоваться следующей командой:

$ git subtree pull --prefix js_node https://github.com/nodejs/node.git main

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

$ git remote add -f node_remote https://github.com/nodejs/node.git

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

$ git subtree add --prefix js_node node_remote main

Как видим, на выходе команды появилось сообщение о том, что каталог js_node уже существует. И это понятно, поскольку введенная команда, по сути, дублирует ранее введенную, но имеющую сокращенную форму.

Введем команду для получения последней версии подпроекта из первоначальной удаленной ветви:

$ git fetch node_remote main

Как можно убедиться, обновление данных прошло успешно.

Пулинг данных подпроекта тепер можно исполнить с помощью следующей конструкции:

$ git subtree pull --prefix js_node node_remote main

Команда учла то, что новые изменения не были внесены после осуществления нами последнего обновления, сообщив на выходе: «Already up to date».

Кстати, если вам нужен мощный инструмент для удаленного взаимодействия команды, можем предложить вам виртуальный сервер с GitLab. GitLab включает в себя Git, инструменты CI/CD, online редактор кода, Wiki и многие другие возможности. Сервер автоматически настраивается сразу после оплаты заказа, через 2-3 минуты Вы уже можете начать с ним работать. Дополнительное преимущество - автоматическое ежедневное создание бекапов.

Подписывайтесь на наш телеграм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.

Мы в чем-то ошиблись, или что-то пропустили?

Напишите об этом в комментариях на сайте и в телеграм-канале. Мы с удовольствием ответим и обсудим Ваши замечания и предложения.

Дата: 31.08.2023
Автор: Александр Ровник
Голосование

Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:

comments powered by Disqus
navigate
go
exit
Спасибо, что выбираете FREEhost.UA