mirror of
https://github.com/golang/go
synced 2024-11-23 06:30:06 -07:00
7b6b5e3404
Explain Brad's algorithm for generating commit headlines. Fixes #15700 Change-Id: Ic602f17629b3dd7675e2bb1ed119062c03353ee9 Reviewed-on: https://go-review.googlesource.com/23355 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
710 lines
21 KiB
HTML
710 lines
21 KiB
HTML
<!--{
|
|
"Title": "Contribution Guidelines"
|
|
}-->
|
|
|
|
<h2 id="Introduction">Introduction</h2>
|
|
|
|
<p>
|
|
This document explains how to contribute changes to the Go project.
|
|
It assumes you have followed the
|
|
<a href="/doc/install/source">installation instructions</a> and
|
|
have <a href="code.html">written and tested your code</a>.
|
|
</p>
|
|
|
|
<p>
|
|
(Note that the <code>gccgo</code> frontend lives elsewhere;
|
|
see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
|
|
</p>
|
|
|
|
<p>
|
|
Sensitive security-related issues should be reported to <a href="mailto:security@golang.org">security@golang.org</a>.
|
|
</p>
|
|
|
|
<h2 id="Design">Discuss your design</h2>
|
|
|
|
<p>
|
|
The project welcomes submissions but please let everyone know what
|
|
you're working on if you want to change or add to the Go repositories.
|
|
</p>
|
|
|
|
<p>
|
|
Before undertaking to write something new for the Go project,
|
|
please <a href="https://golang.org/issue/new">file an issue</a>
|
|
(or claim an <a href="https://golang.org/issues">existing issue</a>).
|
|
Significant changes must go through the
|
|
<a href="https://golang.org/s/proposal-process">change proposal process</a>
|
|
before they can be accepted.
|
|
</p>
|
|
|
|
<p>
|
|
This process gives everyone a chance to validate the design,
|
|
helps prevent duplication of effort,
|
|
and ensures that the idea fits inside the goals for the language and tools.
|
|
It also checks that the design is sound before code is written;
|
|
the code review tool is not the place for high-level discussions.
|
|
</p>
|
|
|
|
<p>
|
|
When planning work, please note that the Go project follows a
|
|
<a href="https://golang.org/wiki/Go-Release-Cycle">six-month
|
|
development cycle</a>. The latter half of each cycle is a three-month
|
|
feature freeze during which only bug fixes and doc updates are accepted.
|
|
New work cannot be submitted during a feature freeze.
|
|
</p>
|
|
|
|
<h2 id="Testing">Testing redux</h2>
|
|
|
|
<p>
|
|
You've <a href="code.html">written and tested your code</a>, but
|
|
before sending code out for review, run all the tests for the whole
|
|
tree to make sure the changes don't break other packages or programs:
|
|
</p>
|
|
|
|
<pre>
|
|
$ cd go/src
|
|
$ ./all.bash
|
|
</pre>
|
|
|
|
<p>
|
|
(To build under Windows use <code>all.bat</code>.)
|
|
</p>
|
|
|
|
<p>
|
|
After running for a while, the command should print
|
|
"<code>ALL</code> <code>TESTS</code> <code>PASSED</code>".
|
|
</p>
|
|
|
|
<h2 id="Code_review">Code review</h2>
|
|
|
|
<p>
|
|
Changes to Go must be reviewed before they are accepted,
|
|
no matter who makes the change.
|
|
A custom git command called <code>git-codereview</code>,
|
|
discussed below, helps manage the code review process through a Google-hosted
|
|
<a href="https://go-review.googlesource.com/">instance</a> of the code review
|
|
system called <a href="https://www.gerritcodereview.com/">Gerrit</a>.
|
|
</p>
|
|
|
|
<h3 id="auth">Set up authentication for code review</h3>
|
|
|
|
<p>
|
|
Gerrit uses Google Accounts for authentication. If you don't have
|
|
a Google Account, you can create an account which
|
|
<a href="https://www.google.com/accounts/NewAccount">includes
|
|
a new Gmail email account</a> or create an account associated
|
|
<a href="https://accounts.google.com/SignUpWithoutGmail">with your existing
|
|
email address</a>.
|
|
</p>
|
|
|
|
<p>
|
|
The email address associated with the Google Account you use will be recorded in
|
|
the <a href="https://go.googlesource.com/go/+log/">change log</a>
|
|
and in the <a href="/CONTRIBUTORS">contributors file</a>.
|
|
</p>
|
|
|
|
<p>
|
|
To set up your account in Gerrit, visit
|
|
<a href="https://go.googlesource.com">go.googlesource.com</a>
|
|
and click on "Generate Password" in the page's top right menu bar.
|
|
</p>
|
|
|
|
<p>
|
|
You will be redirected to accounts.google.com to sign in.
|
|
</p>
|
|
|
|
<p>
|
|
Once signed in, you are returned back to go.googlesource.com to "Configure Git".
|
|
Follow the instructions on the page.
|
|
(If you are on a Windows computer, you should instead follow the instructions
|
|
in the yellow box to run the command.)
|
|
</p>
|
|
|
|
<p>
|
|
Your secret authentication token is now in a <code>.gitcookie</code> file
|
|
and Git is configured to use this file.
|
|
</p>
|
|
|
|
<h3 id="gerrit">Register with Gerrit</h3>
|
|
|
|
<p>
|
|
Now that you have your authentication token,
|
|
you need to register your account with Gerrit.
|
|
To do this, visit
|
|
<a href="https://go-review.googlesource.com/login/">
|
|
go-review.googlesource.com/login/</a>. You will immediately be redirected
|
|
to Google Accounts. Sign in using the same Google Account you used above.
|
|
That is all that is required.
|
|
</p>
|
|
|
|
<h3 id="cla">Contributor License Agreement</h3>
|
|
|
|
<p>Gerrit serves as the gatekeeper and uses your e-mail address as the key.
|
|
To send your first change to the Go project from a given address,
|
|
you must have completed one of the contributor license agreements:
|
|
<ul>
|
|
<li>
|
|
If you are the copyright holder, you will need to agree to the
|
|
<a href="https://developers.google.com/open-source/cla/individual">individual
|
|
contributor license agreement</a>, which can be completed online.
|
|
</li>
|
|
<li>
|
|
If your organization is the copyright holder, the organization
|
|
will need to agree to the
|
|
<a href="https://developers.google.com/open-source/cla/corporate">corporate
|
|
contributor license agreement</a>.
|
|
(If the copyright holder for your code has already completed the
|
|
agreement in connection with another Google open source project,
|
|
it does not need to be completed again.)
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
You can use the links above to create and sign the contributor license agreement
|
|
or you can show your current agreements and create new ones through the Gerrit
|
|
interface. <a href="https://go-review.googlesource.com/login/">Log into Gerrit</a>,
|
|
click your name in the upper-right, choose "Settings", then select "Agreements"
|
|
from the topics on the left. If you do not have a signed agreement listed here,
|
|
you can create one by clicking "New Contributor Agreement" and following the steps.
|
|
</p>
|
|
|
|
<p>
|
|
This rigmarole only needs to be done for your first submission for each email address.
|
|
</p>
|
|
|
|
<p>
|
|
If the copyright holder for the code you are submitting changes—for example,
|
|
if you start contributing code on behalf of a new company—please send email
|
|
to let us know, so that we can make sure an appropriate agreement is completed
|
|
and update the <code>AUTHORS</code> file.
|
|
</p>
|
|
|
|
<h3 id="git-codereview">Install the git-codereview command</h3>
|
|
|
|
<p>
|
|
Now install the <code>git-codereview</code> command by running,
|
|
</p>
|
|
|
|
<pre>
|
|
$ go get -u golang.org/x/review/git-codereview
|
|
</pre>
|
|
|
|
<p>
|
|
Make sure <code>git-codereview</code> is installed in your shell path, so that the
|
|
<code>git</code> command can find it. Check that
|
|
</p>
|
|
|
|
<pre>
|
|
$ git codereview help
|
|
</pre>
|
|
|
|
<p>
|
|
prints help text, not an error.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Note to Git aficionados:</b>
|
|
The <code>git-codereview</code> command is not required to
|
|
upload and manage Gerrit code reviews. For those who prefer plain Git, the text
|
|
below gives the Git equivalent of each git-codereview command.
|
|
</p>
|
|
|
|
<p>If you do use plain
|
|
Git, note that you still need the commit hooks that the git-codereview command
|
|
configures; those hooks add a Gerrit <code>Change-Id</code> line to the commit
|
|
message and check that all Go source files have been formatted with gofmt. Even
|
|
if you intend to use plain Git for daily work, install the hooks in a new Git
|
|
checkout by running <code>git-codereview</code> <code>hooks</code>.
|
|
</p>
|
|
|
|
<p>
|
|
The workflow described below assumes a single change per branch.
|
|
It is also possible to prepare a sequence of (usually related) changes in a single branch.
|
|
See the <a href="https://golang.org/x/review/git-codereview">git-codereview documentation</a> for details.
|
|
</p>
|
|
|
|
<h3 id="git-config">Set up git aliases</h3>
|
|
|
|
<p>
|
|
The <code>git-codereview</code> command can be run directly from the shell
|
|
by typing, for instance,
|
|
</p>
|
|
|
|
<pre>
|
|
$ git codereview sync
|
|
</pre>
|
|
|
|
<p>
|
|
but it is more convenient to set up aliases for <code>git-codereview</code>'s own
|
|
subcommands, so that the above becomes,
|
|
</p>
|
|
|
|
<pre>
|
|
$ git sync
|
|
</pre>
|
|
|
|
<p>
|
|
The <code>git-codereview</code> subcommands have been chosen to be distinct from
|
|
Git's own, so it's safe to do so.
|
|
</p>
|
|
|
|
<p>
|
|
The aliases are optional, but in the rest of this document we will assume
|
|
they are installed.
|
|
To install them, copy this text into your Git configuration file
|
|
(usually <code>.gitconfig</code> in your home directory):
|
|
</p>
|
|
|
|
<pre>
|
|
[alias]
|
|
change = codereview change
|
|
gofmt = codereview gofmt
|
|
mail = codereview mail
|
|
pending = codereview pending
|
|
submit = codereview submit
|
|
sync = codereview sync
|
|
</pre>
|
|
|
|
<h3 id="help">Understanding the git-codereview command</h3>
|
|
|
|
<p>After installing the <code>git-codereview</code> command, you can run</p>
|
|
|
|
<pre>
|
|
$ git codereview help
|
|
</pre>
|
|
|
|
<p>
|
|
to learn more about its commands.
|
|
You can also read the <a href="https://godoc.org/golang.org/x/review/git-codereview">command documentation</a>.
|
|
</p>
|
|
|
|
<h3 id="master">Switch to the master branch</h3>
|
|
|
|
<p>
|
|
Most Go installations use a release branch, but new changes should
|
|
only be made based on the master branch.
|
|
(They may be applied later to a release branch as part of the release process,
|
|
but most contributors won't do this themselves.)
|
|
Before making a change, make sure you start on the master branch:
|
|
</p>
|
|
|
|
<pre>
|
|
$ git checkout master
|
|
$ git sync
|
|
</pre>
|
|
|
|
<p>
|
|
(In Git terms, <code>git</code> <code>sync</code> runs
|
|
<code>git</code> <code>pull</code> <code>-r</code>.)
|
|
</p>
|
|
|
|
<h3 id="change">Make a change</h3>
|
|
|
|
<p>
|
|
The entire checked-out tree is writable.
|
|
Once you have edited files, you must tell Git that they have been modified.
|
|
You must also tell Git about any files that are added, removed, or renamed files.
|
|
These operations are done with the usual Git commands,
|
|
<code>git</code> <code>add</code>,
|
|
<code>git</code> <code>rm</code>,
|
|
and
|
|
<code>git</code> <code>mv</code>.
|
|
</p>
|
|
|
|
<p>
|
|
If you wish to checkpoint your work, or are ready to send the code out for review, run</p>
|
|
|
|
<pre>
|
|
$ git change <i><branch></i>
|
|
</pre>
|
|
|
|
<p>
|
|
from any directory in your Go repository to commit the changes so far.
|
|
The name <i><branch></i> is an arbitrary one you choose to identify the
|
|
local branch containing your changes.
|
|
</p>
|
|
|
|
<p>
|
|
(In Git terms, <code>git</code> <code>change</code> <code><branch></code>
|
|
runs <code>git</code> <code>checkout</code> <code>-b</code> <code>branch</code>,
|
|
then <code>git</code> <code>branch</code> <code>--set-upstream-to</code> <code>origin/master</code>,
|
|
then <code>git</code> <code>commit</code>.)
|
|
</p>
|
|
|
|
<p>
|
|
Git will open a change description file in your editor.
|
|
(It uses the editor named by the <code>$EDITOR</code> environment variable,
|
|
<code>vi</code> by default.)
|
|
The file will look like:
|
|
</p>
|
|
|
|
<pre>
|
|
|
|
# Please enter the commit message for your changes. Lines starting
|
|
# with '#' will be ignored, and an empty message aborts the commit.
|
|
# On branch foo
|
|
# Changes not staged for commit:
|
|
# modified: editedfile.go
|
|
#
|
|
</pre>
|
|
|
|
<p>
|
|
At the beginning of this file is a blank line; replace it
|
|
with a thorough description of your change.
|
|
The first line of the change description is conventionally a one-line
|
|
summary of the change, prefixed by the primary affected package,
|
|
and is used as the subject for code review mail.
|
|
It should complete the sentence "This change modifies Go to _____."
|
|
The rest of the description elaborates and should provide context for the
|
|
change and explain what it does.
|
|
Write in complete sentences with correct punctuation, just like
|
|
for your comments in Go.
|
|
If there is a helpful reference, mention it here.
|
|
If you've fixed an issue, reference it by number with a # before it.
|
|
</p>
|
|
|
|
<p>
|
|
After editing, the template might now read:
|
|
</p>
|
|
|
|
<pre>
|
|
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 http://wikipedia.org/wiki/McGillicutty_Algorithm
|
|
|
|
Fixes #159
|
|
|
|
# Please enter the commit message for your changes. Lines starting
|
|
# with '#' will be ignored, and an empty message aborts the commit.
|
|
# On branch foo
|
|
# Changes not staged for commit:
|
|
# modified: editedfile.go
|
|
#
|
|
</pre>
|
|
|
|
<p>
|
|
The commented section of the file lists all the modified files in your client.
|
|
It is best to keep unrelated changes in different change lists,
|
|
so if you see a file listed that should not be included, abort
|
|
the command and move that file to a different branch.
|
|
</p>
|
|
|
|
<p>
|
|
The special notation "Fixes #159" associates the change with issue 159 in the
|
|
<a href="https://golang.org/issue/159">Go issue tracker</a>.
|
|
When this change is eventually submitted, the issue
|
|
tracker will automatically mark the issue as fixed.
|
|
(There are several such conventions, described in detail in the
|
|
<a href="https://help.github.com/articles/closing-issues-via-commit-messages/">GitHub Issue Tracker documentation</a>.)
|
|
</p>
|
|
|
|
<p>
|
|
Once you have finished writing the commit message,
|
|
save the file and exit the editor.
|
|
</p>
|
|
|
|
<p>
|
|
If you wish to do more editing, re-stage your changes using
|
|
<code>git</code> <code>add</code>, and then run
|
|
</p>
|
|
|
|
<pre>
|
|
$ git change
|
|
</pre>
|
|
|
|
<p>
|
|
to update the change description and incorporate the staged changes. The
|
|
change description contains a <code>Change-Id</code> line near the bottom,
|
|
added by a Git commit hook during the initial
|
|
<code>git</code> <code>change</code>.
|
|
That line is used by Gerrit to match successive uploads of the same change.
|
|
Do not edit or delete it.
|
|
</p>
|
|
|
|
<p>
|
|
(In Git terms, <code>git</code> <code>change</code> with no branch name
|
|
runs <code>git</code> <code>commit</code> <code>--amend</code>.)
|
|
</p>
|
|
|
|
<h3 id="mail">Mail the change for review</h3>
|
|
|
|
<p>
|
|
Once the change is ready, mail it out for review:
|
|
</p>
|
|
|
|
<pre>
|
|
$ git mail
|
|
</pre>
|
|
|
|
<p>
|
|
You can specify a reviewer or CC interested parties
|
|
using the <code>-r</code> or <code>-cc</code> options.
|
|
Both accept a comma-separated list of email addresses:
|
|
</p>
|
|
|
|
<pre>
|
|
$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
|
|
</pre>
|
|
|
|
<p>
|
|
Unless explicitly told otherwise, such as in the discussion leading
|
|
up to sending in the change list, it's better not to specify a reviewer.
|
|
All changes are automatically CC'ed to the
|
|
<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
|
|
mailing list. If this is your first ever change, there may be a moderation
|
|
delay before it appears on the mailing list, to prevent spam.
|
|
</p>
|
|
|
|
<p>
|
|
(In Git terms, <code>git</code> <code>mail</code> pushes the local committed
|
|
changes to Gerrit using <code>git</code> <code>push</code> <code>origin</code>
|
|
<code>HEAD:refs/for/master</code>.)
|
|
</p>
|
|
|
|
<p>
|
|
If your change relates to an open issue, please add a comment to the issue
|
|
announcing your proposed fix, including a link to your CL.
|
|
</p>
|
|
|
|
<p>
|
|
The code review server assigns your change an issue number and URL,
|
|
which <code>git</code> <code>mail</code> will print, something like:
|
|
</p>
|
|
|
|
<pre>
|
|
remote: New Changes:
|
|
remote: https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
|
|
</pre>
|
|
|
|
<h3 id="review">Reviewing code</h3>
|
|
|
|
<p>
|
|
Running <code>git</code> <code>mail</code> will send an email to you and the
|
|
reviewers asking them to visit the issue's URL and make comments on the change.
|
|
When done, the reviewer adds comments through the Gerrit user interface
|
|
and clicks "Reply" to send comments back.
|
|
You will receive a mail notification when this happens.
|
|
You must reply through the web interface.
|
|
(Unlike with the old Rietveld review system, replying by mail has no effect.)
|
|
</p>
|
|
|
|
<h3 id="revise">Revise and upload</h3>
|
|
|
|
<p>
|
|
You must respond to review comments through the web interface.
|
|
(Unlike with the old Rietveld review system, responding by mail has no effect.)
|
|
</p>
|
|
|
|
<p>
|
|
When you have revised the code and are ready for another round of review,
|
|
stage those changes and use <code>git</code> <code>change</code> to update the
|
|
commit.
|
|
To send the update change list for another round of review,
|
|
run <code>git</code> <code>mail</code> again.
|
|
</p>
|
|
|
|
<p>
|
|
The reviewer can comment on the new copy, and the process repeats.
|
|
The reviewer approves the change by giving it a positive score
|
|
(+1 or +2) and replying <code>LGTM</code>: looks good to me.
|
|
</p>
|
|
|
|
<p>
|
|
You can see a list of your pending changes by running <code>git</code>
|
|
<code>pending</code>, and switch between change branches with <code>git</code>
|
|
<code>change</code> <code><i><branch></i></code>.
|
|
</p>
|
|
|
|
<h3 id="sync">Synchronize your client</h3>
|
|
|
|
<p>
|
|
While you were working, others might have submitted changes to the repository.
|
|
To update your local branch, run
|
|
</p>
|
|
|
|
<pre>
|
|
$ git sync
|
|
</pre>
|
|
|
|
<p>
|
|
(In git terms, <code>git</code> <code>sync</code> runs
|
|
<code>git</code> <code>pull</code> <code>-r</code>.)
|
|
</p>
|
|
|
|
<p>
|
|
If files you were editing have changed, Git does its best to merge the
|
|
remote changes into your local changes.
|
|
It may leave some files to merge by hand.
|
|
</p>
|
|
|
|
<p>
|
|
For example, suppose you have edited <code>sin.go</code> but
|
|
someone else has committed an independent change.
|
|
When you run <code>git</code> <code>sync</code>,
|
|
you will get the (scary-looking) output:
|
|
|
|
<pre>
|
|
$ git sync
|
|
Failed to merge in the changes.
|
|
Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
|
|
The copy of the patch that failed is found in:
|
|
/home/you/repo/.git/rebase-apply/patch
|
|
|
|
When you have resolved this problem, run "git rebase --continue".
|
|
If you prefer to skip this patch, run "git rebase --skip" instead.
|
|
To check out the original branch and stop rebasing, run "git rebase --abort".
|
|
</pre>
|
|
|
|
<p>
|
|
If this happens, run
|
|
</p>
|
|
|
|
<pre>
|
|
$ git status
|
|
</pre>
|
|
|
|
<p>
|
|
to see which files failed to merge.
|
|
The output will look something like this:
|
|
</p>
|
|
|
|
<pre>
|
|
rebase in progress; onto a24c3eb
|
|
You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
|
|
(fix conflicts and then run "git rebase --continue")
|
|
(use "git rebase --skip" to skip this patch)
|
|
(use "git rebase --abort" to check out the original branch)
|
|
|
|
Unmerged paths:
|
|
(use "git reset HEAD <file>..." to unstage)
|
|
(use "git add <file>..." to mark resolution)
|
|
|
|
<i>both modified: sin.go</i>
|
|
</pre>
|
|
|
|
<p>
|
|
The only important part in that transcript is the italicized "both modified"
|
|
line: Git failed to merge your changes with the conflicting change.
|
|
When this happens, Git leaves both sets of edits in the file,
|
|
with conflicts marked by <code><<<<<<<</code> and
|
|
<code>>>>>>>></code>.
|
|
It is now your job to edit the file to combine them.
|
|
Continuing the example, searching for those strings in <code>sin.go</code>
|
|
might turn up:
|
|
</p>
|
|
|
|
<pre>
|
|
arg = scale(arg)
|
|
<<<<<<< HEAD
|
|
if arg < 1e9 {
|
|
=======
|
|
if arg < 1e10 {
|
|
>>>>>>> mcgillicutty
|
|
largeReduce(arg)
|
|
</pre>
|
|
|
|
<p>
|
|
Git doesn't show it, but suppose the original text that both edits
|
|
started with was 1e8; you changed it to 1e10 and the other change to 1e9,
|
|
so the correct answer might now be 1e10. First, edit the section
|
|
to remove the markers and leave the correct code:
|
|
</p>
|
|
|
|
<pre>
|
|
arg = scale(arg)
|
|
if arg < 1e10 {
|
|
largeReduce(arg)
|
|
</pre>
|
|
|
|
<p>
|
|
Then tell Git that the conflict is resolved by running
|
|
</p>
|
|
|
|
<pre>
|
|
$ git add sin.go
|
|
</pre>
|
|
|
|
<p>
|
|
If you had been editing the file, say for debugging, but do not
|
|
care to preserve your changes, you can run
|
|
<code>git</code> <code>reset</code> <code>HEAD</code> <code>sin.go</code>
|
|
to abandon your changes.
|
|
Then run <code>git</code> <code>rebase</code> <code>--continue</code> to
|
|
restore the change commit.
|
|
</p>
|
|
|
|
<h3 id="download">Reviewing code by others</h3>
|
|
|
|
<p>
|
|
You can import a change proposed by someone else into your local Git repository.
|
|
On the Gerrit review page, click the "Download ▼" link in the upper right
|
|
corner, copy the "Checkout" command and run it from your local Git repo.
|
|
It should look something like this:
|
|
</p>
|
|
|
|
<pre>
|
|
$ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
|
|
</pre>
|
|
|
|
<p>
|
|
To revert, change back to the branch you were working in.
|
|
</p>
|
|
|
|
<h3 id="submit">Submit the change after the review</h3>
|
|
|
|
<p>
|
|
After the code has been <code>LGTM</code>'ed, an approver may
|
|
submit it to the master branch using the Gerrit UI.
|
|
There is a "Submit" button on the web page for the change
|
|
that appears once the change is approved (marked +2).
|
|
</p>
|
|
|
|
<p>
|
|
This checks the change into the repository.
|
|
The change description will include a link to the code review,
|
|
and the code review will be updated with a link to the change
|
|
in the repository.
|
|
Since the method used to integrate the changes is "Cherry Pick",
|
|
the commit hashes in the repository will be changed by
|
|
the submit operation.
|
|
</p>
|
|
|
|
<h3 id="more">More information</h3>
|
|
|
|
<p>
|
|
In addition to the information here, the Go community maintains a <a href="https://golang.org/wiki/CodeReview">CodeReview</a> wiki page.
|
|
Feel free to contribute to this page as you learn the review process.
|
|
</p>
|
|
|
|
<h2 id="copyright">Copyright</h2>
|
|
|
|
<p>Files in the Go repository don't list author names,
|
|
both to avoid clutter and to avoid having to keep the lists up to date.
|
|
Instead, your name will appear in the
|
|
<a href="https://golang.org/change">change log</a>
|
|
and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
|
|
and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
|
|
</p>
|
|
|
|
<p>The <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
|
|
defines who the Go contributors—the people—are;
|
|
the <a href="/AUTHORS"><code>AUTHORS</code></a> file defines
|
|
who “The Go Authors”—the copyright holders—are.
|
|
These files will be periodically updated based on the commit logs.
|
|
|
|
<p>Code that you contribute should use the standard copyright header:</p>
|
|
|
|
<pre>
|
|
// Copyright 2016 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.
|
|
</pre>
|
|
|
|
<p>
|
|
Files in the repository are copyright the year they are added. It is not
|
|
necessary to update the copyright year on files that you change.
|
|
</p>
|