Статьи

Подмодули Git для зависимого или общего кода

Январь 29, 2018

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

Проблема Подмодулей Решает

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

Вероятно, есть еще один пост о том, как структурировать ваш проект для поддержки субмодулей и общего кода!

.
├── lib
│   ├── theme88
│   └── mybesttools <-- submodule
├── README.md
├── src
    ├── config.php
    ├── controllers
    ├── inc
    ├── models
    ├── public
    ├── scripts
    ├── services
    └── views

Здесь у меня есть базовый макет проекта с подмодулем внутри каталога lib /. Это позволяет мне легко вносить изменения в репозиторий mybesttools, а также вносить изменения здесь и затем отправлять их обратно в апстрим.

Как создать и работать с такой установкой? Продолжай читать ….

Создание субмодулей

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

подмодуль git add [репо URL] lib / mybesttools

Теперь давайте посмотрим на то, что на самом деле произошло. Запустите git status сейчас, и вы увидите две вещи:

  • Изменение в mybesttools
  • Изменение файла с именем .gitmodules, посмотрите здесь, чтобы увидеть настройки для подкаталога и репозитория, который там связан

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

Принятие изменений в подмодули

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

  1. Зайдите в каталог подмодулей. Изнутри он работает так же, как и любой другой git-репо, поэтому внесите новые изменения, как обычно,
  2. Теперь вам нужно указать родительскому репо использовать новую ревизию. git status покажет вам, что ваш подмодуль изменился, а git diff покажет номера ревизий. Добавить и зафиксировать измененный подмодуль и отправить ваши изменения

Помнить не только о том, чтобы вставить новый код в ваш собственный проект и проверить, что все в порядке, но и о том, чтобы зафиксировать и вставить родительский проект, — это ключ — и его очень легко пропустить!

Внесение изменений в подмодуль

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

  1. Сделайте все изменения. Фиксируйте те в родительском проекте как обычно
  2. Перейдите в подмодуль и относитесь к нему как к обычному репо, куративному вменяемому и атомарному коммитам со значимыми коммит-сообщениями (потому что так мы всегда работаем, верно?). Возможно, вам придется проверить свой субмодуль на ветке, прежде чем вы сможете его зафиксировать; это происходит потому, что когда вы обновляете свой подмодуль, он просто проверяет данную ревизию и оказывается в отключенном состоянии головы.
  3. Убедитесь, что вы сейчас отправили свои изменения обратно в репозиторий для субмодуля.
  4. Наконец (и жизненно важно) теперь вернитесь к вашему родительскому проекту и добавьте и зафиксируйте подмодуль. Это позволяет родительскому проекту узнать, на какую ревизию подмодуля он указывает.
  5. Теперь отправьте изменения в родительский репозиторий и дважды проверьте, что вы действительно выдвинули эту ревизию и из подмодуля!

Надеюсь, это даст вам некоторое представление о том, как движущиеся части работают с подмодулями. Конечно, есть некоторые подводные камни, такие как забвение обновления родительского репо при смене подмодуля или забывание вносить изменения в один или другой репозиторий, но, надеюсь, я пометил все это таким образом, чтобы помочь вам избежать любых основные проблемы — или, по крайней мере, быстро понять и распутать их, если что-то случится.

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

Дальнейшее чтение

36
Share: