Как я могу организовать личные репозитории Git?


20

Я нахожусь в процессе настройки учетной записи GitHub с планом создания пары библиотек, которые я разработал как части некоторых недавних проектов iOS, свободно доступных для использования другими разработчиками iOS.

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

Есть ли что-то, чего мне не хватает, что позволило бы мне использовать git-репозиторий с иерархией и проверять фрагменты по мере их необходимости / работы с ними, как я в настоящее время делаю с SVN?

Есть ли у GitHub (или у конкурента, такого как BitBucket) некоторые функции организации проекта, которые мне не хватает?

В противном случае, каков общепринятый «способ Git» для обработки этой ситуации (отменить проекты, не предназначенные для выпуска, сохранить их в автономном режиме, каким-то образом связать их вместе и т. Д. И т. Д.)?

Насколько я могу сказать, мои варианты:

  1. Поместите библиотеки на GitHub, продолжайте размещать свой собственный SVN для всех других проектов, используйте решение не VCS для резервного копирования вне сайта (blech),
  2. Поместите библиотеки и программное обеспечение, которое я планирую выпустить, на GitHub (как общедоступное и частное соответственно), продолжайте размещать свой собственный SVN для проектов, которые меня не особо интересуют, и я, скорее всего, еще раз зайду, чтобы освежить память о том, как реализовать XYZ решите, что я готов их списать, если мой дом рухнет (двойной блех),
  3. Поместите все на [GitHub и / или BitBucket], разберитесь с каким-то смехотворным количеством репозиториев, отыскивая то, что мне нужно, / поддерживая некоторый автономный набор указателей в моей учетной записи [GitHub и / или BitBucket] (triple blech)

2
Мне любопытно узнать, о скольких репозиториях мы говорим здесь. Что вы подразумеваете под «указателями»?
mhulse

так как это старый вопрос, bitbucket позволяет создавать бесплатные организации, и в них вы можете иметь проекты, которые могут иметь репозитории. Организации свободны до определенного количества пользователей. Вы можете управлять разрешениями с помощью org / project / repo.
ксенотеррацид

Обратите внимание, что GitHub теперь предлагает неограниченное количество частных репозиториев с их платными планами.
Джек

Ответы:


11

bitbucket.org позволяет создавать неограниченные частные репозитории.

Git не позволяет вам проверить только некоторые фрагменты кода. Поэтому вам нужно будет создать репо для каждого проекта или заняться клонированием всех проектов. На самом деле я не вижу проблемы в том, чтобы поместить все наши небольшие проекты в один репо. Вы клонируете это однажды, и все готово.

С Git вам больше никогда не придется «извлекать» код, если только вы не уничтожите локальное хранилище или не перейдете на другую машину. Вы просто синхронизируете все свои изменения.

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


Верно, верно ... Я, вероятно, не должен был специально вызывать GitHub, так как я открыт для использования BitBucket для частных проектов. Немного отредактировал вопрос, чтобы сделать его менее конкретным.
Arkaaito

5

Короткий ответ ...

Мое предложение: начать с публичных учетных записей на GitHub и / или Bitbucket (другое?). Добавьте несколько открытых проектов и начните использовать инструменты / интерфейсы. Когда вы почувствуете, что такое сервисы, вы должны понять, каковы ограничения, преимущества и недостатки каждого сервиса. Оттуда вы сможете выбрать лучший путь к просвещению в области контроля версий. :)


Длинный ответ ...

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

Рассматривали ли вы установить свой собственный клиент Git? Если вы уже платите за веб-хостинг, возможно, имеет смысл использовать этот хост для собственной настройки Git.

Например, мой хост - это WebFaction (нет принадлежности):

Установка веб-приложения Git

Направление этого маршрута может позволить вам сэкономить $$$, особенно. если вы уже платите за хостинг.

GitHub не только заряжает частный репозиторий,

Просто чтобы уточнить для других (опять же, нет никакой деловой принадлежности к GitHub или BitBucket):

GitHub: планы и цены

  • $ 7 / мес. до 5 частных репозиториев , неограниченное все остальное.
  • $ 12 / мес. до 10 частных репозиториев , неограниченное все остальное.
  • $ 12 / мес. до 20 частных репозиториев , неограниченное все остальное.

Обратите внимание, что цены на «Бизнес-планы» отличаются.

Ценообразование для Git и Mercurial репо-хостинга для Bitbucket от Atlassian

Как заявил Эндрю в другом ответе, Bitbucket рекламирует неограниченные частные репо.

  • 5 пользователей: бесплатно
  • 10 пользователей: $ 10 / мес.
  • 25 пользователей: $ 25 / мес.
  • 50 пользователей: $ 50 / мес.
  • 100 пользователей: $ 100 / мес.
  • Неограниченный $ 200 / мес.

похоже, что у него нет никакого способа организовать хранилища иерархически.

Не уверен, что именно вы подразумеваете под «иерархически» (возможно, потому что я не знаком с SVN).

Я не уверен, поможет ли это, но вы можете взглянуть на эту таблицу сравнения, чтобы увидеть, как команды сравниваются / отличаются:

Есть ли что-то, чего мне не хватает, что позволило бы мне использовать git-репозиторий с иерархией и проверять фрагменты по мере их необходимости / работы с ними, как я в настоящее время делаю с SVN?

Ветвление?

