Git Submodule Workflow Advice

Question

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

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

//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. Какая часть подмодуля топлива сообщает git, чтобы начать с 1.1/развивать для начала? Там являются другие отрасли (1.1/master, 1.0/develop и т.п ..).
4. Почему мы не можем назвать это днем ​​на шаге 11? Толчок подмодуля работал нормально. Затем я нажимаю супер, потому что руководство tells me it's a good idea. И действительно, направляясь к GitHub и глядя на MY super, совершается фиксация. This commit 845de87 Однако, похоже, это просто ссылка на супер топлива Super, а не MY super. Разве это не ссылка на МОЕ РЕПО, а не их?
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 на MY собственный репо на GitHub? В любом случае топливо отрицает толкает. Если я буду выполнять обновление подмодуля, они будут перезаписаны?

Я также спросил об этом по телефону Fuel's Forums, но это скорее общий вопрос, и здесь больше Gitters ... СПАСИБО!

Answer 1

1. Да, как описано в разделе «true nature of submodules»

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

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

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

5. Использование forks может помочь
   Смотрите "Changing remote repository for a git submodule" обновить подмодуль удаленный URL.