Комментарии 65
Если первый пункт не критичен, лучше выбрать Stash (тоже от Atlassian). Оно того стоит.
Stash дорого. $1800 на 11 человек.
$1800 это на 25 человек. А на 10 — всего $10.
Для минусующих объясняю:
ТС платит $10 в месяц за Bitbucket. Это тариф для 10 участников.
Stash для этого же количества мемберов — так же $10. И внимание — One-time payment. Не ежемесячно.
Но да, если нужно будет на одного участника больше — резкий рывок к $1800.
ТС платит $10 в месяц за Bitbucket. Это тариф для 10 участников.
Stash для этого же количества мемберов — так же $10. И внимание — One-time payment. Не ежемесячно.
Но да, если нужно будет на одного участника больше — резкий рывок к $1800.
Stash «опасен» тем, что за год количество участников может превысить 10 (а если есть группа, то сама группа тоже считается как участник) и потом придётся раскошелиться до $1800
Вы не пробовали ПРОДЛИТЬ продукты Atlassian, купленные за 10$? Вас ждет неприятный сюрприз. Или — отсутствие обновлений.
Справедливости ради надо отменить, что при желании можно купить все заново по 10$ на другую карточку, установить все на чистые базы, и путем замены Server-ID в существующих БД/конфигах на новый (для каждого из продуктов) получить еще год почти-бесплатных обновлений
Не могли бы, пожалуйста, поделиться сакральным знанием какие сюрпризы ожидают тех, кто захочет продлить лицензию?
На сайте у них вроде бы как английским по белому написано что это можно сделать за те же 10$
На сайте у них вроде бы как английским по белому написано что это можно сделать за те же 10$
Crowd starter обновляется нормально (в смысле, renew), за те же $10.
Мне только что Stash сказать что появился side-by-side diff, и предложил воспользоваться
Реально всё сводится к 1му моменту :)
2й решается плагинами/скриптами готовыми: chrome.google.com/webstore/detail/side-by-side-diff-view-in/ihmhmdmhllhleioijdeoocgoddjckbcd
3й имеет штатное решение хуком
«кнопка Approved для pull request-а» — у гитхаба автоматический мерж есть для PR
размер в сотни метров на файл — как правило за глаза и за уши
а рус и интерфейс это вещи субьективные и с ними всегда можно жить.
хотя как по мне, то для приватных репозиториев лучше приватный же сервер.
2й решается плагинами/скриптами готовыми: chrome.google.com/webstore/detail/side-by-side-diff-view-in/ihmhmdmhllhleioijdeoocgoddjckbcd
3й имеет штатное решение хуком
«кнопка Approved для pull request-а» — у гитхаба автоматический мерж есть для PR
размер в сотни метров на файл — как правило за глаза и за уши
а рус и интерфейс это вещи субьективные и с ними всегда можно жить.
хотя как по мне, то для приватных репозиториев лучше приватный же сервер.
Пробовал это расширение, не работает оно так как нужно. К сожалению не помню, что именно нас не устроило. К тому же
Не самая лучшая идея заменять необходимый функционал сторонними расширениями, вы так не считаете?
Не самая лучшая идея заменять необходимый функционал сторонними расширениями, вы так не считаете?
ну github.com/KuiKui/Octosplit — исходники есть и публичны :)
Кстати, помнится в gitweb включается sbs-diff легко: gist.github.com/scharan/1274726
и тогда вообще всё получается бесплатно, приватно и секурно.
а еще есть консольное cdiff, кою можно вызывать git difftool; есть meld;
есть еще TortoiseGIT который как раз няшно и гуёво показывает именно как надо.
Кстати, помнится в gitweb включается sbs-diff легко: gist.github.com/scharan/1274726
и тогда вообще всё получается бесплатно, приватно и секурно.
а еще есть консольное cdiff, кою можно вызывать git difftool; есть meld;
есть еще TortoiseGIT который как раз няшно и гуёво показывает именно как надо.
А ещё есть нормальные IDE, например от
реклама
, где side-by-side diff встроен.Jetbrains
Которая стоит денег ;)
Согласен. Но функциональность веб-diff'а c возможностью комментирования это одно, а просмотр diff'а в IDE — другое. В IDE ведь коммент коллеге не напишешь :)
Ну, для таких случаев мы обычно копируем ссылку (в вышеупомянутом IDE — copy reference) вида /project/file.ext:line-number и пользуемся общим чатом. Однако, конечно, когда речь о большом кол-ве комментариев удобнее комментировать в вебе.
P.S. эта же ссылка элементарно вставляется на машине разработчика и тот моментально попадает на нужную строку у себя и исправляет что нужно. В некотором случае это удобнее чем смотреть комментарии в вебе и потом всё-равно возвращаться к тому же месту в своём коде.
P.S. эта же ссылка элементарно вставляется на машине разработчика и тот моментально попадает на нужную строку у себя и исправляет что нужно. В некотором случае это удобнее чем смотреть комментарии в вебе и потом всё-равно возвращаться к тому же месту в своём коде.
Совершенно не разбираюсь в теме, но вроде в последней Visual Studio можно оставлять комментарии:)
Дык ТС говорит, что и в bitbucket не напишешь.
точности ради, есть IDE Talk
Это есть и в EGit для Eclipse. И вовсе без денег :)
Очень люблю продукты от JetBrains, однако diff у них не очень хороший.
У них отличная ТП, если у вас есть конкретные предложения по улучшению — youtrack.jetbrains.com/dashboard#newissue=yes
НЛО прилетело и опубликовало эту надпись здесь
3й имеет штатное решение хуком
github же не поддерживает before push хуки?
чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода
То есть code review у вас есть, а CI сервер с проверкой code style у вас нет? Не цените вы свое время
Вы не учитываете, что у нас не только PHP. Jenkins конечно же работает :)
Да, исправил комментарий. Увидел питон в скринах — pychecker.sourceforge.net/ вот что показывают первые ссылки в гугле.
Да и проверить пробелы/табы можно регулярками, если с используемым языком плохо. Но заставлять это делать ревьювера, даже с плагином — мне кажется странно.
Да и проверить пробелы/табы можно регулярками, если с используемым языком плохо. Но заставлять это делать ревьювера, даже с плагином — мне кажется странно.
Как показывает практика, лучше все же не пропустить плохой код на уровне pull request, чем получить всем начальством на email сообщение от CI о том, что билд сфейлился.
P.S. не факт, что это очень актуально для многих проектов. Но поверьте, учавствуя в разработке такого крупного проекта, как oDesk.com я понял, как полезны pull request'ы. В паре с CI.
P.S. не факт, что это очень актуально для многих проектов. Но поверьте, учавствуя в разработке такого крупного проекта, как oDesk.com я понял, как полезны pull request'ы. В паре с CI.
А что плохого в фейле билда внутри ветки для фичи/правки бага?
Я говорю о мастере.
Думаю вероятность того, что такой фейл билда внутри ветки для фичи может быть незамечен/проигнорирован все же больше, чем того, что его не заметят при код ревью и аппруве пул реквеста.
чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода
Думаю вероятность того, что такой фейл билда внутри ветки для фичи может быть незамечен/проигнорирован все же больше, чем того, что его не заметят при код ревью и аппруве пул реквеста.
Вы с CI работали? Посмотрите любой открытый проект, например github.com/composer/composer/pull/2819
CI сервер проверяет CS, если нужно, прогоняет тесты, учитывя изменения в ветке и результат мержа виден уже внутри PR
CI сервер проверяет CS, если нужно, прогоняет тесты, учитывя изменения в ветке и результат мержа виден уже внутри PR
А на битбакете до сих пор при обновлении бранча нужно обновлять пул-реквест?
По поводу третьего пункта: если каждый разработчик будет иметь свой форк проекта на гитхабе, и делать пул-реквест не из одной ветки origin repo в другую, а из своей ветки в своем репозитории в мастер основного репозитория, то тогда проблемы с доступами легко решаются средствами гитхаба. Плюс это дает больше понимания, над чем трудится каждый человек. Давать всем разработчикам полный доступ на создание веток в основном репозитории не всегда полезно и может привести к бардаку.
А еще CodeReview есть у бесплатного Phabricator.
А почему не Gitlab на каком-нибудь VPS сервере за $5/мес? Если репозитории частные, то может лучше и частный сервер завести?
> подсветка пробелов/табов, чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода
Можно повесить Code Sniffer на хук коммита в репозиторий и проблемы с правилами форматирования кода будут решены. Code Sniffer не пропустит коммиты не по стандарту.
Можно повесить Code Sniffer на хук коммита в репозиторий и проблемы с правилами форматирования кода будут решены. Code Sniffer не пропустит коммиты не по стандарту.
Неужели amend commit — это какая-то сложная концепция? Это вообще была первая фича, которой я дико порадовался при переходе на git с cvs. Просто, элегантно и нужно.
3/4 комментов объясняют вам, почему решение, которое вас устраивает, является неверным. :)
git — локальная VCS, попытка сделать из него веб-редактор кода — возврат к SVN.
github недавно ввёл side-by-side diff
Да слышал, вчера анонсировали. Их side-by-side diff куда более юзабельнее, чем на Bitbucket.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы для code review выбрали Bitbucket, а не GitHub