Як я можу організувати персональні сховища Git?

Я зараз налаштовую обліковий запис GitHub з планом створення пари бібліотек, які я розробив як частини деяких останніх проектів iOS, вільно доступних для інших iOS-розробників.

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

Чи є щось, чого мені не вистачає, що дозволило б мені використовувати сховище git з ієрархією та перевіряти фрагменти, як мені це потрібно / працювати з ними, як я зараз роблю зі SVN?

Чи має GitHub (або конкурент, як BitBucket) якісь функції організації проекту, які мені відсутні?

Якщо цього не зробити, який загальноприйнятий "Git спосіб" вирішення цієї ситуації (відмовитися від проектів, не призначених для випуску, зберігати їх в автономному режимі, зв'язати їх якось разом і т. Д. Тощо)?

Наскільки я можу сказати, мої варіанти:

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

bitbucket.org дозволяє створювати необмежену кількість приватних репостів.

Git не дозволяє перевірити лише деякі фрагменти коду. Отже, вам потрібно створити репо для кожного проекту або вирішити питання щодо клонування всіх проектів. Насправді я не бачу проблем із тим, щоб об'єднати всі наші маленькі проекти в єдиний репо. Ви клонуєте його один раз, і ви закінчите.

З Git вам ніколи не доведеться "перевіряти" код ще раз, якщо ви не підірвете місцеве репо або не переїдете на іншу машину. Ви просто синхронізуєте всі свої зміни.

У мене є симулятор з великою кількістю сховищ. Причина, що я не можу зберігати їх у одному сховищі, полягає в тому, що мені потрібно розгалужувати різні версії кожного сховища. Керувати дуже важко.

Коротка відповідь ...

Моя пропозиція: почніть з публічних облікових записів на GitHub та / або Bitbucket (інших?). Створіть кілька публічних проектів і почніть використовувати інструменти / інтерфейси. Як тільки ви відчуваєте послуги, то вам слід зрозуміти, які обмеження, переваги та недоліки кожної служби є. Звідти ви зможете вибрати найкращий шлях до просвітлення контролю версій. :)

Довга відповідь ...

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

Чи планували ви встановити власний клієнт Git? Якщо ви вже платите за веб-хостинг, можливо, буде доцільно використовувати цей хост для власної установки Git.

Наприклад, мій хост - це WebFaction (без належності):

Встановлення веб-програми Git

Заголовок цього маршруту може допомогти вам заощадити $$$, esp. якщо ви вже платите за хостинг.

GitHub не тільки стягує приватне сховище,

Просто для уточнення для інших (знову ж таки, жодної приналежності до GitHub чи BitBucket):

GitHub: Плани та ціни

• $ 7 / міс. для до 5 приватних сховищ , необмежено все інше.
• $ 12 / міс. для до 10 приватних сховищ , необмежено все інше.
• $ 12 / міс. для до 20 приватних сховищ , необмежено все інше.

Зауважте, що ціни на "Бізнес-плани" різні.

Ціни на Git і Mercurial repo хостинг для Bitbucket від Atlassian

Як заявив Ендрю в іншій відповіді, Bitbucket рекламує необмежену кількість приватних репостів.

• 5 користувачів: Безкоштовно
• 10 користувачів: $ 10 / міс.
• 25 користувачів: $ 25 / міс.
• 50 користувачів: $ 50 / міс.
• 100 користувачів: $ 100 / міс.
• Необмежено 200 доларів США / міс.

Схоже, немає способу ієрархічної організації сховищ.

Не впевнений, що саме ви маєте на увазі під "ієрархічно" (можливо, тому, що я не знайомий з SVN).

Я не впевнений, чи допоможе це, але ви можете подивитися в цій таблиці порівняння, щоб побачити, як команди порівнюють / відрізняються:

• Гіперполіглот: контроль версій

Чи є щось, чого мені не вистачає, що дозволило б мені використовувати сховище git з ієрархією та перевіряти фрагменти, як мені це потрібно / працювати з ними, як я зараз роблю зі SVN?

Відгалуження?

• Успішна модель розгалуження Git (ака, git-flow)
• Блог GitHub: Потік GitHub у браузері

Чи має GitHub (або конкурент, як BitBucket) якісь функції організації проекту, які мені відсутні?

Не впевнений, чи це допоможе, але ви можете поглянути:

