Комментарии 33
Странно, выглядят этот Stash и Bitbucket очень похоже, странно что codebase разный.
А сколько у вас человек из команды используют code-review Stash'a?
От Аркадии к Аркадии ;):
Билды нужны для интеграции с любой системой continuous integration/continuous deployment системой. У нас оно «успешно» интегрируется с Jenkins, при этом мы используем мной улучшенный хук Reject merge on Broken Build. Таким образом у нас реализован Stop the line — пока не пофиксят имеющуюся проблему, нового накидать в мастер нельзя
Если вы посмотрите Get git right презенташку, к примеру, там будет рассказано как именно выбираются те девелоперы, которые Stash вам предлагает как ревьюеров — обычно это довольно хорошо работает.
upd и про Gitflow — опять же рекомендую посмотреть презенташку Get git right — они там дают примеры как минимум четырёх workflow и все они имеют свой смысл и свою применимость.
Билды нужны в случае интеграции с Bamboo — например, чтобы гарантировать, что в этом бранче никто не сломал юнит-тесты.
Видимо, количество успешных билдов имеет смысл только в случае наличия отдельно запускаемых performance (или других, занимающих относительно долгое время и потому не выполняющихся на каждый коммит) тестов в отдельном билде. Ну, я не придумал другого применения :)
Билды нужны для интеграции с любой системой continuous integration/continuous deployment системой. У нас оно «успешно» интегрируется с Jenkins, при этом мы используем мной улучшенный хук Reject merge on Broken Build. Таким образом у нас реализован Stop the line — пока не пофиксят имеющуюся проблему, нового накидать в мастер нельзя
Девелопер создает PR и назначает ревьюверов. Назначает руками, случайным образом из списка, увы, нельзя.
Если вы посмотрите Get git right презенташку, к примеру, там будет рассказано как именно выбираются те девелоперы, которые Stash вам предлагает как ревьюеров — обычно это довольно хорошо работает.
upd и про Gitflow — опять же рекомендую посмотреть презенташку Get git right — они там дают примеры как минимум четырёх workflow и все они имеют свой смысл и свою применимость.
А это с какой версии Stash начал предлагать ревьюверов? Мы как в начале 2014-го 2.x поставили так еще и не обновились на 3-ю.
У нас стоит Atlassian Stash v3.4.1 на данный момент. С какой — не знаю. Но очень удобно, поскольку предлагает «тех кто недавно менял тот код, что изменён в данном PR» и, кажется, тех кого ты добавлял в последний раз. В итоге в пару кликов… Если есть желание посмотреть — nikolay.bukharev@arcadia.spb.ru :)
Очень многие для хостинга проектов и ревью в одном флаконе используют GitLab — бесплатно и опенсорсно (но можно и платно при желании).
Gitlab крайне неудобен для code review. Коментарии привязаны к комитам а не к merge request, если разработчик обновляет свой бранч с push -f (чтобы не плодить бессмысленные комиты), старые коментарии теряются.
Пару лет назад отказались от гитлаб из за дикого количества багов в нем.
Пару месяцев назад выбирал между Stash и GitLab. По функционалу очень схожи. Нужный нам функционал есть и там и там. Мне ближе показался Stash (возможно, потому что очень нравится BitBucket), но руководство выбрало GitLab, так как он бесплатный.
Недавно перешли с Github Enterprise на Stash. Субъективно — после GitHub очень тяжело привыкать к отсутствию мелочей, которые были почти незаметны, пока они были на гитхабе. Первое что приходит в голову — «размер» PR в удаленных/добавленных строках, сворачивание неактуальных комментариев к коду (даже если код уже изменен, комментарий продолжает висеть в Overview, а в gh помечался как outdated и сворачивался).
Тоже самое. Пока сидели на гитхабе не было даже желания что то менять. Переехали на стэш сразу всплыло куча мелких недочетов:
— интерфейс какой то большой
— размер шрифтов не сбалансированный, где то большой где то мальнький
— не актуальные комиты не сворачивается
— нет дифа простыней
— в пр даже поиска/сортировки нет
— выделение бранча по дабл клику не работает в пр, а по тройному выделяется пол экрана
— в настройках не возможно выделить урл репозитария (да я знаю что можно из меню клонировать, но там он пихает имя юзера, а оно мне не надо)
И это я только вечер с ним провёл :)
V3.5.0
— интерфейс какой то большой
— размер шрифтов не сбалансированный, где то большой где то мальнький
— не актуальные комиты не сворачивается
— нет дифа простыней
— в пр даже поиска/сортировки нет
— выделение бранча по дабл клику не работает в пр, а по тройному выделяется пол экрана
— в настройках не возможно выделить урл репозитария (да я знаю что можно из меню клонировать, но там он пихает имя юзера, а оно мне не надо)
И это я только вечер с ним провёл :)
V3.5.0
Когда я пробовал Stash — мне не хватило самого простого баг-трекера. Понятно, что есть JIRA, но не всем она нужна. Вполне хватило бы механизма обсуждения из PR. В общем как на гитхабе сделано.
Плюс он очень требовательный по ресурсам, на vps за 20$ на DO он заводился минут 20 и еще через 20 лег.
Плюс он очень требовательный по ресурсам, на vps за 20$ на DO он заводился минут 20 и еще через 20 лег.
Начали использовать Phabricator.
Пока непонятно, но как-то стало слишком много бюрократии.
До этого не использовали инструменты для code review.
Пока непонятно, но как-то стало слишком много бюрократии.
До этого не использовали инструменты для code review.
GitLab
Спасибо за статью, и хочется немного добавить.
Вы лукавите в той, части, где говорите о ветвлении. У вас есть возможность выбрать тип автоматического flow, которое поддерживает stash — gitflow, forking (feature branch собственно его разновидность). Часто gitflow совершенно избыточен. По большому счёту flow в stash даёт вам только созданные автоматически ветки (вы сами выбираете, что вам нужно). Вся прелесть их открывается при использовании вместе с jira — вы в 1 клик можете создать ветку для решения проблемы или создания новой фичи. При этом имя ветки формируется на основе версий в которой проблема найдена и в какой версии планируется релиз. Всё вместе позволяет включить автоматический merge для gitflow (на текущий момент, насколько знаю работает только для него). В том числе очень удобная история с тем, что смерджив реквест вы можете настроить автоматические закрытие тикета в джире.
В stash можно запретить прямые комиты в ветки — и в 2 и 3 версиях. Это делается в branch permissions.
Чем сейчас stash не удобен:
— если ваши ревью затрагивают несколько проектов, то fisheye предпочтительнее, т.к. ревью в stash это только возможность оставить свои комментарии к пул реквесту. Не более того.
— в stash ваши комментарии удаляются из текста файла в diff после любого комита, затрагивающего этот файл. Фактически это приводит к тому, что в не можете эффективно посмотреть, исправлено ли ваше замечание или что писали другие ваши коллеги. Т.е. к примеру вы в троем оставили в файле 4 комментария, автор исправляет замечание по одному из них и комитит. Всё, все остальные комментарии ему и читателям доступны только в activity stream.
— в stash по прежнему нет цитирования кода в комментариях — нужно копировать и вставлять куски руками.
— в stash по прежнему нет возможности посмотреть диапазон комитов в файле. Только «было» и «стало». Возможно я просто зажрался, но когда смотришь большие объемы изменений этого очень не хватает.
— из серии «очень хотелось бы» это подсветка синтаксиса, которая очень помогает в fisheye. Plain text и код с подсветкой всё таки совсем разная степень удобства. Подсветки синтаксиса в stash сейчас нет, есть классическая подсветка «удаленный фрагмент» и «добавленный фрагмент» для дифа.
Я считаю, что рассматривать stash как отдельный инструмент для ревью кода рановато. Как реализация git scm он просто прекрасен. В нём с самого начала есть (и остаются) проблемы с большими репозитариями (очень выжирает память на клоне и пуле), но всем всё равно советую попробовать.
p.s. Сами для ревью используем и fisheye и stash. Stash для небольших пул реквестов, fisheye для больших изменений или случаев, когда 1 тикет затрагивает более 2-3 репозитариев.
Вы лукавите в той, части, где говорите о ветвлении. У вас есть возможность выбрать тип автоматического flow, которое поддерживает stash — gitflow, forking (feature branch собственно его разновидность). Часто gitflow совершенно избыточен. По большому счёту flow в stash даёт вам только созданные автоматически ветки (вы сами выбираете, что вам нужно). Вся прелесть их открывается при использовании вместе с jira — вы в 1 клик можете создать ветку для решения проблемы или создания новой фичи. При этом имя ветки формируется на основе версий в которой проблема найдена и в какой версии планируется релиз. Всё вместе позволяет включить автоматический merge для gitflow (на текущий момент, насколько знаю работает только для него). В том числе очень удобная история с тем, что смерджив реквест вы можете настроить автоматические закрытие тикета в джире.
В stash можно запретить прямые комиты в ветки — и в 2 и 3 версиях. Это делается в branch permissions.
Чем сейчас stash не удобен:
— если ваши ревью затрагивают несколько проектов, то fisheye предпочтительнее, т.к. ревью в stash это только возможность оставить свои комментарии к пул реквесту. Не более того.
— в stash ваши комментарии удаляются из текста файла в diff после любого комита, затрагивающего этот файл. Фактически это приводит к тому, что в не можете эффективно посмотреть, исправлено ли ваше замечание или что писали другие ваши коллеги. Т.е. к примеру вы в троем оставили в файле 4 комментария, автор исправляет замечание по одному из них и комитит. Всё, все остальные комментарии ему и читателям доступны только в activity stream.
— в stash по прежнему нет цитирования кода в комментариях — нужно копировать и вставлять куски руками.
— в stash по прежнему нет возможности посмотреть диапазон комитов в файле. Только «было» и «стало». Возможно я просто зажрался, но когда смотришь большие объемы изменений этого очень не хватает.
— из серии «очень хотелось бы» это подсветка синтаксиса, которая очень помогает в fisheye. Plain text и код с подсветкой всё таки совсем разная степень удобства. Подсветки синтаксиса в stash сейчас нет, есть классическая подсветка «удаленный фрагмент» и «добавленный фрагмент» для дифа.
Я считаю, что рассматривать stash как отдельный инструмент для ревью кода рановато. Как реализация git scm он просто прекрасен. В нём с самого начала есть (и остаются) проблемы с большими репозитариями (очень выжирает память на клоне и пуле), но всем всё равно советую попробовать.
p.s. Сами для ревью используем и fisheye и stash. Stash для небольших пул реквестов, fisheye для больших изменений или случаев, когда 1 тикет затрагивает более 2-3 репозитариев.
Говорят, что добавили подвсетку — blogs.atlassian.com/2014/12/stash-comment-likes-syntax-highlighting/
Про прямый коммит (кстати, вот issue — jira.atlassian.com/browse/STASH-2910): в branch permissions можно запретить всем запись в бранч, но тогда никто и на merge нажать не сможет, то есть все-равно нужен один генерал с большими правами.
Про прямый коммит (кстати, вот issue — jira.atlassian.com/browse/STASH-2910): в branch permissions можно запретить всем запись в бранч, но тогда никто и на merge нажать не сможет, то есть все-равно нужен один генерал с большими правами.
Да, действительно, с 3.5 появилась. Правда jira.atlassian.com/browse/STASH-2823 они пока даже не запланировали :( нас много QML в ревью, а для него имеющиеся в CodeMirror схемы не особо подходят. Насколько я понимаю, чтобы добавить кастомную подсветку нужно кинуть пул реквест в CodeMirror и ждать очередного релиза обоих продуктов или патчить сам stash? Вы не знаете?
не знаю, но выглядит именно так. Максимум можно выбрать подсветку для кастомных расширений и MIME-типов — confluence.atlassian.com/display/STASHKB/Configuring+syntax+highlighting+for+file+extensions
> Из серии «очень хотелось бы» это подсветка синтаксиса, которая очень помогает в fisheye
Собственно одна из самых главных фич Upsource, кстати, это IDEA-like навигация по коду и подсветка синтаксиса — go to definition, find usages и т.д.
Собственно одна из самых главных фич Upsource, кстати, это IDEA-like навигация по коду и подсветка синтаксиса — go to definition, find usages и т.д.
Подскажите, пожалуйста, можно ли эту замечательную софтину натравить на свой git сервер? А если нельзя, есть ли решения подобной задачи: изменения одного разработчика всегда должны проходить ревью другого, но еще до попадания в удаленный репозиторий, в идеале даже без создания на нем ветки, чтобы проверяющий видел только дифф локальной ветки другого программиста с удаленной?
Если задача не особо понятна, могу попробовать расписать получше. Очень хочется советов и предложений :)
Если задача не особо понятна, могу попробовать расписать получше. Очень хочется советов и предложений :)
В GitLab'е, например, можно запрещать определённым ролям пользователей пушить в определённые ветки, (например пушить рядовым разработчикам в master), им можно будет только пушить в свои ветки и создавать Merge Request'ы, которые пользователи с правами покруче могут review'ить и принимать.
Нет, Stash так не натравливается :) посмотрите Gerrit, опыта использования нет, но вроде бы именно такую проблему он и решает, без создания веток
Fisheye для ревью, SVN/TFS как центральные репозитории, и Git на локальной машине.
Кстати, тут ещё один велосипед пишется. Правда, пока ещё альфа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процесс Code Review с Atlassian Stash