Для чего необходима разработка проекта на GitHub?

Question

[askeet]

Планирую, вести для себя проект , но и не откажусь от помощи со стороны.
Стоит для этого разместить проект на GitHub ?
Да и в общем какие плюсы и минусы всего этого?

У кого есть опыт поделитесь.

Answer 1

[Defman21]

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

Если вдруг что-то случится с Вашим жестким диском, то проект не пропадет.

Из минусов - надо будет смотреть, что коммитишь. Иногда бывает, что в репу закинешь какой-либо файлик с конфигурацией и приходится колдовать над rebase.

Answer 2

[sergey]

Если всерьез планируете заниматься разработкой, то обязательно заливать на github. Github это портфолио разработчика и будущий ваш наниматель не будет там читать какой вы вуз закончили или что нарисовали в резюме, а попросит ссылку на github. Это если коротко.
А если не совсем коротко: то такие инструменты как git и github упрощают жизнь разработчику, не только команде.

Comments

[askeet]

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

[sergey]

askeet: поверьте с git жизнь то интереснее

[askeet]

А на каком языке вести?

[sergey]

askeet: что вести? github/git да и вся разработка только английский. Вы может не правильно поняли: github это не соцсеть:) а ваш код. Язык у кода один.

[askeet]

я имел ввиду комментарии и документация.)

[sergey]

askeet: да как вам удобно, знаете английский пишите на английском, знаете русский - на русском, тут воля ваша

[riot26]

askeet: но всё же очень желательно на английском, у многих компаний СНГ даже внутренние коммиты ведутся на инглише

[askeet]

А грамматикой как ? А то получится своего рода руинглишь.

Answer 3

[Роман]

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

Если делаешь проект один - ГитХаб не нужен. Если нет необходимости создавать несколько версий проекта - тоже не нужен.

Хочешь похвастать проектом перед людьми, ГитХаб в помощь.

Comments

[askeet]

То есть преимущество только в наличии общего репозитория?

[Денис Загаевский]

askeet: Нет, студент-новичок просто ещё не терял свои наработки. Для этого нужен удалённый репозиторий, если ты один. Версионирование и атомарные коммиты - бесценно, можно всегда вернуться назад, если что-то пошло не так, увидеть, где ты накосячил. Использовать github для этого не обязательно, можно воспользоваться приватным bitbucket, например.

[Роман]

Под фразой "сохранять бэкапы" я и имел ввиду сохранение наработок.

[h8nor]

От человеческого фактора никто не застрахован. Иногда просто нужно что-то доработать, - это работа с версиями. Иногда ошибки вылезают через тучу лет. Хранить кучу папок с версиями - это геморой. Удобнее иметь историю изменений и рабочие файлы.

Answer 4

[Павел Селиванов]

Основные ответы уже написали:
1) Возможность поделиться своим решением с сообществом. Если кто-нибудь станет использовать - можно получить фидбек или исправления, Pull Request там сделан очень удобно. Например: я когда-то написал роль ansible для управления конфигурацией IPMI через impitool: ansible_ipmi_lan_manage. Сам я её уже не использую, сплошной IaaS, живём в облаках. Но судя по нескольким звёздочкам и форкам, кому-то она пользу приносит. Вот недавно прислали PR с обновлением синтаксиса, потому что некоторые вещи в нынешнем ansible объявлены obsolete. То есть хотя я её уже ни использую, но сообщество поддерживает, в следующих релизах ansible она продолжит работать. Ещё из bacula_zabbix_integration сделали пару форков и используют, правда PR не присылают, но я её и не хочу поддерживать, сто лет бакулу не трогал.
2) Профиль на гитхабе - это твоё резюме. Особенно актуально для разработчиков, но и для админа полезно.

Хочу добавить, что очень важно ставить для своего кода открытую лицензию: https://help.github.com/articles/open-source-licensing/ Иначе по-умолчанию будут применяться стандартные законы копирайта, и никто не сможет этот код использовать.

Comments

[askeet]

На счет лицензии интересно. Какую посоветуете выбрать изначально?

[Павел Селиванов]

askeet: есть давний холивар между сторонниками "вирусных" лицензий(aka GPL и производные) и "use-any-way-you-want"(BSD-like). Можно нагуглить много аргументов и кидания экскрементами с обоих сторон. Я делаю так: для мелких кусков кода ставлю WTFPL(BSD-like, причём очень простая и понятная :), для чего-то относительно серьёзного - GPL/LGPL/AGPL, чтобы те, кто используют, дальше делились с сообществом наработками.

[askeet]

А если проект, сначала маленький, а затем разрастется ? Пока поставил изначально, как MIT. Но я же в случае чего могу изменить первоначальную лицензию?

[Павел Селиванов]

askeet: сложный вопрос. Пока ведёшь проект один - точно можешь. Если принимал коммиты от других людей - то может потребоваться их согласие. Например, ядро Linux до сих пор под GPLv2 а не GPLv3 в том числе по этой причине.

Можно лицензировать двойной лицензией: OpenSource или проприетарная на выбор. Тогда начиная с любой новой версии проекта лицензию можно поменять, потому что проприетарная такое допускает, и все, кто коммитил в старые версии, соглашались, что проприетарная тоже может применяться. Но старые версии всё равно останутся под той OpenSource лицензией, которая бвла изначально. Там вообще чёрт ногу сломит, для таких вещей специально обученных юристов используют. Лучше сразу ставить правильную лицензию.

ИМХО - GPL/LGPL рулит: нефиг крысить наработки от сообщества, надо вместе дружно пилить софт в светлое будущее :)