1. Documentation
  2. Contribution Guide

Руководство по вкладу

Проект Go приветствует всех участников.

Данная документация является руководством, которое поможет вам пройти процесс участия в проекте Go, который немного отличается от используемого в других проектах с открытым исходным кодом. Предполагается, что вы имеете базовое понимание Git и Go.

Помимо информации, содержащейся здесь, сообщество Go поддерживает страницу CodeReview в вики. Не стесняйтесь добавлять информацию в вики по мере того, как вы будете изучать процесс проверки.

Обратите внимание, что интерфейс gccgo находится в другом месте; см. Участие в gccgo.

Становление участником

Обзор

Первым шагом является регистрация как участника Go и настройка среды. Ниже приведён чеклист необходимых шагов:

Если вы предпочитаете, существует автоматизированный инструмент, который пройдёт по этим шагам. Просто выполните: 

$ go install golang.org/x/tools/cmd/go-contrib-init@latest
$ cd /code/to/edit
$ go-contrib-init

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

Шаг 0: Выбор учётной записи Google

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

Учётные записи Google могут быть адресами электронной почты Gmail, учётными записями организаций G Suite или учётными записями, связанными с внешним адресом электронной почты. Например, если вам нужно использовать существующий корпоративный адрес электронной почты, который не управляется через G Suite, вы можете создать учётную запись, связанную с вашим существующим адресом электронной почты.

Также необходимо убедиться, что ваш инструмент Git настроен на создание коммитов с использованием выбранного вами адреса электронной почты. Можно настроить Git глобально (как значение по умолчанию для всех проектов) или локально (для одного конкретного проекта). Проверить текущую конфигурацию можно с помощью следующей команды: 

$ git config --global user.email  # проверить текущую глобальную конфигурацию
$ git config user.email           # проверить текущую локальную конфигурацию

Чтобы изменить настроенный адрес: 

$ git config --global user.email name@example.com   # изменить глобальную конфигурацию
$ git config user.email name@example.com            # изменить локальную конфигурацию

Шаг 1: Лицензионное соглашение участника

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

Проверить уже подписанные соглашения и подписать новые можно на сайте Google Developers Contributor License Agreements. Если правообладателем внесённого вклада уже было подписано соглашение в рамках другого проекта Google Open Source, то его повторное заполнение не требуется.

Если правообладателем кода, который вы отправляете, является другая организация — например, вы начинаете вносить код от имени новой компании, пожалуйста, отправьте письмо на golang-dev mailing list. Это позволит нам узнать о ситуации и убедиться, что соответствующее соглашение будет подписано.

Шаг 2: Настройка git-аутентификации

Основной репозиторий Go находится по адресу go.googlesource.com, Git-сервер, размещённый в Google. Аутентификация на веб-сервере осуществляется через вашу учётную запись Google, однако также необходимо настроить git на вашем компьютере для доступа к нему. Следуйте этим шагам:

  1. Перейдите на сайт go.googlesource.com и нажмите на кнопку «Generate Password» в правом верхнем меню страницы. Вы будете перенаправлены на accounts.google.com для входа.
  2. После входа вы окажетесь на странице с заголовком «Configure Git». Эта страница содержит персонализированный скрипт, который при запуске локально настроит Git для хранения вашего уникального ключа аутентификации. Этот ключ связан с ключом, сгенерированным и сохранённым на сервере, аналогично работе SSH-ключей.
  3. Скопируйте и выполните этот скрипт локально в терминале, чтобы сохранить ваш секретный токен аутентификации в файле .gitcookies. Если вы используете компьютер на Windows и запускаете cmd, вместо этого следуйте инструкциям в жёлтом блоке, чтобы выполнить команду; в противном случае запустите обычный скрипт.

Шаг 3: Создайте учётную запись Gerrit

Gerrit — это инструмент с открытым исходным кодом, используемый разработчиками Go для обсуждения и проверки кода.

