Что хороший путь состоит в том, чтобы организовать большое количество персональных сценариев с помощью мерзавца?
У меня есть большое количество моих персональных сценариев, что я хотел бы запустить управление версиями с помощью Мерзавца. Я ранее организовал свой код следующим образом:
~/code/python/projects/ (for large stuff, each project contained in an individual folder)
~/code/python/scripts/ (single file scripts all contained in this directory)
~/code/python/sandbox/ (my testing area)
~/code/python/docs/ (downloaded documentation)
~/code/java/... (as above)
Теперь я собираюсь запустить управление версиями мой код с помощью мерзавца, так, чтобы я мог иметь историю и скопировать весь мой код к удаленному серверу.
Я знаю, использовал ли я SVN, я просто сохранил бы свое все"~/code/"каталог в большом репозитории, но я понимаю, что это не хороший способ сделать вещи с Мерзавцем.
Большая часть информации, которую я видел онлайн, предлагает сохранить все мои папки проекта в единственном месте (как в, никакие отдельные каталоги для Python или Java) с каждым проектом, содержащим свой собственный репозиторий мерзавца и просто имеющим каталог "отрывков", содержащий все однофайловые сценарии/эксперименты, которые могут быть преобразованы в проекты позднее.
Но я не уверен, как я чувствую о консолидации всех моих каталогов кода в одну область. Существует ли хороший способ сохранить мои отдельные каталоги кода в целости, или разве это не стоит усилия? Возможно, я просто привязан к отдельным каталогам кода, потому что я никогда не знал ничто больше...
Также (как примечание стороны), я хотел бы быстро смочь видеть хронологическую историю всех своих проектов и сценариев. Таким образом, я вижу, какие проекты я создал последний раз. Я раньше делал это путем хранения числа в начале всех моих проектов, 002project, 003project.
Там автоматический или простой способ состоит в том, чтобы сделать это в мерзавце, не имея необходимость добавлять число ко всем названиям проекта?
Я открыт для любого практического или философского кода, организующего совет, который Вы имеете.Спасибо!!!
2 ответа
Я знаю, что если бы я использовал SVN, я бы просто сохранил весь свой каталог «~ / code /» в большом репозитории, но я понимаю, что это не хороший способ делать что-то с Git.
Причина, по которой git отговаривает людей от создания единых, монолитных репозиториев, заключается в том, что вы не можете клонировать подкаталоги репозитория (как это можно сделать с SVN)
Допустим, у вас есть git: //blah/somecorp_code.git с миллионами исправлений и размером 15 ГБ. Если вам просто нужен подкаталог этого кода, жестко - вы либо получаете все 15 ГБ, либо ничего.
Для личного кода это не проблема - у меня есть один «монолитный» репозиторий git размером около 20 МБ, и я могу с радостью клонировать его на всех машинах, на которых я хочу его использовать.
Никто другой его не использует, никто другой не фиксирует, и я редко делаю много ветвлений. На самом деле это просто причудливая система отмены с хорошей синхронизацией и удаленным резервным копированием (частный проект GitHub)
Я организовал это следующим образом:
На корневом уровне репозитория у меня есть код (вместе с папкой sites для материалов веб-разработчиков - поэтому размер репозитория составляет 20 МБ)
В папке с кодом у меня есть папки для разных языков ( python , ruby , c и т.д.)
В каждом языковом каталоге у меня есть две папки, фрагменты и проекты . Внутри сниппетов находится куча файлов, внутри проектов - серия папок.
Эти проекты - случайные вещи, которые я написал, но на самом деле они мало работают (игрушечные проекты: «Интересно, мог бы я ..."-projects и т. д.)
Если это один файл Python, он помещается в code / python / snippets / , если это более одного файла, он входит в code / python / projects / { имя проекта}
Когда я хочу публично выпустить проект (обычно на Github), я создаю новый репозиторий, копирую в него код и синхронизирую его с Github.
Теперь отдельный репозиторий «активного проекта» не связаны с монолитным репозиторием. Я изучил проект подмодуля, но он не предназначен для этого использования - он предназначен для упрощения клонирования зависимостей, а не для управления серией несвязанных репозиториев
У меня есть сценарий, который использует Github API чтобы автоматически клонировать все мои проекты локально или обновить их с помощью git pull - это просто автономная версия githubsync.py (я объединил github.py в тот же файл). можно найти здесь как gist / 373731
. Я использовал githubsync.py, чтобы изначально клонировать свои проекты на ноутбук и настольный компьютер, а также регулярно запускать его в сбоку Dropbox, в качестве резервной копии.
Я знаю, что если бы я использовал SVN, я бы просто сохранил весь свой "
~ / code /"в большом репозитории, но я понимаю, что это не лучший способ делать что-то с Git.
Да, это так.
Но если у вас есть большой репозиторий, вы должны различать в нем части, которые будут развиваться со своим собственным жизненным циклом и собственным тегом.
Это будут подмодули , которые, как вы сказали, будут собственным репозиторием git.
Таким образом, вы все равно получите:
code
.git (main project)
python
.git (main sub-project for all python-related stuff)
project1
.git (first submodule)
project2
.git (first submodule)
...
scripts
.git (one submodules for all your scripts)
sandbox
.git (sandbox submodule)
docs
.git (docs submodule)
java
.git (main sub-project for all java-related stuff)
... (repeat same organization)
Примечание: хронологию создания проектов по-прежнему лучше контролировать с помощью соглашения об именах.
С таким количеством подмодулей вы можете:
- фактически клонировать и работать над любой частью вашей коллекции, не обязательно получать все
- , или вы можете воссоздать ту же старую организацию, которая была у вас изначально