Comments 65
Если первый пункт не критичен, лучше выбрать Stash (тоже от Atlassian). Оно того стоит.
Для минусующих объясняю:
ТС платит $10 в месяц за Bitbucket. Это тариф для 10 участников.
Stash для этого же количества мемберов — так же $10. И внимание — One-time payment. Не ежемесячно.
Но да, если нужно будет на одного участника больше — резкий рывок к $1800.
Stash «опасен» тем, что за год количество участников может превысить 10 (а если есть группа, то сама группа тоже считается как участник) и потом придётся раскошелиться до $1800
Вы не пробовали ПРОДЛИТЬ продукты Atlassian, купленные за 10$? Вас ждет неприятный сюрприз. Или — отсутствие обновлений.
Справедливости ради надо отменить, что при желании можно купить все заново по 10$ на другую карточку, установить все на чистые базы, и путем замены Server-ID в существующих БД/конфигах на новый (для каждого из продуктов) получить еще год почти-бесплатных обновлений
Не могли бы, пожалуйста, поделиться сакральным знанием какие сюрпризы ожидают тех, кто захочет продлить лицензию?
На сайте у них вроде бы как английским по белому написано что это можно сделать за те же 10$
Прошу прощения за дезинформацию, оказывается лицензии на 10 пользователей у FisheEye бывают как Starter, так и вполне обычными, Commercial. При этом стоимость продления последних больше в 40 раз.
Мне только что Stash сказать что появился side-by-side diff, и предложил воспользоваться
Реально всё сводится к 1му моменту :)

2й решается плагинами/скриптами готовыми: chrome.google.com/webstore/detail/side-by-side-diff-view-in/ihmhmdmhllhleioijdeoocgoddjckbcd

3й имеет штатное решение хуком

«кнопка Approved для pull request-а» — у гитхаба автоматический мерж есть для PR
размер в сотни метров на файл — как правило за глаза и за уши

а рус и интерфейс это вещи субьективные и с ними всегда можно жить.

хотя как по мне, то для приватных репозиториев лучше приватный же сервер.
Пробовал это расширение, не работает оно так как нужно. К сожалению не помню, что именно нас не устроило. К тому же

image

Не самая лучшая идея заменять необходимый функционал сторонними расширениями, вы так не считаете?
ну github.com/KuiKui/Octosplit — исходники есть и публичны :)

Кстати, помнится в gitweb включается sbs-diff легко: gist.github.com/scharan/1274726
и тогда вообще всё получается бесплатно, приватно и секурно.

а еще есть консольное cdiff, кою можно вызывать git difftool; есть meld;
есть еще TortoiseGIT который как раз няшно и гуёво показывает именно как надо.
А ещё есть нормальные IDE, например от
реклама
Jetbrains
, где side-by-side diff встроен.
Строго говоря, не обязательно — есть же и Community Edition, и Ultimate Edition с Open Source License. Но в большинстве случаев (т.е. если проекты с закрытыми исходниками и в областях, не покрываемых Community Edition) — да, стоит денег.
Согласен. Но функциональность веб-diff'а c возможностью комментирования это одно, а просмотр diff'а в IDE — другое. В IDE ведь коммент коллеге не напишешь :)
Ну, для таких случаев мы обычно копируем ссылку (в вышеупомянутом IDE — copy reference) вида /project/file.ext:line-number и пользуемся общим чатом. Однако, конечно, когда речь о большом кол-ве комментариев удобнее комментировать в вебе.

P.S. эта же ссылка элементарно вставляется на машине разработчика и тот моментально попадает на нужную строку у себя и исправляет что нужно. В некотором случае это удобнее чем смотреть комментарии в вебе и потом всё-равно возвращаться к тому же месту в своём коде.
Кстати, для того же IDE был даже где-то плагин IDE-jabber. Хоть он был весьма уныл, но идея хорошая.
Совершенно не разбираюсь в теме, но вроде в последней Visual Studio можно оставлять комментарии:)
Напишешь. Нельзя написать в режиме Side-by-Side, однако в обычном режиме (как на GitHub) всё пишется как обычно.
Вот только он с символьными ссылками не умеет работать. Постоянно предлагает добавить в индекс файлы из ссылки на директорию.
Очень люблю продукты от JetBrains, однако diff у них не очень хороший.
Я отписывал им о найденных багах, но видимо отсутствие голосов делает свое дело.
У меня прямо противоположная история — все те немногие баги (именно баги, а не пожелания по улучшению), которые у меня получалось найти, исправлялись _очень_ быстро (десятки минут и единицы часов). Но это если говорить о самой IDE, с плагинами ситуация похуже, а часто и заметно хуже.
3й имеет штатное решение хуком
локальным штоле? это, конечно, немного лучше чем «не делайте так, иначе сломаю ногу», но не сильно.
ну правильно. это применимо только к подконтрольному серверу. если репозиторий на гитхабе, способа запретить пушить в мастер (или хотя бы запретить non-fast-forward push) таки нет.
3й имеет штатное решение хуком