Чтобы зарегистрировать свою учётную запись, перейдите на сайт go-review.googlesource.com/login/ и войдите один раз, используя ту же учётную запись Google, что и выше.

Шаг 4: Установите команду git-codereview

Изменения в Go должны быть проверены перед принятием, независимо от того, кто их вносит. Пользовательская команда git под названием git-codereview упрощает отправку изменений в Gerrit.

Установите команду git-codereview, выполнив следующую команду: 

$ go install golang.org/x/review/git-codereview@latest

Убедитесь, что git-codereview установлен в вашем shell path, чтобы команда git могла его найти. Проверьте, что 

$ git codereview help

выводит текст справки, а не ошибку. Если выводится ошибка, убедитесь, что $GOPATH/bin находится в вашем $PATH.

В Windows, при использовании git-bash необходимо убедиться, что git-codereview.exe находится в вашем git exec-path. Выполните git --exec-path, чтобы определить правильное расположение, а затем создайте символическую ссылку или просто скопируйте исполняемый файл из $GOPATH/bin в эту директорию.

Перед тем как вносить изменения в код

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

Куда вносить изменения

Проект Go состоит из основного go репозитория, который содержит исходный код языка Go, а также множества репозиториев golang.org/x/... . Эти репозитории содержат различные инструменты и инфраструктуру, поддерживающие Go. Например, golang.org/x/pkgsite используется для pkg.go.dev, golang.org/x/playground используется для Go playground, а golang.org/x/tools содержит различные инструменты Go, включая сервер языка Go, gopls. Список всех репозиториев golang.org/x/... можно найти на go.googlesource.com.

Проверьте трекер задач

Независимо от того, знаете ли вы, какую именно вкладку сделать, или ищете идею, трекер задач всегда является первым местом, куда стоит обратиться. Задачи классифицируются, чтобы организовать рабочий процесс.

Большинство репозиториев golang.org/x/... используют основной трекер задач Go. Однако несколько из этих репозиториев управляют своими задачами отдельно, поэтому убедитесь, что вы проверяете правильный трекер для репозитория, в который вы хотите внести вклад.

Большинство задач будут помечены одной из следующих меток рабочего процесса:

Вы можете использовать функциональность поиска GitHub, чтобы найти задачи, с которыми можно помочь. Примеры:

Откройте задачу для любого нового вопроса

За исключением очень тривиальных изменений, все вклады должны быть связаны с существующей задачей. Пожалуйста, откройте новую задачу и обсудите свои планы. Этот процесс даёт всем возможность проверить дизайн, помогает избежать дублирования усилий, и гарантирует, что идея соответствует целям языка и инструментов. Он также проверяет, что дизайн является надёжным, прежде чем будет написан код; инструмент проверки кода не предназначен для обсуждения на высоком уровне.

При планировании работы, пожалуйста, обратите внимание, что проект Go следует шестимесячному циклу разработки для основного репозитория Go. Вторая половина каждого цикла — это трёхмесячный период заморозки функций, в течение которого принимаются только исправления ошибок и обновления документации. Новые вклады могут быть отправлены во время заморозки функций, но они не будут объединены, пока не пройдёт период заморозки. Заморозка распространяется на всё основное репозиторий, а также на код в репозиториях golang.org/x/..., необходимый для сборки бинарных файлов, входящих в релиз. См. списки пакетов, включённых в стандартную библиотеку и go команду.

Значительные изменения в языке, библиотеках или инструментах (включая изменения API в основном репозитории и во всех репозиториях golang.org/x, а также изменения командной строки go команды) должны пройти через процесс предложения изменений перед тем, как будут приняты.

Чувствительные вопросы, связанные с безопасностью (только они!), должны быть сообщены на адрес security@golang.org.

Отправка изменений через GitHub

Для новых участников, уже знакомых с GitHub flow, рекомендуется использовать тот же процесс для вкладов в Go. Несмотря на то, что сопровождающие Go используют Gerrit для проверки кода, был создан бот под названием Gopherbot, который синхронизирует GitHub pull requests с Gerrit.

