які переваги та недоліки розміщення коду незавершеного проекту на github

Я заявляю, що працюю над проектом, який я маю намір випустити як відкритий код через githubs. Які переваги вводити код на github з самого початку, на відміну від очікування, поки проект буде в робочому стані перед публікацією.

Якщо це має значення, цей конкретний проект є додатком / послугою C #, і у мене є лише безкоштовний обліковий запис github (тому я не можу зробити його приватним, а потім відтягнути обкладинки пізніше)

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

У Github повно маленьких та незавершених проектів, тому ваш проект повинен відповідати правильно. Чим більше деталей ви вкладете у файл readme, тим краще, оскільки це допоможе іншим розробникам / споживачам швидко розвинути ваш проект.

Принаймні, ваші приватні проекти повинні перебувати під певним контролем версій. Якщо ви не хочете платити за послугу, рекомендую скористатися Dropbox для резервного копіювання ваших приватних сховищ. Таким чином у вас є резервне копіювання файлів і контроль версій у вашому проекті, що позбавить вас від больових годин у майбутньому. Зовсім недавно GitHub та його конкуренти випустили безкоштовні приватні сховища, тож ви можете користуватися своїм рішенням щодо контролю версій вибору приватно без платної підписки.

Недоліків немає. Поки у вас є файл readme, який чітко стверджує, що проект знаходиться в потоці, ніхто не буде заважати йому, якщо ви внесете неполадки в міру просування проекту.

Є https://bitbucket.org або https://github.com/, якщо ви хочете отримати безкоштовні приватні сховища за допомогою git, і коли ви закінчите, можете перетворити його на загальнодоступне місце.

Короткий відповідь: Ви все одно можете безперешкодно приймати його в Github.

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

Однак, щоб уникнути більшості недоліків , має сенс написати примітку, де згадується, що проект знаходиться на стадії розробки. І які функції, як очікується, будуть функціонувати під час початкового випуску бета-версії.

Я кажу, чому б не мати кращих з обох світів.

Приємна річ у git та децентралізованому керуванні джерелами - це те, що вам не потрібно дотримуватися одного хоста. Ви можете зробити приватне ретро-ретро або github repo та загальнодоступне рето github. Прямо зараз натисніть на зміни до приватного репо, і коли ваш проект буде більш повним (або досягне важливої ​​віхи), ви можете перейти до загальнодоступного репо ... Гітуб

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