• Клієнти GUI

Git поставляється із вбудованими інструментами графічного інтерфейсу для здійснення ( git-gui ) та перегляду ( gitk ), але є кілька сторонніх інструментів для користувачів, які шукають особливості роботи на платформі.

... знову ж таки, не впевнений, чи може хтось із цих інструментів допомогти вам зрозуміти, що можливо.

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

Якщо цього не зробити, який загальноприйнятий "git спосіб" вирішення цієї ситуації (відмовтеся від проектів, не призначених для випуску, зберігайте їх у режимі офлайн, зв'язуйте їх якось разом і т. Д. Тощо)?

Якби я був ти, я використовував би сховища.

Скільки приватних сховищ вам потрібно?

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

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

• Клоніруйте лише одну гілку
• Як клонувати одну гілку в git?

Я маю попередити вас, хоча використання гілок для організації коду (наприклад, папок) насправді не найкращий спосіб вчинити (хоча нічого, що говорить, що ви не можете очолити цей маршрут).

( Зверніться до моєї відповіді тут щодо пов’язаної інформації стосовно філій GitHub. )

Знову ж таки, я думаю, що багато репостів - це шлях.

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

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

Якщо ви прямуєте цим маршрутом, Dropbox (або подібний) може бути хорошим способом отримати певну форму контролю версій та синхронізацію для резервного копіювання поза сайтом.

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

Це повертає мене до питання "Ви вже платите за хостинг? Якщо так, ви можете встановити власний хост Git"; Перевагою є те, що ви можете мати весь вихідний код під парасолькою Git, навіть якщо це не все на одному хості (тобто використовуйте GitHub для публічних речей, які ви хочете показати).

Розмістіть усе на [GitHub та / або BitBucket], вирішіть, чи матимете якусь смішну кількість сховищ, шукаючи те, що мені потрібно / підтримуючи деякий офлайн-набір покажчиків у моєму обліковому записі [GitHub та / або BitBucket] (потрійна вибірка)

---> Дивіться мою коротку відповідь вище. ^^^^^^

Ось що я роблю:

• Розмістіть окремі проекти, які ви хочете оприлюднити, в окремих репортажах GitHub . Оскільки GitHub на даний момент фактично є місцем для спільного використання коду, це зробить ваші проекти більш відкритими / простішими для розкрутки.
• Для будь-яких проектів, які ви хочете зберегти приватними, розмістіть їх у приватних репортажах, розміщених вашим постачальником послуг. Як вже було сказано, Bitbucket є хорошим вибором для цього, оскільки він дозволяє необмежену кількість приватних репостів.

• Помістіть увесь інший код у репо "сміття". Це може включати код, який використовується для вивчення та тестування, а також невеликі фрагменти, які насправді не є частиною проекту. Поки немає причин зберігати цю приватну інформацію, ви можете розмістити цю репо на GitHub.

  Окрім усіх звичних переваг управління версіями (які ви вже маєте зі SVN), ваш код тепер резервний в Інтернеті. Якщо будь-який ваш непотрібний код перетвориться на проект, ви можете просто відкрутити його у власне репо.

  Ви можете помістити цей код в окремі репозиції або використовувати щось фантазійне, як підмодулі git або subtrees, але я вважаю, що найпростіше просто зберегти все це в одному репо і організувати його за допомогою папок. Це набагато простіше, а git досить швидкий, що розмір репо не повинен бути проблемою.

  • Наприклад, ось моя: https://github.com/bmaupin/junkpile
  • Ще кілька:
    • https://github.com/voltagex/junkcode
    • https://github.com/jivoi/junk
    • https://github.com/infnty/junkyard

Однією з можливих методик було б використання гілок.

Гілки в git repo - лише вказівки на коміти, вони не повинні жодним чином пов'язувати один одного. Таким чином, ви можете створити репортаж "мінорпроектів" на хостинговій службі, а потім використовувати гілку в цьому репо для кожного проекту. Якщо незначний проект зростає, ви можете легко перемістити відділення до власного репо.

Місцево ви можете або тримати гілки в окремих місцевих репортах (не повинно бути 1: 1 зіставлення між локальними та віддаленими репостами), або мати єдине місцеве репо-репортаж і використовувати git worktree для підтримки декількох працюючих дерев. Особисто я підозрюю, що перший підхід менш схильний до помилок.