Откройте GitHub pull request, как обычно. Gopherbot создаст соответствующий список изменений в Gerrit («CL») и опубликует ссылку на него в вашем GitHub pull request; обновления pull request также будут отражены в Gerrit CL. Когда кто-либо прокомментирует CL, его комментарий также будет опубликован в вашем pull request, поэтому вы получите уведомление.

Несколько моментов, которые стоит иметь в виду:

Отправка изменений через Gerrit

Полная синхронизация Gerrit и GitHub невозможна, по крайней мере на данный момент, поэтому рекомендуется ознакомиться с Gerrit. Он отличается, но мощный, и знакомство с ним поможет вам понять процесс.

В следующих разделах приводится краткое руководство по отправке изменений через Gerrit. Для получения дополнительных сведений о взаимодействии с Gerrit обратитесь к документации Gerrit. В частности, рекомендуется прочитать страницы Обзор пользовательского интерфейса для проверки и Основное руководство по Gerrit — Для пользователей GitHub.

Обзор

Это обзор общего процесса:

Остальная часть этого раздела описывает эти шаги более подробно.

Шаг 1: Клонирование исходного кода

Помимо недавней установки Go, вам нужно иметь локальную копию исходного кода, проверенную из правильного репозитория. Вы можете склонировать репозиторий исходного кода Go в любое место вашей локальной файловой системы, лишь бы оно находилось за пределами вашего GOPATH (по умолчанию это каталог go в вашем домашнем каталоге). Клонируйте с go.googlesource.com (не с GitHub):

Основной репозиторий Go:

$ git clone https://go.googlesource.com/go
$ cd go

Репозиторий golang.org/x/...

(golang.org/x/tools в этом примере): 

$ git clone https://go.googlesource.com/tools
$ cd tools

Шаг 2: Подготовьте изменения в новой ветке

Каждое изменение в Go должно быть сделано в отдельной ветке, созданной из ветки master. Можно использовать обычные команды git для создания ветки и добавления изменений в область подготовки: 

$ git checkout -b mybranch
$ [редактирование файлов...]
$ git add [файлы...]

Чтобы зафиксировать изменения, вместо git commit используйте git codereview change. 

$ git codereview change
(открывается $EDITOR)

Вы можете редактировать описание коммита в вашем любимом редакторе, как обычно. Команда git codereview change автоматически добавит уникальную строку Change-Id внизу. Эта строка используется Gerrit для сопоставления последовательных загрузок одного и того же изменения. Не редактируйте и не удаляйте её. Change-Id выглядит так: 

Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

Инструмент также проверяет, что вы запустили go fmt над исходным кодом, и что сообщение коммита соответствует предлагаемому формату.

Если потребуется снова отредактировать файлы, вы можете подготовить новые изменения и снова запустить git codereview change: каждое последующее выполнение будет изменять существующий коммит, сохраняя при этом Change-Id.

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

Шаг 3: Протестируйте свои изменения

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

В главном репозитории Go

Для стандартных библиотечных пакетов все тесты внутри пакета должны пройти: 

$ go test

Краткая тестовая сборка для всего дерева может быть запущена с помощью all.bash (Для сборки под Windows используйте all.bat): 

$ cd go/src
$ ./all.bash

После некоторого времени работы и вывода большого количества информации о тестировании команда должна завершиться печатая, 

ALL TESTS PASSED

Вместо all.bash можно использовать make.bash чтобы просто собрать компилятор и стандартную библиотеку без запуска тестов. После сборки инструмент go будет установлен как bin/go в директории, в которую был клонирован репозиторий Go, и вы сможете запускать его напрямую оттуда. См. также раздел о том, как быстро протестировать изменения.

В репозиториях golang.org/x/...

Запустите тесты для всего репозитория (golang.org/x/tools, в этом примере): 

