Комментарии 43
Забавно, насколько иногда сходятся мысли — я тоже начал так делать, и тоже в августе. (Посредине там отпуск, на морько ЭВМ решил не брать. Да, да, я оправдываюсь перед зелеными квадратиками.)
Отличное средство для дополнительной мотивации, в самом деле.
Отличное средство для дополнительной мотивации, в самом деле.
Это немного странно, но интересно. Использовал этот же календарь во время написания текста диплома (в мае), и правда ведь помогал: нужно было каждый день хоть абзац да написать.
GTD по хабровски ;)
Счастливый вы. У меня вот так совместно с работой не получается.
Взгляните на эту картинку трезво, взгляните попристальнее — и Вы увидите, Вы поймёте тотчас же, что Wolf6969 всего-навсего отфотошопил мой календарь.
(А не то, например, цифры были бы под ним другими.)
Счастье ли в этом?
(А не то, например, цифры были бы под ним другими.)
Счастье ли в этом?
А вот с коммитами комментариев на Хабр у автора похуже. Есть места по19 коммитов в один день в последние 100 дней, а есть 0:
(Плотность коммитов любого автора можно посмотреть через юзерскрипт habrActivity.)
(Плотность коммитов любого автора можно посмотреть через юзерскрипт habrActivity.)
http:
коммиты засчитываются только при попадании в основной репозиторий — более того, только в его ветку по умолчанию или в ветку gh-pages
Странно. То есть при политике master = stable держать steak в одиночку, без pull-request самому себе, не получится? напомните старику, какая у гитхаба предпотительная политика по стабильным/дев веткам — я почему-то был уверен что master обычно стабилен — с него же все рекомендуется кланировать?
У самогó Гитхаба — политика GitHub Flow.
И она также (как и календарь) предполагает частые коммиты в master (aka stable).
И она также (как и календарь) предполагает частые коммиты в master (aka stable).
Github Flow, насколько я понимаю, подразумевает master = stable. Правильно ли я понимаю, что если я работаю над проектом в гордом одиночестве и не хочу каждый день радовать пользователей новыми непротестированными коммитами в мастер — то steak мне не светит?
Есть обходные пути.
Во-первых, можно новый код покрывать сразу и тестами. Настроить Travis CI, превратив каждый коммитв master-ветке в протестированный. (Пример.)
Во-вторых, пользователям можно рекомендовать брать итоги Вашего труда не из ветки master, а из источников кода, пополняемых Вами менее часто (в те моменты времени, когда в коде Вы уверены). На самóм Гитхабе для этой цели служит механизм GitHub Releases. У разработчиков модулей для этой цели служат внешние хранилища(в Node.js — npm; в Python — PyPI; в Ruby — RubyGems; ну и так далее).
Во-первых, можно новый код покрывать сразу и тестами. Настроить Travis CI, превратив каждый коммит
Во-вторых, пользователям можно рекомендовать брать итоги Вашего труда не из ветки master, а из источников кода, пополняемых Вами менее часто (в те моменты времени, когда в коде Вы уверены). На самóм Гитхабе для этой цели служит механизм GitHub Releases. У разработчиков модулей для этой цели служат внешние хранилища
Я что-то полгода не заходил в статистику, глянул хоть…
Тогда и я поделюсь =)
Солиднее моего, молодцом!
Раз уж такое дело — тоже есть что показать)
Жаль, только master учитывается
Жаль, только master учитывается
А с чего Вы взяли, что только master?
Your commit contributions are only counted when they are created on or merged into the default branch or gh-pages branch of a non-fork repository.
https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile
Не забывайте, что роль играют только OS проекты. Я вижу ваш профиль иначе:
В апреле отпуск был?
У меня максимум получилось 20 дней, а вот у Qiang Xue, архитектора Yii, наверное, рекорд: github.com/qiangxue
Я натыкался на треки у которых практически все дни были зелёные. Так что ИМХО до рекорда ему далеко :)
а вот у Qiang Xue, архитектора Yii, наверное, рекорд
:)
Я бы, впрочем, предпочел видеть данные по неделям. То есть не за последние 7 дней, а вот прямо по неделям, чтобы с чистой совестью
Согласен с автором на 90% т.к. сам использую такой же подход уже давно. Issues — это тоже шаг вперёд т.к. иногда бывают дни когда писать код не хочется, тогда просто запускается проект и ищутся ошибки в нем, или описываются фичи которые хочется сделать в будущем. Таких дней не много, так что особо плутовством на мой взгляд это не назовешь. Просто другой тип работы.
Вот мой трек:
В июле был отпуск, а предыдущий год «пропал» после смены работы :)
Вот мой трек:
В июле был отпуск, а предыдущий год «пропал» после смены работы :)
Все испортили жесткие дни в июле с >90 коммитами :)
Штука, которая нарисует в вашем календаре что угодно: github.com/gelstudios/gitfiti
Имхо, все-таки важнее что и куда ты коммитишь, нежели то, как часто ты это делаешь.
Имхо, все-таки важнее что и куда ты коммитишь, нежели то, как часто ты это делаешь.
Предложенная вами методика, calendar-driven development, реализуема на практике далеко не всегда. У меня на работе, например, используется достаточно распространенная схема с ветками master-develop и форком основного репозитория. Задачи достаточно крупные, логически и функционально законченные, в большинстве случаев выходящие за рамки 2-3 дней.
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Я знаю, какой буду делать проект на гитхабе — скрипт, чтобы убирать знаки ударения из текстов автора.
Хабр поломал гитхаб? Я вижу розового единорога и сообщение об ошибке :)
Вы меня простите, ибо не моё, но автор LeechCraft просил передать: 
Пожалуй возьму платный аккаунт для своих проектов.
Расскажите лучше о интересных проектах, которые стоит поддерживать.
Текущий мой трек. Это чисто заливы кода, Issue Tracker я не юзаю
Немного моей истории про Форки. Тут было сказано что коммиты не засчитываются в Fork репозитарии. Это верно.
Но бывает это неудобно, когда репозитарий форкнут, но Пуллов в основной репозит не будет. Мое действие — я например в Support, и мне сбросили Fork статус
Но бывает это неудобно, когда репозитарий форкнут, но Пуллов в основной репозит не будет. Мое действие — я например в Support, и мне сбросили Fork статус
40 дней в русской традиции специфическая дата.
Проект еще жив?
Проект еще жив?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Впечатления от сорокá дней ежедневной работы над открытым исходным кодом на Гитхабе