Подмодули — это одна из самых мощных и самых недоверчивых функций в 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.
Принятие изменений в подмодули
Итак, вы строите проект с библиотекой в подмодуле. В подмодуле есть новые изменения, и вы хотите внести их в свой проект. Ваш рабочий процесс будет выглядеть примерно так:
- Зайдите в каталог подмодулей. Изнутри он работает так же, как и любой другой git-репо, поэтому внесите новые изменения, как обычно,
- Теперь вам нужно указать родительскому репо использовать новую ревизию. git status покажет вам, что ваш подмодуль изменился, а git diff покажет номера ревизий. Добавить и зафиксировать измененный подмодуль и отправить ваши изменения
Помнить не только о том, чтобы вставить новый код в ваш собственный проект и проверить, что все в порядке, но и о том, чтобы зафиксировать и вставить родительский проект, — это ключ — и его очень легко пропустить!
Внесение изменений в подмодуль
Если вы работаете над функцией, которая требует изменений в подмодуле, вам не нужно фиксировать их вверх по течению и извлекать их, вы можете сделать их прямо в своем проекте (это одна из причин, почему мне нравится этот метод над управление зависимостями при работе с библиотекой, которую я знаю, может развиваться вместе со мной). Вам нужно очень тщательно обработать изменения между субмодулем и родительским репо, поэтому попробуйте это как рецепт успеха:
- Сделайте все изменения. Фиксируйте те в родительском проекте как обычно
- Перейдите в подмодуль и относитесь к нему как к обычному репо, куративному вменяемому и атомарному коммитам со значимыми коммит-сообщениями (потому что так мы всегда работаем, верно?). Возможно, вам придется проверить свой субмодуль на ветке, прежде чем вы сможете его зафиксировать; это происходит потому, что когда вы обновляете свой подмодуль, он просто проверяет данную ревизию и оказывается в отключенном состоянии головы.
- Убедитесь, что вы сейчас отправили свои изменения обратно в репозиторий для субмодуля.
- Наконец (и жизненно важно) теперь вернитесь к вашему родительскому проекту и добавьте и зафиксируйте подмодуль. Это позволяет родительскому проекту узнать, на какую ревизию подмодуля он указывает.
- Теперь отправьте изменения в родительский репозиторий и дважды проверьте, что вы действительно выдвинули эту ревизию и из подмодуля!
Надеюсь, это даст вам некоторое представление о том, как движущиеся части работают с подмодулями. Конечно, есть некоторые подводные камни, такие как забвение обновления родительского репо при смене подмодуля или забывание вносить изменения в один или другой репозиторий, но, надеюсь, я пометил все это таким образом, чтобы помочь вам избежать любых основные проблемы — или, по крайней мере, быстро понять и распутать их, если что-то случится.
Если у вас есть другие советы или рекомендации, пожалуйста, поделитесь в комментариях, я всегда ищу способы улучшить свой рабочий процесс и упростить методы, такие как подмодули, для команд, с которыми я работаю.
Дальнейшее чтение
- Git Log Все филиалы
- Используйте GitHub Branch в качестве зависимости от Composer
- Быстрое переключение между ветками Git
- Бесцветный выход Git
- Понимание отслеживания веток в Git
- Видео: Git Remotes и отслеживание веток