$ cd tools
$ go test ./...

Если вас беспокоит статус сборки, можно проверить Build Dashboard. Ошибки тестирования также могут быть замечены TryBots во время код-ревью.

Некоторые репозитории, такие как golang.org/x/vscode-go будут иметь различные инфраструктуры тестирования, поэтому всегда проверяйте документацию репозитория, в котором вы работаете. Файл README в корне репозитория обычно содержит эту информацию.

Шаг 4: Отправьте изменения на проверку

Когда изменение готово и протестировано на всём дереве, отправьте его на проверку. Это делается с помощью подкоманды mail, несмотря на своё название, которая не отправляет ничего по электронной почте; она просто отправляет изменение в Gerrit: 

$ git codereview mail

Gerrit назначает вашему изменению номер и URL-адрес, которые git codereview mail выведет, примерно следующего вида: 

remote: New Changes:
remote:   https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments

Если вместо этого вы получаете ошибку, проверьте раздел Устранение неполадок с почтовыми ошибками.

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

Шаг 5: Внесение изменений после отзыва

Сопровождающие Go будут проверять ваш код в Gerrit, и вы получите уведомления по электронной почте. Вы можете просматривать отзыв в Gerrit и комментировать его там. Также можно отвечать по электронной почте, если вы предпочитаете такой способ.

Если вам нужно внести изменения в ваше изменение после отзыва, отредактируйте файлы в той же ветке, которую вы ранее создавали, добавьте их в область подготовки Git, а затем измените коммит с помощью git codereview change: 

$ git codereview change     # изменить текущий коммит
(open $EDITOR)
$ git codereview mail       # отправить новые изменения в Gerrit

Если вам не нужно изменять описание коммита, просто сохраните и закройте редактор. Помните, что не стоит трогать специальную строку Change-Id.

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

Хорошие сообщения коммитов

Сообщения коммитов в Go следуют определённым соглашениям, о которых говорится в этом разделе.

Вот пример хорошего сообщения: 

math: improve Sin, Cos and Tan precision for very large arguments
The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.
The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm
Fixes #159

Первая строка

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

Правило thumb (правило пальца) состоит в том, что она должна быть написана так, чтобы завершать предложение "Это изменение модифицирует Go для _____". Это означает, что она не начинается с заглавной буквы, не является полным предложением, и фактически резюмирует результат изменений.

После первой строки следует пустая строка.

Основное содержание

Остальная часть описания раскрывает детали и должна предоставить контекст для изменений и объяснить, что они делают. Пишите полными предложениями с правильной пунктуацией, как и для комментариев в Go. Не используйте HTML, Markdown или любой другой язык разметки.

Добавьте любую соответствующую информацию, например данные бенчмарков, если изменение влияет на производительность. Инструмент benchstat обычно используется для форматирования данных бенчмарков в описаниях изменений.

Ссылки на проблемы

Специальная запись "Fixes #12345" связывает изменение с проблемой 12345 в трекере проблем Go. Когда это изменение будет применено, трекер проблем автоматически отметит проблему как исправленную.

Если изменение является частичным шагом к разрешению проблемы, напишите "Updates #12345". Это оставит комментарий в проблеме, который будет ссылаться обратно к изменению в Gerrit, но не закроет проблему при применении изменений.

Если вы отправляете изменения в репозиторий golang.org/x/..., вы должны использовать полностью квалифицированный синтаксис, поддерживаемый GitHub, чтобы убедиться, что изменения связаны с задачей в основном репозитории, а не в x/ репозитории. Большинство задач отслеживаются в трекере задач основного репозитория. Правильный формат: "Fixes golang/go#159".

Процесс проверки

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

Распространённые ошибки новичков

Когда изменения отправляются в Gerrit, они обычно обрабатываются в течение нескольких дней. Сопровождающий ознакомится с ними и предоставит начальную проверку, в которой для первых участников обычно акцентируется внимание на базовой эстетике и распространённых ошибках. К таким ошибкам относятся:

