Я нахожусь в процессе настройки учетной записи GitHub с планом создания пары библиотек, которые я разработал как части некоторых недавних проектов iOS, свободно доступных для использования другими разработчиками iOS.
В настоящее время у меня нет резервной копии для большей части моего кода, поэтому изначально я думал, что буду загружать все свои личные проекты или, по крайней мере, все свои проекты iOS, в частный репозиторий на GitHub. , Тем не менее, у меня есть много проектов, многие из которых являются довольно низкими (то есть адаптированы из книг и написаны для обучения). GitHub не только взимает плату с частного репозитория, но, похоже, не имеет никакого способа организовать хранилища иерархически.
Есть ли что-то, чего мне не хватает, что позволило бы мне использовать git-репозиторий с иерархией и проверять фрагменты по мере их необходимости / работы с ними, как я в настоящее время делаю с SVN?
Есть ли у GitHub (или у конкурента, такого как BitBucket) некоторые функции организации проекта, которые мне не хватает?
В противном случае, каков общепринятый «способ Git» для обработки этой ситуации (отменить проекты, не предназначенные для выпуска, сохранить их в автономном режиме, каким-то образом связать их вместе и т. Д. И т. Д.)?
Насколько я могу сказать, мои варианты:
- Поместите библиотеки на GitHub, продолжайте размещать свой собственный SVN для всех других проектов, используйте решение не VCS для резервного копирования вне сайта (blech),
- Поместите библиотеки и программное обеспечение, которое я планирую выпустить, на GitHub (как общедоступное и частное соответственно), продолжайте размещать свой собственный SVN для проектов, которые меня не особо интересуют, и я, скорее всего, еще раз зайду, чтобы освежить память о том, как реализовать XYZ решите, что я готов их списать, если мой дом рухнет (двойной блех),
- Поместите все на [GitHub и / или BitBucket], разберитесь с каким-то смехотворным количеством репозиториев, отыскивая то, что мне нужно, / поддерживая некоторый автономный набор указателей в моей учетной записи [GitHub и / или BitBucket] (triple blech)
источник
Ответы:
bitbucket.org позволяет создавать неограниченные частные репозитории.
Git не позволяет вам проверить только некоторые фрагменты кода. Поэтому вам нужно будет создать репо для каждого проекта или заняться клонированием всех проектов. На самом деле я не вижу проблемы в том, чтобы поместить все наши небольшие проекты в один репо. Вы клонируете это однажды, и все готово.
С Git вам больше никогда не придется «извлекать» код, если только вы не уничтожите локальное хранилище или не перейдете на другую машину. Вы просто синхронизируете все свои изменения.
У меня есть проблема с большим количеством репозиториев. Причина, по которой я не могу хранить их все в одном репозитории, заключается в том, что мне нужно разветвлять разные версии каждого репозитория. Это очень сложно управлять.
источник
Короткий ответ ...
Мое предложение: начать с публичных учетных записей на GitHub и / или Bitbucket (другое?). Добавьте несколько открытых проектов и начните использовать инструменты / интерфейсы. Когда вы почувствуете, что такое сервисы, вы должны понять, каковы ограничения, преимущества и недостатки каждого сервиса. Оттуда вы сможете выбрать лучший путь к просвещению в области контроля версий. :)
Длинный ответ ...
Рассматривали ли вы установить свой собственный клиент Git? Если вы уже платите за веб-хостинг, возможно, имеет смысл использовать этот хост для собственной настройки Git.
Например, мой хост - это WebFaction (нет принадлежности):
Установка веб-приложения Git
Направление этого маршрута может позволить вам сэкономить $$$, особенно. если вы уже платите за хостинг.
Просто чтобы уточнить для других (опять же, нет никакой деловой принадлежности к GitHub или BitBucket):
GitHub: планы и цены
Обратите внимание, что цены на «Бизнес-планы» отличаются.
Ценообразование для Git и Mercurial репо-хостинга для Bitbucket от Atlassian
Как заявил Эндрю в другом ответе, Bitbucket рекламирует неограниченные частные репо.
Не уверен, что именно вы подразумеваете под «иерархически» (возможно, потому что я не знаком с SVN).
Я не уверен, поможет ли это, но вы можете взглянуть на эту таблицу сравнения, чтобы увидеть, как команды сравниваются / отличаются:
Ветвление?
git-flow)Не уверен, поможет ли это, но вы можете взглянуть на:
... опять же, не уверен, что какой-либо из этих инструментов поможет вам понять, что возможно.
Чтобы быть ясным, я не уверен в вашем уровне навыков Git ... если вы новичок в Git / GitHub, использование GUI может быть быстрым / простым способом почувствовать вещи. Мне лично нравится использовать официальный GitHub для приложений Mac / Windows.
На вашем месте я бы использовал репозитории.
Сколько частных репозиториев вам нужно?
Если вы хотите использовать GitHub, одним из решений может быть получение самого дешевого плана и использование нескольких частных репозиториев для хранения всего вашего тестового / закрытого кода. Вы можете просто использовать структуру папок в своей
mainветке, чтобы поддерживать иерархическую структуру, или вы можете использовать несколько веток, чтобы держать вещи более разделенными.Подсказка: если вы используете более свежую версию Git, вы можете получить определенные ветки, используя
git clone -b mybranch --single-branch git://sub.domain.com/repo.git:Однако я должен предупредить вас, что использование ветвей для организации кода (например, папок) на самом деле не лучший способ сделать что-то (хотя нет ничего, что говорило бы, что вы не можете идти по этому пути).
( Смотрите мой ответ здесь для получения дополнительной информации о ветвях GitHub. )
Опять же, я думаю, что несколько репо - это путь.
Вы можете спросить себя, действительно ли ваш код должен быть закрытым; Возможно ли, что вы могли бы обнародовать указанный код без каких-либо последствий?
Если вы идете по этому пути, Dropbox (или аналогичный) может быть хорошим способом получить некоторую форму контроля версий и синхронизации для резервного копирования за пределы сайта.
Это возвращает меня к вопросу «Вы уже платите за хостинг? Если это так, вы можете установить свой собственный хост Git»; преимущество в том, что вы можете иметь весь исходный код под зонтиком Git, даже если он не на одном хосте (то есть использовать GitHub для общедоступного материала, который вы хотите продемонстрировать).
---> Смотрите мой короткий ответ выше. ^^^^^^
источник
Вот что я делаю:
Поместите весь другой код в «мусорное» хранилище. Это может включать в себя код, используемый для изучения и тестирования, а также небольшие фрагменты, которые на самом деле не являются частью проекта. Пока нет причин хранить это в тайне, вы также можете разместить этот репозиторий на GitHub.
В дополнение ко всем обычным преимуществам контроля версий (которые у вас уже есть в SVN), теперь ваш код резервируется онлайн. В случае, если какой-либо ваш ненужный код превращается в проект, вы можете просто раскрутить его в собственное репо.
Вы можете поместить этот код в отдельные репозитории или использовать что-то необычное, например, подмодули git или поддеревья, но я считаю, что проще всего хранить все это в одном репо и упорядочивать его по папкам. Это намного проще, а git достаточно быстр, чтобы размер репо не был проблемой.
источник
Одним из возможных методов будет использование веток.
Ветви в git-репо - это просто указатели на коммиты, они не должны быть связаны друг с другом каким-либо образом. Таким образом, вы можете создать репо «minorprojects» на хостинге, а затем использовать ветку в этом репо для каждого проекта. Если незначительный проект растет, вы можете легко переместить ветку в собственное репо.
Локально вы можете хранить ветки в отдельных локальных репозиториях (между локальными и удаленными репозиториями не должно быть сопоставления 1: 1) или иметь одно локальное репо и использовать рабочее дерево git для поддержки нескольких рабочих деревьев. Лично я подозреваю, что первый подход менее подвержен ошибкам.
источник
git worktreeкоманде, которая позволяет вам создавать дополнительные рабочие деревья для репозитория, позволяя вам проверять несколько веток одновременно. При этом недостатки вашего подхода в основном исчезают: просто создайте рабочее дерево для каждой независимой ветви и используйте их как независимые репозитории. Хорошая идея добавить это к вашему ответу :-)