Git Submodule Workflow Советы

Question

Итак, я начал использовать Git несколько дней назад. ( Очень поздно на вечеринку - не ругайте :) ). Действительно начинаю освоиться с основными командами, идеями и рабочими процессами. Тем не менее, субмодули действительно берут мой мозг на прокат. Я пытаюсь внести код в FuelPHP GitHub , и я мог бы использовать некоторые рекомендации и советы.

Я выполняю следующие команды в терминале:

//1: clone the repository from Fuel's github.
git clone git://github.com/fuel/fuel.git

//2: move into the main fuel directory
cd fuel

//3: initilize the submodules (populate .git/config with submodule data)
git submodule init

//4: download the submodules...
git submodule update

//5: move into the core directory (which is a submodule).
cd fuel/core

//6: change branch from (*no branch) to 1.1/develop
git checkout 1.1/develop

//7: open random file in text editor + make some small change (i.e. typo) + save file.
sudo gedit classes/autoloader.php

//8: add this file to the staging area.
git add classes/autoloader.php

//9: commit this file under 1.1develop branch.
git commit -m "im committing a submodule"

//10: push the new commit to MY (not fuel's) github repo (yes i've renamed the repo).
git push git@github.com:jordanarseno/fuel-core.git

//11: changes are reflected on github, looks good.

//12: back way out to fuel again. time to push the submodule commit separately.
cd ../../

//13: add the fuel/core submodule to the staging area.
git add fuel/core

//14: commit the submodule change.
git commit -m "submodule pushed. pushing super now."

//15: push the commit to MY (not fuel's) github repo.
git push git@github.com:jordanarseno/fuel.git

В частности, мои вопросы:

1. Это правильный рабочий процесс для работы с подмодулями? Это то, что вы будете делать?
2. Почему git опускает ветку 1.1/develop в подмодуле, но по умолчанию устанавливает меня на *no branch? Могу ли я изменить это поведение?
3. Какая часть подмодуля Fuel говорит git тянуть 1.1 / development для начала? Там есть другие ветви (1.1/master, 1.0/develop и т. Д.).
4. Почему мы не можем назвать это днем ​​на шаге 11? Субмодульный пуш работал нормально. Потом я толкаю супер, потому что руководство говорит мне, что это хорошая идея . И действительно, отправляясь на GitHub и глядя на мой супер, коммит сделан. Этот коммит 845de87 , тем не менее, похоже, является ссылкой на супер топливо, а не МОЕ супер. Разве это не ссылка на МОЕ РЕПО, а не на их?
5. Запуск cat .git/config в супер шоу:

Вместе со всеми подмодулями ...

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://github.com/fuel/fuel.git`

Запуск cat .git config в основном подмодуле показывает:

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://github.com/fuel/core.git

Было бы разумно изменить эти URL-адреса на МОЕ собственное репо на GitHub? Топливо в любом случае отрицает толчки. Если я выполню обновление субмодуля, они будут перезаписаны?

Я также спрашивал об этом на Топливных форумах , но это более общий вопрос, и здесь есть больше Гиттеров ... СПАСИБО!

Answer 1

1. Да, как объяснено в " истинной природе подмодулей "

2. подмодуль git является ссылкой на конкретный коммит (SHA1), а не ветвь, поэтому вы всегда сначала находитесь в режиме отсоединения (который совместим с использованием только для чтения).
   Другими словами, git submodule update проверяет конкретную фиксацию, а не подсказкуфилиал.
   Файл .gitmodule будет содержать ссылку на ваш подмодуль репо.А конкретный SHA1 будет записан в родительском репо как специальный коммит (режим 160000).Когда вы 'git submodule add' создаете новый подмодуль, он записывает SHA1, на котором в данный момент извлекается другое репо (независимо от его ветви).
   Если вы хотите внести изменения, вы должны оформить ветку в этом репо подмодуля.(существующая ветка или новая : в обоих случаях вы отправите любое новое изменение в удаленное хранилище этого подмодуля).
   Альтернативой может быть git slave .

3. См. 2. Другие ветви, перечисленные в git branch, являются локальными, существующими в вашем репо подмодуля, включая один локальный филиал для каждой отслеживающей ветви , если вы сделали git pull в одной точке.

4. Поскольку родитель все еще ссылается на начальный SHA1 подмодуля.
   Но поскольку вы внесли в него изменения, этот SHA1 необходимо обновить.
   Имейте в виду, чтоподмодуль сам по себе является git-репо ... абсолютно не подозревая, что он используется как подмодуль.Следовательно, необходимо записать новое состояние этого репо в родительском репо (единственный отслеживающий состояние его подмодулей).
   Ваш первый git push полностью внутренняя операция подмодулярепо (которого родительское репо вообще не видит).
   Для родительского репо подмодуль репо представляет собой «черный ящик», содержащий только удаленный адрес и SHA1.Все, что делается внутри подмодуля, не имеет последствий для родителя, который обнаружит только изменение SHA1 дерева подмодуля.

5. Использование forks может помочь
   См. " Изменение удаленного репозитория для подмодуля git " для обновления удаленного URL вашего подмодуля.