Trybots

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

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

Иногда дерево может быть сломано на некоторых платформах на несколько часов; если ошибка, сообщенная trybot, не кажется связанной с вашим патчем, перейдите на Build Dashboard и проверьте, появляется ли та же ошибка в других недавних коммитах на той же платформе. В этом случае, не стесняйтесь оставить комментарий в Gerrit, чтобы указать, что ошибка не связана с вашими изменениями, чтобы помочь сопровождающим понять ситуацию. Вы также можете поискать задачи на GitHub по сообщению об ошибке или просмотреть недавно обновлённые задачи watchflakes. Если ваши изменения основаны на старом коммите или кажется, что кто-то уже исправил проблему, попробуйте перебазировать изменения до последнего коммита master через git rebase.

Проверки

Сообщество Go очень ценит тщательные проверки. Думайте о каждом комментарии проверки как о тикете: ожидается, что вы как-то "закроете" его, реализовав предложение или убедив проверяющего в обратном.

После обновления изменений пройдитесь по комментариям проверки и убедитесь, что ответили на каждый. Можно нажать кнопку "Done", чтобы ответить, указав, что вы реализовали предложение проверяющего; в противном случае, нажмите "Reply" и объясните, почему вы не сделали этого, или что сделали вместо этого.

Нормально, когда изменения проходят несколько циклов проверки, при этом один или несколько рецензентов оставляют новые комментарии и затем ждут обновлённого варианта перед повторной проверкой. Этот процесс происходит даже для опытных участников, поэтому не стоит отчаиваться из-за него.

Согласования по голосованию

По мере приближения к решению, рецензенты будут выставлять «голос» по Code-Review для вашего изменения. Существует два возможных голоса:

Чтобы изменение было принято, оно должно иметь Code-Review +2 от сопровождающего.

Сопровождающие также могут выставить голос Hold +1 для изменения, чтобы отметить изменение, которое не должно быть принято сейчас (например, потому что ревью предложения для нового API в изменении ещё не завершено).

Чтобы изменение было принято, оно не должно иметь ни одного голоса Hold +1 от сопровождающего.

Наконец, чтобы изменение было принято, оно должно включать участие двух сотрудников Google, либо как загрузивший изменение, либо как рецензент, выставивший как минимум Code-Review +1. Это требование связано с соблюдением норм и обеспечением безопасности поставки.

Подача одобренного изменения

Когда изменение готово, сопровождающий подаст его, что добавит его как коммит в репозиторий Gerrit.

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

Подача изменения записывает его в репозиторий. Описание изменения будет включать ссылку на код-ревью, которое будет обновлено ссылкой на изменение в репозитории. Поскольку метод, используемый для интеграции изменений, это Git "Cherry Pick", хэши коммитов в репозитории будут изменены операцией подачи.

Если ваше изменение было одобрено несколько дней без подачи, не стесняйтесь оставить комментарий в Gerrit с просьбой о подаче.

Дополнительная информация

Помимо информации, представленной здесь, сообщество Go поддерживает страницу вики CodeReview. Не стесняйтесь вносить вклад в эту страницу по мере того, как узнаете больше о процессе рецензирования.

Различные темы

В этом разделе собраны различные комментарии, которые находятся вне самого процесса вопроса/редактирования/ревью/подачи.

Gopls

При работе в основном репозитории Go и использовании gopls с вашим редактором, команда go, вызываемая gopls, должна соответствовать версии исходного кода, над которым вы работаете. Команда go может быть собрана с помощью make.bash, и директория bin должна быть добавлена в ваш PATH. См. Gopls: Advanced topics для дополнительных деталей.

Полная документация по Gopls доступна по адресу https://go.dev/gopls.

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

Новые файлы, которые вы добавляете, должны использовать стандартный заголовок авторских прав: 

// Copyright 2025 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

Файлы в репозитории защищены авторским правом с года их добавления. Не обновляйте год авторского права в файлах, которые вы изменяете.

