какой инструмент обеспечивает code review bitbucket

Процесс Code Review с Atlassian Stash

Всем привет! Вот и наша компания решила завести блог на Хабре (в конце концов, не вечно же читать чужие статьи). В профиле компании вы можете посмотреть, чем мы занимаемся. В ближайшее время мы предложим вашему вниманию цикл статей по широкому спектру тем: от сервисов дистрибуции и поддержки тестовых сборок iOS приложений до программного управления IIS. А первая наша публикация посвящена Atlassian Stash.

На текущий день на хабре практически отсутствует какая бы то ни было информация об Atlassian Stash (всего один анонс и одна статья на тему установки). Хотя инструмент, на самом деле, прекрасный, и определенно стоящий рассмотрения в случае использования всего стэка Atlassian. Я хочу рассказать что это такое и как эту штуку можно добавить в процесс разработки.

Небольшая предыстория — у нас появился новый заказчик и возможность построить инфраструктуру для разработки практически с нуля. Сразу захотелось сделать «всё правильно» — git/CI/code-review и т.д. Все вроде как согласны, что code-review это важно и нужно, меж тем далеко не все его используют, а если используют, то в основном некую постфактум версию — закоммитил в транк, кто-то позже посмотрел. Где-то по workflow запрещено резолвить задачу, пока кто-нибудь не посмотрел код коммита, ну или другие устно/письменно-оговорённые ограничения. Нам же хотелось сделать процесс более контролируемым с технической точки зрения.

Из решений для / с поддержкой code-review на ум пришли: TFS, Atlassian Stash, Github, Gerrit, новенький Upsource от JetBrains.

Gitflow

Как правильно организовать ветки, чтобы потом не было мучительно больно, уже давно придумано до нас, поэтому на самом workflow останавливаться не буду — просто напишу примерный алгоритм:

Там показано как всё круто интегрируется, но кое-что из всего этого (например, кнопка Start Review) у нас не заработало. Возможно, проблема с версией.

Источник

Better code with Bitbucket: 4 starting steps

Before you begin, you’ll need a Bitbucket Cloud account to follow along in this tutorial yourself. This guide will give you a tour of the parts of Bitbucket you’ll use a lot, so you should also have Git installed and be familiar with basic Git commands and how Git works.

Now, let’s put some bits in your bucket.

Step 1: Put your code in Bitbucket

Repositories (affectionately referred to as ‘repos’ in the biz) are where code lives in Bitbucket. There are a few ways to get started depending on your needs:

Create a new empty repository

Import a repository from another Git provider

Provide the URL where the repository can be accessed.

If your repository requires authorization, tick Requires authorization and provide credentials for access.

Give the repository a name. This is important! The name of a repository will be included in its URL.

You can leave the rest to the defaults and click Import repository.

Step 2: Set up locally, collaborate globally

With your repository living in the cloud, now you need to set up your local system to contribute or change the code living in Bitbucket. This step requires that you have installed and configured Git, so if you skipped that step you’ll want to go back and do this part now. Don’t forget we’ve got an entire separate guide just to help you with this!

Clone a Bitbucket repository

Once created (or imported), to collaborate on making code changes in a Bitbucket repository, you first need to clone the repository to your local system. Read more about Git cloning.

From the CLI

A new sub-directory appears on your local drive with the same name as the repository you cloned. If you cloned an empty repository there might not be anything in that local directory yet.

Make changes to a file in Bitbucket online

Wait, I don’t have any files in Bitbucket.

Did you skip the optional step to add a README file to your Bitbucket repository? That’s okay! If the repository is still empty, go to the repository and create one now by clicking Create a README. Now you’ve got something to clone that’s not an empty repository.

Pull updates from Bitbucket

From the CLI

Now you’ve downloaded any changes made to those files to your local system.

Step 3: Basic branching with Bitbucket

Branching allows each team member to work on a different things simultaneously without affecting the original codebase or each other’s work. When you’re ready to merge the changes, you’ll push your branch to Bitbucket so that it can be reviewed in a pull request.

There are a few ways to create branches, so pick the one that makes the most sense for your team’s needs.

Create a branch

From the CLI

From the CLI, within your local repository directory

Check out the branch. git checkout

Now let’s go to Bitbucket to see our branch.

Go to your repository.

Click Branches.

This does require you have access to Jira Software Cloud, and have it integrated with Bitbucket. You’ll need administrator permissions to do this, but if you just want to play with the integration to see how it works, you can always sign up for your free trial of Jira Software Cloud.

Read Connect Bitbucket Cloud to Jira Software Cloud for instructions on integrating the two products once you have your Jira site set up.

Step 4: Review code changes with a pull request

Once your code changes have been pushed to Bitbucket, it’s time get those changes reviewed by a colleague. Pull requests are a simple and effective way to get your code reviewed and collaborate in a shared environment with your team.

Create a pull request

You can see this pull request from the Pull requests lists in the side navigation of your repository.

Review a pull request

As a reviewer, you’ll get a notification that you have a pull request to review. You can also find open pull requests from the Pull requests tab on your Dashboard. There are a lot of ways to review code for quality assurance, but how your team does them is entirely up to you. Here are some ways to effectively communicate with your colleagues to ensure everyone understands what’s being changed, and approves a change to be merged.

View the diff(erence)
When you view a pull request, you’ll see diffs (the changes) of all files changed in the pull request. Lines shaded in green were added, the ones in red were removed. You can also click the Commits tab at the top of a pull request to see which commits are included, which is helpful for reviewing big pull requests.

Leave feedback and ask questions in comments
In Bitbucket you can leave comments an entire pull request, a specific file, or a specific place within a file. This is handy when you want to provide context or specificity with your feedback. Comments can have images, links, rich text, and have a unique URL so you can share specific comments quickly.

Approve, or Decline, a pull request
Once you’ve reviewed the code changes, you now need to tell the author of the pull request if this pull requests is ready to be merged. Clicking the Approve button sends a notification to the pull request author, and indicates you feel the changes can be safely merged. The opposite is true if you decline a pull request. Once you decline a pull request, it can’t be reopened. To merge the branch you will have to open a new pull request.

Take note that declining a pull request doesn’t feel good for the author, and should probably be reserved only for changes that are way off target, or for work that’s no longer needed. Remember to be kind in reviewing the work of others, and always seek first to understand before seeking to be understood.

Merge a pull request
After your code has been reviewed and approved in a pull request, click the Merge button to merge your branch into the main branch. The code changes from the source branch are now fully incorporated into the target branch.

Источник

Bitbucket’s new code review offers reviewers a fast track to approving changes

Code review is at the heart of building quality software. It’s a critical step to ensure your code won’t cause issues down the line. But in the new world of automation, code review can feel like the slowest part of the software delivery process. It depends on another person taking time out of their day to give you feedback and check your work. Additionally, working within a pull request can be cumbersome and hard to navigate, slowing this process even further.

To solve this, we’ve set out to reimagine code review in Bitbucket from the ground up. And today, we’re excited to share the first milestone with you, a new pull request experience, now available as an opt-in beta feature.

A new code-first design

To help reviewers assess changes quickly, we’ve historically taken a «code first» design approach for the pull request view. Bitbucket displays the diff front and center so reviewers don’t need to click around to see what’s changed and provide feedback.

Today, we’re taking this concept a huge step further: we’ve redesigned the pull request view to display everything the reviewer needs on a single page, without tabs.

Through several rounds of user testing, we optimized the new design around improving navigability for the reviewer. We’ve seen reviewers reduce their time-to-approve by 21% compared to the existing UI.

Let’s check out the key features that help reviewers evaluate changes quickly to help deliver value to your customers faster.

Sidebar with file tree

Just like the sidebar in the new source browser, the pull request sidebar groups information into collapsible cards for quick reference at any time. One of these cards is the brand new file tree for navigating between files in the diff. Now, you can jump between files without having to scroll back to the top of the page:

Files are organized into collapsible folders in a familiar layout, and files are marked with comment counts and conflict markers so they can be addressed. If a filename is truncated, hover over the filename to reveal a tooltip with the full filename or click-and-drag the edge of the sidebar to reveal more of the tree:

You can also collapse and expand the sidebar by clicking on its edge or using the ] keyboard shortcut.

Sticky action header as you scroll

The redesigned header remains sticky to the top as you scroll down the page. Now you can easily approve or merge the PR once you’ve finished reviewing:

Sticky file headers and file tree highlighting as you scroll

Similarly, diff file headers are also sticky to the top of the page as you scroll so you don’t lose your place viewing long diffs. And to further reinforce this, the current file is highlighted in the file tree as you scroll:

Before, it was easy to lose your place when reviewing long or similar files. Now it’s always clear which file you’re viewing.

Collapsible diffs

Each file’s diff is collapsible so you can mark your progress and reduce scrolling as you move through the review.

And each diff’s side-by-side view is now available inline, instead of in a modal window:

Try the new pull request experience today

We’d love your team to try out the new view and give us your feedback! To enable the new view:

This opt-in release is a beta, and we are still working to bring some existing features over to the new view. We’ve made it easy to temporarily switch back to the old view using the «temporarily disable the new UI» link in the Feedback card at the bottom of the sidebar:

If you’re not using Bitbucket yet but you’re excited to try the new experience, sign up today!

Discuss the new code review experience with the Bitbucket Community and Alastair Wilkes (Bitbucket PM) here

Источник

Узнайте о проверке кода в Bitbucket Cloud

Создайте репозиторий и добавьте кого-нибудь в качестве проверяющего к своему запросу pull, чтобы начать совместную работу над кодом.

Примечание. В следующем разделе обучающего руководства приводятся инструкции по добавлению проверяющего (или участника команды) к вашему запросу pull, чтобы вы могли совместно работать над кодом в Bitbucket Cloud. Если вы не работаете совместно с членами команды или в данный момент не хотите добавлять проверяющих, можете перейти к следующему руководству — Изучите ветвление в Bitbucket Cloud.

Краткое описание основной задачи

До сих пор вы работали в репозиториях и над кодом в одиночку. А как быть, если вы хотите, чтобы кто-нибудь проверил ваш код и отправил отзыв? Вы сможете это сделать, добавив проверяющего к своему запросу pull, причем вне зависимости от того, находитесь ли вы с ним в одной комнате или в разных концах земного шара.

О ветках и запросах pull

Если в команде присутствует несколько пользователей Bitbucket, вам будет нужно работать над собственным кодом отдельно от основной базы кода. Для этого используются ветки, представляющие собой независимое направление разработки в репозитории. Ветку можно рассматривать как комбинацию новых разделов — рабочего каталога, индекса и истории проекта. После создания ветки вы будете работать над кодом и отправлять его в эту ветку в качестве коммитов. Кроме того, вам придется извлекать обновления из Bitbucket для поддержания актуальности данных в ветке, а затем отправлять результаты работы обратно в Bitbucket.

Когда в ветке Bitbucket возникают изменения в коде, можно создать запрос pull и инициировать проверку кода. Перед подтверждением запроса участники команды выскажутся относительно кода и зададут вопросы. Получив достаточное количество подтверждений, вы сможете выполнить слияние запроса pull и объединить ветку с основным кодом.

Создание репозитория

Вы только что прибыли на космическую станцию Bitbucket. Вам предстоит выполнить начальные действия, в том числе внести изменения в стартовый пакет и пройти процедуру их утверждения.

Нажмите + на общей боковой панели и выберите в разделе Create (Создать) пункт Repository (Репозиторий).

Убедитесь, что созданная вами команда имеет статус владельца репозитория.

Введите произвольные имя проекта и имя репозитория. Если вы затрудняетесь с выбором, используйте варианты «Стартовый набор» и «Первые впечатления» соответственно.

В области Include a README? (Добавить файл README?) выберите один из вариантов Yes (Да).

В области Version control system (Система управления версиями) выберите тип репозитория, который нужно создать. Если вы затрудняетесь с выбором, оставьте эту настройку без изменений.

Нажмите Create repository (Создать репозиторий), и вы попадете на страницу Source (Исходный код) своего нового репозитория.

На странице Source (Исходный код) выберите > Add file (Добавить файл).

Нажмите Commit (Сделать коммит), затем повторно нажмите Commit в диалоговом окне.

Теперь репозиторий выглядит неплохо. При желании вы можете просмотреть доступные возможности.

Клонирование и внесение изменений в новую ветку

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

Если вы используете командную строку

Шаг 1. Клонируйте репозиторий в локальную систему

Перейдем в локальную систему, чтобы приступить к работе.

Скопируйте команду клонирования.

В окне терминала перейдите в локальный каталог, в который требуется клонировать репозиторий.

Подробная информация о клонировании приведена в соответствующем видео:

Шаг 2. Создайте ветку и переместите ее в локальную среду

Настройка репозитория завершена, и теперь начинается самое интересное. Вы можете создавать ветки локально или через Bitbucket. В рамках обучающего руководства мы воспользуемся вторым методом.

Нажмите Branches (Ветки) на левой панели навигации. Вы увидите, что у вас уже есть главная ветка ( main ).

Нажмите Create a branch (Создать ветку) в правом верхнем углу.

После создания ветки ее нужно выбрать в локальной системе. В Bitbucket доступны команды извлечения и переключения. Их можно скопировать и вставить в командную строку, которая будет выглядеть примерно так:

Вы переключились на локальную версию новой ветки. Теперь вы можете работать с изолированным участком кода и затем опубликовать его.

Шаг 3. Внесите изменения в ветку

На этом этапе вам необходимо внести в репозиторий несколько изменений. Как указано в файле, можно использовать самый нестандартный вариант организации данных или выбрать нечто попроще. Измените CSS. Добавьте новые файлы. Напишите космическую оперу. Или просто ответьте на вопросы.

Откройте в текстовом редакторе файл survey.html (он может иметь другое имя).

Внесите нужные изменения, затем сохраните и закройте файл.

Если вы используете Sourcetree

Шаг 1. Клонируйте репозиторий в локальную систему

Перейдем в локальную систему, чтобы приступить к работе.

Нажмите кнопку Clone (Клонировать).

Чтобы ознакомиться с процедурой, просмотрите раздел видео о клонировании репозитория:

Шаг 2. Создайте ветку и переместите ее в локальную среду

Настройка репозитория завершена, и теперь начинается самое интересное. Ветки используются не только в Bitbucket, поэтому их можно создавать локально. Однако в рамках обучающего руководства мы создадим ветку в Bitbucket.

Нажмите Branches (Ветки) на левой панели навигации. Вы увидите, что у вас уже есть главная ветка (master).

Нажмите Create a branch (Создать ветку) в правом верхнем углу.

Введите имя ветки и нажмите Create (Создать). Если вы затрудняетесь с выбором имени, используйте, например, my-updates.

После создания ветки ее необходимо выбрать в локальной системе. Для этого нажмите кнопку Check out in Sourcetree (Переключить в Sourcetree).

В диалоговом окне Checkout Existing (Переключение существующего элемента) в Sourcetree нажмите Checkout (Переключить).

Теперь ветка существует в Bitbucket и выбрана в локальной системе. Вы можете работать с изолированным участком кода и затем опубликовать его.

Шаг 3. Внесите изменения в ветку

На этом этапе вам необходимо внести в репозиторий несколько изменений. Как указано в файле, можно использовать самый нестандартный вариант организации данных или выбрать нечто попроще. Измените CSS. Добавьте новые файлы. Напишите космическую оперу. Или просто ответьте на вопросы.

Откройте в текстовом редакторе файл survey.html (он может иметь другое имя).

Внесите нужные изменения, затем сохраните и закройте файл.

Несохраненные измененияОткройте Sourcetree. Вы увидите, что в репозитории появились неподтвержденные изменения.

(Только для Git.) Добавьте файл в раздел проиндексированных файлов:

Выберите строку с неподтвержденными изменениями.

Добавление изменений в раздел проиндексированных файловВ списке Unstaged files (Неиндексированные файлы) поставьте галочку рядом с файлом survey.html (сделайте то же самое для других файлов, содержащих неподтвержденные изменения).

В диалоговом окне Confirm Stage? (Подтвердить индексирование?) нажмите OK.

Нажмите кнопку Commit (Сделать коммит) в верхней части страницы, чтобы выполнить коммит файла.

Введите комментарий к коммиту в соответствующей области, например «Отвечено».

Нажмите кнопку Commit (Сделать коммит) под областью комментария.После переключения в прежнее представление вы заметите, что файл добавлен в коммит, но не опубликован в репозитории Bitbucket.

Нажмите кнопку Push (Отправить) в Sourcetree, чтобы отправить изменения, выполненные в последнем коммите.

В открывшемся диалоговом окне нажмите OK, чтобы опубликовать ветку с коммитом в Bitbucket.

В Bitbucket перейдите на страницу Source (Исходный код) в своем репозитории. В раскрывающемся списке вы увидите две ветки. Коммиты, сделанные для ветки my-updates, также появятся в этой ветке.

Создание запроса pull для слияния изменений

Далее потребуется создать запрос pull, чтобы добавить проверяющих для проверки и утверждения вашего кода перед слиянием. Запрос pull не только инициирует проверку кода, но также позволяет просмотреть изменения по сравнению с исходным репозиторием. Кроме того, с помощью такого запроса можно без труда выполнить слияние готового кода.

Шаг 1. Создайте запрос pull

Для создания запроса pull необходима ветка — вы уже создали ее ранее.

В поле Title (Название) автоматически отобразится ваш последний комментарий к коммиту.

При необходимости добавьте информацию в поле Description (Описание).

(Необязательное действие: добавление проверяющего). Если вы хотите, чтобы кто-нибудь из коллег проверил и (или) утвердил ваш код перед слиянием, добавьте его в поле Reviewers (Проверяющие). Как видите, в следующем примере запроса pull в качестве проверяющего добавлен пользователь Breezy Cloud.

Чтобы добавить проверяющего к запросу pull, вы должны сначала предоставить ему доступ к репозиторию, добавив в группу. Более полная информация и подробные инструкции приводятся в статье Предоставление доступа к репозиторию пользователям и группам. Примечание: вы всегда можете сначала создать запрос pull, а проверяющих добавить позже.

Нажмите Create pull request (Создать запрос pull).

В Bitbucket откроется запрос pull, и при добавлении проверяющего он получит по электронной почте уведомление с подробными данными запроса для проверки.

Шаг 2. Выполните слияние запроса pull

Подождите! Возможно, вы заметили кнопку Merge (Слияние) в верхней части страницы. Перед тем как ее нажать, необходимо дождаться утверждения изменений. Ваши коллеги получат уведомление по электронной почте, а также увидят запрос pull в разделе Pull requests to review (Запросы pull, ожидающие проверки) дашбоарда Your work (Ваша работа).

Перед нажатием кнопки Approve (Утвердить) проверяющий может просмотреть в запросе pull все изменения и добавить комментарии, таким образом начав обсуждение.

Когда коллега утвердит ваш запрос pull, вы получите уведомление по электронной почте. После получения всех необходимых утверждений (в данном случае нужно лишь одно) можно выполнить слияние. В разделе запроса pull нажмите Merge (Слияние). Готово! Чтобы увидеть, как выглядит ваша ветка после слияния с основной веткой, нажмите Commits (Коммиты). Это действие откроет дерево коммитов.

Источник