Какой хороший способ организовать большую коллекцию личных скриптов, используя git? - PullRequest
Новая
       6

Какой хороший способ организовать большую коллекцию личных скриптов, используя git?

5 голосов
/ 17 апреля 2010

У меня есть большая коллекция моих личных скриптов, которые я хотел бы начать создавать с помощью Git. Ранее я организовал свой код следующим образом: 

~/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)

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

Я знаю, что если бы я использовал SVN, я бы просто держал весь каталог "~/code/" в большом репозитории, но я понимаю, что это не очень хороший способ сделать что-то с Git.
Большая часть информации, которую я видел в Интернете, предлагает хранить все папки моих проектов в одном месте (например, без отдельных каталогов для python или java), где каждый проект содержит свой собственный репозиторий git, и просто иметь каталог «snippets», содержащий все файл сценариев / экспериментов, которые могут быть позже преобразованы в проекты.

Но я не уверен, что чувствую при объединении всех моих каталогов кода в одну область. Есть ли хороший способ сохранить мои отдельные каталоги кода нетронутыми, или это не стоит усилий? Может быть, я просто привязан к отдельным каталогам кода, потому что больше ничего не знал ...

Кроме того (как примечание), я хотел бы быстро увидеть хронологическую историю всех моих проектов и сценариев. Так что я вижу, какие проекты я создал совсем недавно. Раньше я делал это, сохраняя номер в начале всех моих проектов, 002project, 003project.
Есть ли автоматический или простой способ сделать это в git без добавления номера ко всем именам проектов?

Я открыт для любых практических или философских советов по организации кода, которые у вас есть. Спасибо !!!

Ответы [ 2 ]

5 голосов
/ 21 апреля 2010

Я знаю, что если бы я использовал SVN, я бы просто держал весь каталог "~ / code /" в большом репозитории, но я понимаю, что это не очень хороший способ делать что-то с Git.

Причина, по которой git отговаривает людей от использования одиночных монолитных репозиториев, заключается в том, что вы не можете клонировать подкаталоги репозитория (как вы можете с SVN)и 15 ГБ.Если вам нужен только подкаталог этого кода, жестко - вы либо получите все 15 ГБ, либо ничего.

Для личного кода это действительно не проблема - у меня есть один «монолитный» репозиторий git, который20 МБ, и я могу с радостью сделать его клонированным на всех машинах, на которых я хочу его использовать.

Никто больше не использует его, никто не коммитит, и я редко делаю много в способе ветвления.На самом деле это просто необычная система с хорошей синхронизацией и удаленным резервным копированием (частный проект GitHub)

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

В корневом уровне хранилища у меня естьпапка code (вместе с папкой sites, для web-dev - поэтому размер хранилища составляет 20 МБ)

В папке с кодом у меня есть папки на разных языках (python,ruby, c и т. Д.)

В каждом языковом каталоге у меня есть две папки: snippets и projects.Внутри фрагментов находится куча файлов, внутри проектов - ряд папок.

Эти проекты - случайные вещи, которые я написал, но на самом деле они мало работают (игрушечные проекты: «Интересно, смогу ли я... "- проекты и т. д.)

Если это один файл Python, он помещается в code/python/snippets/, если это более одного файла, он входит в code/python/projects/{project name}

Когда я хочупублично выпустить проект (обычно на Github), я создаю новый репозиторий, копирую в него код и синхронизирую его с Github.

Отдельный репозиторий «активный проект» теперь не связан с монолитным репо.Я изучил проект подмодуля, но он не предназначен для этого использования - он предназначен для упрощения клонирования зависимостей, а не для управления рядом несвязанных репозиториев

У меня есть скрипт, который использует Github API для автоматического клонированиявсе мои проекты локально, или обновите их git pull - это просто автономная версия githubsync.py (я слил github.py в тот же файл).Его можно найти здесь как gist / 373731

Я использовал githubsync.py, чтобы изначально клонировать свои проекты на мой ноутбук и настольный компьютер, а также регулярно запускать его в Dropbox в качестве резервной копии.

2 голосов
/ 17 апреля 2010

Я знаю, что если бы я использовал 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)

Примечание: хронология создания проектов все еще лучше управляется с соглашением об именах.

С таким количеством подмодулей вы можете:

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