Коротка відповідь ...
Почніть із сховищ у вашому особистому обліковому записі. Звідти, якщо / коли щось зростає та / або стає популярним у спільноті, перемістіть їх на обліковий запис організації.
Довга відповідь ...
Давайте розглянемо деякі ваші варіанти:
1. Організація:
Для отримання додаткової інформації про функції організації GitHub обов'язково прочитайте:
Блог GitHub: Представлення організацій
Якщо вам коли-небудь доводилося керувати кількома обліковими записами GitHub, хочете, щоб панель інструментів, орієнтована на компанію, хотіли додати співробітників, які працюють лише для читання, або потрібно, щоб хтось інший надав адміністративний контроль над одним із ваших сховищ, ви любите Організації.
Виходячи з вашого запитання, я не можу сказати, чи підходить вам організація (моя кишка каже мені "ні") , але, можливо, перегляд деяких реальних прикладів допоможе вам прийняти рішення.
Ось кілька прикладів організацій GitHub, які мені цікаві для перегляду:
https://github.com/gruntjs
Це один з моїх улюблених прикладів облікового запису організації з відкритим кодом. Мене найбільше вражають конвенції іменування, які використовуються для сховищ (тобто, по суті, grunt/
це основне репо і всі пов'язані з кодом core / contrib / плагіни / завдання живуть у grunt-xxxx/
сховищах).
https://github.com/github
Напевно, варто переглянути власний Org GitHub. рахунок. Конвенції про іменування, що використовуються для сховищ, не настільки жорсткі, як Grunt (IMHO), але все-таки хороший приклад. О, і зараз, мабуть, пристойний час вказати на вкладку "Члени" , оскільки ви цього не отримуєте для особистих облікових записів чи сховищ.
https://github.com/twbs
Twitter Bootstrap. Я думаю, що це хороший приклад Оргу. обліковий запис лише з декількома сховищами (зверніть увагу на єдине репо з 58 000+ зірками). Також зауважте, що Bootstrap налічує п’ять членів (на момент написання цього запису), проте ці п’ять відповідальні за шалено популярне сховище (на відміну від 214 членів організації GitHub ).
- https://github.com/twitter : головний обліковий запис Twitter GitHub.
Ще кілька загальних прикладів:
https://github.com/yeoman : Інструменти побудови.
https://github.com/h5bp : HTML5.
https://github.com/nprapps : Приклад галузі новин.
2. Особистий рахунок
Як ви вже згадували, ви можете створити сховища всередині особистого облікового запису і перейти звідти.
Вам потрібні будуть співпрацівники?
Довідка GitHub: Співпраця / Як додати колаборатора?
Як бачите, додавання співпрацівників досить безболісне.
Виходячи з вашого запитання, ця опція звучить як потрібна.
3. Репо з декількома гілками:
Ви можете створити одне сховище та використовувати гілки для організації пов’язаних бітів коду.
Я не думаю, що більшість людей погоджуються, що це найкращий спосіб впорядкувати свій код :
З іншого боку, нічого не говорить про те, що ви не можете організувати пов'язані біти коду за допомогою гілок.
Одне особисте роздратування, яке я маю щодо цієї методики, полягає в тому, що графічний інтерфейс / інтерфейс GitHub покаже вам це повідомлення:
... при перегляді гілок, крім вашої master
(тобто якщо ваша філія вперед / поза в комітах).
Порада. Якщо ви використовуєте більш нову версію Git, ви можете витягнути конкретні гілки за допомогою git clone -b mybranch --single-branch git://sub.domain.com/repo.git
:
Пов'язані:
4. Гібридний підхід:
Чи варто використовувати організацію GitHub для обробки такої конфігурації? Або я повинен просто скинути все це на власний рахунок, а також з десяток інших, абсолютно не пов’язаних сховищ?
Ви можете використовувати комбінацію всього перерахованого. Наприклад:
Створіть організацію для "... загальної демпінгової документації та прикладів, а два інших містять реалізацію двох програм, що складають основу проекту".
Використовуйте свій особистий рахунок для "... десятка інших, абсолютно не пов'язаних сховищ"
Використовуйте гілки для демонстраційних сторінок gh-pages
, відповідного коду та / або документації.
Примітки:
Варто також зазначити, що ви можете використовувати WIKI сховища для цілей документації: