Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
P.S. Добавим, что при приёме на работу Github-профиль разработчика зачастую говорит больше, чем его официальное резюме.
Интересно, а как с этим дела обстоят у нас? Кто-нибудь давал ссылку на свой гитхаб-профиль в резюме? Помогло?
не, у нас до сих пор все в лаптях ходют
Когда размещали вакансию, просили указать. Если в github кандидата было что-то адекватное, то было плюсом на собеседовании.
Наши пока требуют готовые проекты. И для веб-программистов такими пока являются готовые сайты. Чтобы можно было «посмотреть и потыкать». Но в целом, добавление ссылки на Гитхаб только улучшит (но не заменит) имидж программиста.
У нас один из программистов, когда заполнял анкету (у нас даже есть вопрос про это), написал.
Вон, сидит напротив и программирует.
Помогло, значит.
Вон, сидит напротив и программирует.
Помогло, значит.
Часто спрашивают на собеседованиях «Есть ли OpenSource проекты (GitHub, Google Code)? Помогаете ли вы развивать чужие проекты: пишете код, фидбэки, репортите баги?». Помощь в OpenSource большой плюс — значит человек разбирается в чужом коде и в тонкостях библиотек (jQuery например) и стремится к развитию.
А ответ «нет» может быть минусом, интересно? Ведь можно разбираться в чужом коде и тонкостях библиотек/фреймворков/систем без коммитов и репортов. Я, скажем, как та собака — всё (почти) понимаю по-английски, но сказать ничего не могу :)
Может, особенно если работа хотя бы косвенно касается опенсорса. Основная причина — если человек с этим работает, и ничего не делает, значит он и не умеет особо работать. С программистами на глухой проприентарщине (а-ля asp) — другое дело, там и проектов-то опенсорсных толком нет, и у бизнеса модель другая.
Но ведь не выкладывать код в паблик != ничего не делать. Простейшая ситуация — делаю наследника класса фреймворка или библиотеки с нужными мне фичами, реализую какой-то интерфейс своим образом, но кажется, что фича настолько уникальна, что даром никому не нужна, например, хранилище данных на плоских файлах, вряд ли ещё кому попадётся заказчик, который настаивает на бесплатных хостингах без мускула :)
Меня спрашивали или я участвую в открытых проектах и просили ссылки на гитхаб и битбакет.
Меня Ализар поразил.
Это первая статья без подоплеки не недоговорок.
Плохо, что в ИТ нет премии аля Нобеля.
За гитхаб было бы не стыдно.
Это первая статья без подоплеки не недоговорок.
Плохо, что в ИТ нет премии аля Нобеля.
За гитхаб было бы не стыдно.
А мне нравиться их раздел справки help.github.com. Рекомендую, как хорошее руководство по Git.
А я обожаю вот эту их страницу github.com/404. По-моему шедевр.
На мой взгляд, гитхабу не хватает полноценной системы багтрекинга (как на bitbucket). Приходится пока что для этого костыли типа google code использовать.
Чем вам это не багтрэкер?
В нем невозможно найти баг, отправленный тобой.
Плохо индексируется гуглом, поиск работает довольно плохо. Инструмент нуждается в доработке.
Баги нельзя назначать. Статусов только два — открыт/закрыт. В общем, это не багтрекер, это список багов, не более.
Фишка GitHub это облегчить общение и доступ к коду проектов для разработчиков. По этому он и называет себя «Social Coding». Думаю они и не стремятся к мощной системе багтрекера. Направление в другом движется проект. Если не нравится трекер, отключай и пользуйся внешним и никаких проблем) По моему правильное решение.
Неудобно это. Там есть зачатки интеграции с багтрекером, и если бы это был полноценный бактрекинг, было бы вообще шикарно. А интеграция заключается в том, что если в коммите есть слова типа «Fixes #123» Или «Closes #312», то система отмечает баг как пофикшенный и добавляет к нему ссылку на коммит.
Так что нормальный багтрекер всё же нужен.
Так что нормальный багтрекер всё же нужен.
> Простая публикация своих хаков
Спорно — вместо присоединения к проекту плодятся десятки клонов, о которых не знает никто кроме их автора…
Спорно — вместо присоединения к проекту плодятся десятки клонов, о которых не знает никто кроме их автора…
Pull requests, anybody?
Мне это тоже кажется спорным. Когда много клонов, в них что-то и есть полезное, наверное, но не каждый же перебирать и смотреть, а что тут интересного. Ветки в меркуриале как-то приятнее выглядят.
клоны — это не «готовые продукты», это попытки развивать какую-то фичу. Даже если она не используется в продакте, она может стать полигоном для отладки идеи или проверке возможности. И оно не сгинет где-то в потрохах домашнего клона репозитория.
Я не к тому что клоны это плохо. Ситуация мне видится следующим образом — вместо того, чтобы создать запрос и прислать патч к проекту, создается клон который допиливается автором до нужного ему (автору) состояния и где-то используется, а в дальнейшем просто забрасывается. Понятно, что разработчики оригинального проекта могут ничего не знают о тех новых фичах которые есть в клоне. Проходит время оригинальный проект развивается, а клон так и остается в том состоянии в котором оставил его автор — разница только в том, что оно сгинет не «где-то в потрохах домашнего клона репозитория», а в потрохах гитхаба.
Да и потом, мы же говорим о гите => самый лучший способ реализовать нужные фичи в локальной копии, и если эта попытка окажется полезной — запостить патч к оригинальному проекту. Даже если код не попадет в оригинальный репозиторий, его полезность намного выше — т.к. когда кому-то понадобится точно такая же фича поиск начнется с трекера проекта. А в то, что кто-то будет специально прерывать весь гитхаб в поисках неизвестного клона от Васи Пупкина я не верю.
Т.о. нет принципиальной разницы (в плане полезности кода) между локальной копией и клоном — обе практически бесполезны как для самого проекта так и для остальных пользователей (повторюсь — про старение кода тоже не нужно забывать, вероятность того что клон будет поддерживаться в актуальном состоянии не слишком высока).
(за кадром — есть ли доверие к Васиному коду? Почему тогда он не включен в проект? ...)
Да и потом, мы же говорим о гите => самый лучший способ реализовать нужные фичи в локальной копии, и если эта попытка окажется полезной — запостить патч к оригинальному проекту. Даже если код не попадет в оригинальный репозиторий, его полезность намного выше — т.к. когда кому-то понадобится точно такая же фича поиск начнется с трекера проекта. А в то, что кто-то будет специально прерывать весь гитхаб в поисках неизвестного клона от Васи Пупкина я не верю.
Т.о. нет принципиальной разницы (в плане полезности кода) между локальной копией и клоном — обе практически бесполезны как для самого проекта так и для остальных пользователей (повторюсь — про старение кода тоже не нужно забывать, вероятность того что клон будет поддерживаться в актуальном состоянии не слишком высока).
(за кадром — есть ли доверие к Васиному коду? Почему тогда он не включен в проект? ...)
я вижу словосочетание «pull request» вас не заинтересовало, дам ссылку — help.github.com/pull-requests/
вкратце, это и есть «запостить патч»
вкратце, это и есть «запостить патч»
Вы плохо разобрались в Гите. Это отличный инструмент. И форки — это тоже отлично. Ты можешь реализовать серьёзную функциональность и бросить её автору проекта. К примеру, я форкнул одну игрушку и полностью перевёл фронтенд с SVG на Canvas, потом сделал пул-реквест. Там было много коммитов, в отдельной ветке, а потом мы просто слили эти проекты.
Или, к примеру, я хотел воспользоваться Packager, но мне не очень понравилось, что в нём надо указывать список файлов. А сам проект уже не поддерживается. Среди пул-реквестов я быстро нашёл форк товарища slik и, в итоге, я все, кому я рекомендовал этот продукт — пользовались его версией. И если автор вдруг образумится и вернётся к разработке, то он просто смерджит свою ветку и ветку slik'a
На форках можно делать и другие вещи. Мы с коллегой не знаем, как лучше реализовать одну функциональность. Он форкает мой проект и каждый из нас реализовывает свой вариант, потом сравниваем, тестим, выбираем лучший, мерджим.
Но самое главное, что форки — это не отдельные проекты, а просто ответвления одного и того же.
Или, к примеру, я хотел воспользоваться Packager, но мне не очень понравилось, что в нём надо указывать список файлов. А сам проект уже не поддерживается. Среди пул-реквестов я быстро нашёл форк товарища slik и, в итоге, я все, кому я рекомендовал этот продукт — пользовались его версией. И если автор вдруг образумится и вернётся к разработке, то он просто смерджит свою ветку и ветку slik'a
На форках можно делать и другие вещи. Мы с коллегой не знаем, как лучше реализовать одну функциональность. Он форкает мой проект и каждый из нас реализовывает свой вариант, потом сравниваем, тестим, выбираем лучший, мерджим.
Но самое главное, что форки — это не отдельные проекты, а просто ответвления одного и того же.
> Вы плохо разобрались в Гите.
Да, возможно, пользуюсь я им не очень часто. Но еще раз повторюсь — я не против клонов/фоков и очень рад если они в конечном итоге позволяют сделать проект лучше.
Но вы же не будете отрицать того, что не все будут слать пул-реквесты? Возьмем, например, первый попавшийся проект:rails, форков — 1347, запросов — всего 199 (скорее всего я их не все нашел? + часть, возможно, были слиты без запросов). Более тысячи форков не влились и скорее всего не вольются в основной проект — тогда какая разница в том где они: на гитхабе или в локальной копии?
Посмотрите с другой стороны — если вы хотите чтобы ваш патч был принят вам придется придерживаться принятых в проекте стандартов кодирования и т.д. — т.о. патч предполагает гораздо большую ответственность. Форк же позволяются просто реализовать то что нужно здесь и сейчас — кому кроме авторов нужны подобные поделки? Никому. И именно поэтому я считаю, что их не должно быть — хочешь что-то по быстрому сделать — сделай, но в своей локальной копии. не нужно выкладывать это в паблик, бессмысленно. Если же, действительно хочешь помочь проекту — сделай нормально и создай запрос (патч ли это будет или пул-реквест не слишком важно. впрочем последнее, возможно, поудобнее).
Да, возможно, пользуюсь я им не очень часто. Но еще раз повторюсь — я не против клонов/фоков и очень рад если они в конечном итоге позволяют сделать проект лучше.
Но вы же не будете отрицать того, что не все будут слать пул-реквесты? Возьмем, например, первый попавшийся проект:rails, форков — 1347, запросов — всего 199 (скорее всего я их не все нашел? + часть, возможно, были слиты без запросов). Более тысячи форков не влились и скорее всего не вольются в основной проект — тогда какая разница в том где они: на гитхабе или в локальной копии?
Посмотрите с другой стороны — если вы хотите чтобы ваш патч был принят вам придется придерживаться принятых в проекте стандартов кодирования и т.д. — т.о. патч предполагает гораздо большую ответственность. Форк же позволяются просто реализовать то что нужно здесь и сейчас — кому кроме авторов нужны подобные поделки? Никому. И именно поэтому я считаю, что их не должно быть — хочешь что-то по быстрому сделать — сделай, но в своей локальной копии. не нужно выкладывать это в паблик, бессмысленно. Если же, действительно хочешь помочь проекту — сделай нормально и создай запрос (патч ли это будет или пул-реквест не слишком важно. впрочем последнее, возможно, поудобнее).
Большинство форков не имеют ни одного коммита. Не знаю, зачем, но люди так делают. Это не недостаток технологии. При этом, делают подобное очень много людей.
Ещё бывает, что форкаешь, хочешь поправить баг или внести патч, но видишь, что не осилишь, или резко пропало время. У людей после этого форк остаётся.
Это не значит, что это плохой инструмент. Просто не надо смотреть на «Форк» в том смысле, в котором приняли видеть его в других технологиях. Это просто «своя ветка» для каждого человека.
Ещё бывает, что форкаешь, хочешь поправить баг или внести патч, но видишь, что не осилишь, или резко пропало время. У людей после этого форк остаётся.
Это не значит, что это плохой инструмент. Просто не надо смотреть на «Форк» в том смысле, в котором приняли видеть его в других технологиях. Это просто «своя ветка» для каждого человека.
Эти семь пунктов с некоторыми оговорками справедливы и для Google Code и для sourceforge.net
У меня была идея предложить писать все дипломы наши кафедральные на github или другом подобном сервисе, кому что религия позволяет.
Диплом то программиский и открытость и контроль научнику, и обсуждение если проект дельный и вдруг кто патч предложит, если кто-то форкнет. Но идея не вызвала бурного обсуждения. А могло бы быть интересно
Диплом то программиский и открытость и контроль научнику, и обсуждение если проект дельный и вдруг кто патч предложит, если кто-то форкнет. Но идея не вызвала бурного обсуждения. А могло бы быть интересно
Не забывайте, что github умеет хостить также html странички вашего проекта. pages.github.com/
Вот пример проекта который хостится на github jashkenas.github.com/coffee-script/
Вот пример проекта который хостится на github jashkenas.github.com/coffee-script/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Семь аспектов, как Github изменил мир Open Source