github же не поддерживает before push хуки?
чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

То есть code review у вас есть, а CI сервер с проверкой code style у вас нет? Не цените вы свое время
Вы не учитываете, что у нас не только PHP. Jenkins конечно же работает :)
Да, исправил комментарий. Увидел питон в скринах — pychecker.sourceforge.net/ вот что показывают первые ссылки в гугле.
Да и проверить пробелы/табы можно регулярками, если с используемым языком плохо. Но заставлять это делать ревьювера, даже с плагином — мне кажется странно.
Именно для того, чтобы тыканьем в табы не занимался reviewer и был написан вышеуказанный userscript.
Автор коммита ДО pull request видит их и исправляет.
Как показывает практика, лучше все же не пропустить плохой код на уровне pull request, чем получить всем начальством на email сообщение от CI о том, что билд сфейлился.

P.S. не факт, что это очень актуально для многих проектов. Но поверьте, учавствуя в разработке такого крупного проекта, как oDesk.com я понял, как полезны pull request'ы. В паре с CI.
Я говорю о мастере.
чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

Думаю вероятность того, что такой фейл билда внутри ветки для фичи может быть незамечен/проигнорирован все же больше, чем того, что его не заметят при код ревью и аппруве пул реквеста.
Вы с CI работали? Посмотрите любой открытый проект, например github.com/composer/composer/pull/2819
CI сервер проверяет CS, если нужно, прогоняет тесты, учитывя изменения в ветке и результат мержа виден уже внутри PR
А на битбакете до сих пор при обновлении бранча нужно обновлять пул-реквест?
По поводу третьего пункта: если каждый разработчик будет иметь свой форк проекта на гитхабе, и делать пул-реквест не из одной ветки origin repo в другую, а из своей ветки в своем репозитории в мастер основного репозитория, то тогда проблемы с доступами легко решаются средствами гитхаба. Плюс это дает больше понимания, над чем трудится каждый человек. Давать всем разработчикам полный доступ на создание веток в основном репозитории не всегда полезно и может привести к бардаку.
Посидел я на оупенсорс тулзах типа redmine, phabricator, gitlab и что-то пришел к выводу, что продукты Atlassian стоят-таки своих денег. Для небольших команд есть недорогая линейка OnDemand, для больших, как мне кажется, цена обычной лицензии не так уж должна быть велика.
А почему не Gitlab на каком-нибудь VPS сервере за $5/мес? Если репозитории частные, то может лучше и частный сервер завести?
Поддерживаю. У нас Gitlab развёрнут в нашей серверной, проблем не ощущаем. Кое-где для интеграции с внутренними процессами допилили код, он там весьма вменяемый. Side-by-side diff там есть :-)
> подсветка пробелов/табов, чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

Можно повесить Code Sniffer на хук коммита в репозиторий и проблемы с правилами форматирования кода будут решены. Code Sniffer не пропустит коммиты не по стандарту.
Неужели amend commit — это какая-то сложная концепция? Это вообще была первая фича, которой я дико порадовался при переходе на git с cvs. Просто, элегантно и нужно.
3/4 комментов объясняют вам, почему решение, которое вас устраивает, является неверным. :)
потому, что диалог получается только при несогласиях. иначе разговоры были бы
> А я сделал А!
>> о! круто! молодцы
>>> да! мы молодцы!
>>>> вы молодцы, что понимаете что молодцы!
>>>>> согласен!
>>>>>> совершенно согласен!
>>>>>>> это не могло быть иначе!
>>>>>>>> вы снова абсолютно правы!
git — локальная VCS, попытка сделать из него веб-редактор кода — возврат к SVN.
не знаю, мне понравилось делать мелкие правки прямо из вебморды гитхаба
BA и QA часто проще в вебе просто подредактировать файл, чем учиться работать с GIT. Особенно BA или копирайтерам.
согласен, читал недавно djbook.ru и нашел ошибку в переводе, сделал пулреквест прямо из браузера, если бы мне пришлось клонить репозиторий сначала, я бы не стал заморачиваться с этим.
Only those users with full accounts are able to leave comments. Log in, please.