Устранение неполадок с ошибками почты

Самый распространённый способ, когда команда git codereview mail завершается неудачей, заключается в том, что адрес электронной почты в коммите не совпадает с тем, который был использован во время процесса регистрации.
Если вы видите что-то вроде... 

remote: Processing changes: refs: 1, done
remote:
remote: ERROR:  In commit ab13517fa29487dcf8b0d48916c51639426c5ee9
remote: ERROR:  author email address XXXX XXXXXXX XXXXXXX
remote: ERROR:  does not match your user account.

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

$ git config user.email email@address.com

Затем измените коммит, чтобы использовать этот альтернативный адрес электронной почты с помощью следующей команды: 

$ git commit --amend --author="Author Name <email@address.com>"

После этого попробуйте снова с помощью команды: 

$ git codereview mail

Быстрое тестирование ваших изменений

Запуск all.bash для каждого отдельного изменения в дереве кода является слишком трудоёмким. Несмотря на то, что настоятельно рекомендуется запускать его перед отправкой изменений, в обычном цикле разработки вы можете захотеть скомпилировать и протестировать только пакет, над которым работаете.

Указание рецензента / CC других лиц

Если явно не указано иное, например, в ходе обсуждения, предшествующего отправке изменений, лучше не указывать рецензента. Все изменения автоматически отправляются на список рассылки golang-codereviews@googlegroups.com. Если это ваше первое изменение, может быть задержка модерации перед появлением сообщения в списке рассылки, чтобы предотвратить спам.

Вы можете указать рецензента или добавить заинтересованные лица в CC, используя параметры -r или -cc. Оба параметра принимают список адресов электронной почты, разделенных запятыми: 

$ git codereview mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com

Синхронизируйте ваш клиент

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

$ git codereview sync

(Внутри команда выполняет git pull -r.)

Просмотр чужого кода

В рамках процесса рецензирования рецензенты могут предлагать изменения напрямую (в GitHub это будет когда кто-то прикрепляет коммиты к pull request). Gerrit предоставляет доступ к командам, которые помогут вам импортировать изменения, предложенные другим разработчиком, чтобы вы могли проверить или протестировать их локально. На странице Gerrit для CL, который вы хотите импортировать, откройте меню "⋮", затем нажмите ссылку "Download patch". В зависимости от предпочитаемого вами Git-потока, выберите подходящую команду. Опции будут выглядеть примерно так: 

$ git fetch https://go.googlesource.com/review refs/changes/21/13245/1 && git checkout FETCH_HEAD

Чтобы отменить изменения, вернитесь к ветке, в которой вы работали.

Настройка алиасов Git

Команда git-codereview может быть запущена напрямую из оболочки путем ввода, например, 

$ git codereview sync

однако удобнее установить алиасы для подкоманд git-codereview, чтобы вышеуказанная команда стала, 

$ git sync

Подкоманды git-codereview были выбраны таким образом, чтобы они отличались от подкоманд Git, поэтому безопасно определять эти алиасы. Чтобы установить их, скопируйте следующий текст в ваш файл конфигурации Git (обычно это .gitconfig в вашем домашнем каталоге): 

[alias]
change = codereview change
gofmt = codereview gofmt
mail = codereview mail
pending = codereview pending
submit = codereview submit
sync = codereview sync

Отправка нескольких зависимых изменений

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

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

$ git codereview mail HEAD

Убедитесь, что вы явно указали HEAD, что обычно не требуется при отправке отдельных изменений. Более подробную информацию можно найти в документации git-codereview.

Минорные релизы

Если вы хотите внести изменения в ветку релиза для обратной совместимости, см. Минорные релизы.

GoRu.dev Golang на русском

На сайте представлена адаптированная под русский язык документация языка программирования Golang

goru.dev использует файлы cookie для предоставления и улучшения качества своих услуг и анализа трафика. Узнать больше.