Каков идеальный рабочий процесс для работы над A, B & C параллельно, где A зависит от B и B от C?

Question

Интересно, какой идеальный рабочий процесс, если нужно параллельно работать над проектами A, B и C, где A зависит от B и B, зависит от C.

В настоящее время у меня есть все в одном хранилище, которое ускорило ранний развитие. Так что мой рабочий каталог выглядит следующим образом:

/A/ 
/A/B 
/A/B/C 

Так A это проект, который является движущей силой развития, но это также означает B и C находятся параллельно эволютивные.

Однако, я хочу выпустить проекты B и C отдельно, а также они весьма полезны для других.

Однако я разорван на то, как это сделать, не разрушая скорость развития. npm отлично подходит для управления распределением и зависимостями, но во время разработки вы определенно не хотите перемещать временные версии через Интернет, просто чтобы файлы обновлялись в другой папке на вашем компьютере :)

С другой стороны, вы также можете не хотят их вручную копировать. Heck, все это Мне нужно переключить каталоги для работы на B, а теперь скопируйте его на /A/B страшно и кажется склонным к ошибкам.

Таким образом, git submodule выглядел как ответ, поскольку он по существу позволяет именно это: вы сохранили бы свой макет каталога так, как есть. Затем, когда вы вносите изменения в файлы в B, вы можете напрямую протестировать их в A без необходимости копировать что-то. И когда вы думаете, что он готов, вы можете просто совершить и нажать из трех разных папок. Все происходит автоматически в трех разных хранилищах. Кажется, что рай все же ненавидит git submodule по разным причинам.

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

Так что, интересно, в чем же ответ?

Answer 1

Обратите внимание, что подмодули Git указывают на определенную версию внешнего репозитория, то есть на конкретную фиксацию.

Чтобы обновить все подмодулях Git до последней версии, вы все равно придется run a command:

git submodule foreach git pull origin master 

В зависимости от вашей ситуации, вы могли бы использовать НПМ вместо Git подмодулей. В этом случае вы просто указываете свои зависимости в package.json, а затем запустите npm install в корневом каталоге репозитория, чтобы получить их. Если обновление обновляется и публикуется новая версия, вы снова запускаете npm update, и он будет соответствовать требованиям к версии, установленным в файле package.json.Вы могли бы также use npm to point to a specific commit, так же, как, как Git подмодулей работы:

{ 
    "devDependencies": { 
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#b3c24169432a924d05020c85f852d4a1736e66d4" 
    } 
} 

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

{ 
    "devDependencies": { 
    "dependency-a": "git://github.com/the-user-name/the-project-name.git#master" 
    } 
} 

Answer 2

Я пробовал все эти рабочие процессы и решил, что подмодули git не являются ответом. Основная причина для меня в том, что они объединяют проекты вместе на уровне scm, и неинтересно, где именно в истории изменений эта связь происходит. Особенно в сценарии с отдельной головой. Я полагаюсь на npm для управления зависимостями с комбинацией npm link и git URL. npm link замечательно, когда я хочу проверить что-то локально. git URL-адреса идеально подходят для разрешения зависимостей во время запросов на загрузку. В конце концов, я всегда хочу опубликованный модуль с номером версии, который я могу сопоставить с тегом git для дальнейшего использования и отслеживания проблем. Я использую npm version, чтобы сделать это за один шаг. Позволяет проектам зависеть друг от друга на разных уровнях сцепления в течение моего цикла разработки.

Answer 3

Будет ли использовать здесь git subtree? В этой статье Alternatives To Git Submodule: Git Subtree проделана хорошая работа, объясняющая плюсы и минусы использования git subtree по сравнению с git submodules.