Есть ли у GitHub (или у конкурента, такого как BitBucket) некоторые функции организации проекта, которые мне не хватает?

Не уверен, поможет ли это, но вы можете взглянуть на:

Git поставляется со встроенными инструментами GUI для фиксации ( git-gui ) и просмотра ( gitk ), но есть несколько сторонних инструментов для пользователей, которые ищут опыт работы с конкретной платформой.

... опять же, не уверен, что какой-либо из этих инструментов поможет вам понять, что возможно.

Чтобы быть ясным, я не уверен в вашем уровне навыков Git ... если вы новичок в Git / GitHub, использование GUI может быть быстрым / простым способом почувствовать вещи. Мне лично нравится использовать официальный GitHub для приложений Mac / Windows.

В противном случае, каков общепринятый «мерзкий способ» решения этой ситуации (отменить проекты, не предназначенные для выпуска, сохранить их в автономном режиме, каким-то образом связать их вместе и т. Д. И т. Д.)?

На вашем месте я бы использовал репозитории.

Сколько частных репозиториев вам нужно?

Если вы хотите использовать GitHub, одним из решений может быть получение самого дешевого плана и использование нескольких частных репозиториев для хранения всего вашего тестового / закрытого кода. Вы можете просто использовать структуру папок в своей mainветке, чтобы поддерживать иерархическую структуру, или вы можете использовать несколько веток, чтобы держать вещи более разделенными.

Подсказка: если вы используете более свежую версию Git, вы можете получить определенные ветки, используя git clone -b mybranch --single-branch git://sub.domain.com/repo.git:

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

( Смотрите мой ответ здесь для получения дополнительной информации о ветвях GitHub. )

Опять же, я думаю, что несколько репо - это путь.

Вы можете спросить себя, действительно ли ваш код должен быть закрытым; Возможно ли, что вы могли бы обнародовать указанный код без каких-либо последствий?

Поместите библиотеки на GitHub, продолжайте размещать свой собственный SVN для всех других проектов, используйте решение не VCS для резервного копирования вне сайта (blech),

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

Поместите библиотеки и программное обеспечение, которое я планирую выпустить, на GitHub (как общедоступное и частное соответственно), продолжайте размещать свой собственный SVN для проектов, которые меня не особо интересуют, и я, скорее всего, еще раз зайду, чтобы освежить память о том, как реализовать XYZ решите, что я готов их списать, если мой дом рухнет (двойной блех),

Это возвращает меня к вопросу «Вы уже платите за хостинг? Если это так, вы можете установить свой собственный хост Git»; преимущество в том, что вы можете иметь весь исходный код под зонтиком Git, даже если он не на одном хосте (то есть использовать GitHub для общедоступного материала, который вы хотите продемонстрировать).

Поместите все на [GitHub и / или BitBucket], разберитесь с каким-то смехотворным количеством репозиториев, отыскивая то, что мне нужно, / поддерживая некоторый автономный набор указателей в моей учетной записи [GitHub и / или BitBucket] (triple blech)

---> Смотрите мой короткий ответ выше. ^^^^^^


0

Вот что я делаю:

  • Поместите отдельные проекты, которые вы хотите опубликовать в отдельном GitHub репозиториях . Поскольку GitHub в настоящее время является де-факто местом для обмена кодом, это сделает ваши проекты более доступными для обнаружения / простыми для разветвления.
  • Для любых проектов, которые вы хотите оставить закрытыми, поместите их в частные репозитории, размещенные вашим поставщиком по вашему выбору. Как уже упоминалось, Bitbucket является хорошим выбором для этого, поскольку он позволяет неограниченное количество частных репо.
  • Поместите весь другой код в «мусорное» хранилище. Это может включать в себя код, используемый для изучения и тестирования, а также небольшие фрагменты, которые на самом деле не являются частью проекта. Пока нет причин хранить это в тайне, вы также можете разместить этот репозиторий на GitHub.

    В дополнение ко всем обычным преимуществам контроля версий (которые у вас уже есть в SVN), теперь ваш код резервируется онлайн. В случае, если какой-либо ваш ненужный код превращается в проект, вы можете просто раскрутить его в собственное репо.

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


0

Одним из возможных методов будет использование веток.

Ветви в git-репо - это просто указатели на коммиты, они не должны быть связаны друг с другом каким-либо образом. Таким образом, вы можете создать репо «minorprojects» на хостинге, а затем использовать ветку в этом репо для каждого проекта. Если незначительный проект растет, вы можете легко переместить ветку в собственное репо.

Локально вы можете хранить ветки в отдельных локальных репозиториях (между локальными и удаленными репозиториями не должно быть сопоставления 1: 1) или иметь одно локальное репо и использовать рабочее дерево git для поддержки нескольких рабочих деревьев. Лично я подозреваю, что первый подход менее подвержен ошибкам.


Хранение их в одном и том же удаленном репо не означает, что вы должны использовать одно и то же локальное репо.
Питер Грин

Просто забудь о моем последнем комментарии. Я только что узнал о git worktreeкоманде, которая позволяет вам создавать дополнительные рабочие деревья для репозитория, позволяя вам проверять несколько веток одновременно. При этом недостатки вашего подхода в основном исчезают: просто создайте рабочее дерево для каждой независимой ветви и используйте их как независимые репозитории. Хорошая идея добавить это к вашему ответу :-)
cmaster - восстановить

@cmaster, сделано ...
Питер Грин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.