1. Ngôn ngữ lập trình Go
  2. Tài liệu
  3. Hướng dẫn đóng góp

Hướng dẫn đóng góp

Dự án Go chào đón mọi người đóng góp.

Tài liệu này là hướng dẫn giúp bạn đi qua quá trình đóng góp cho dự án Go, vốn có một số điểm khác so với các dự án mã nguồn mở khác. Chúng tôi giả định bạn đã có hiểu biết cơ bản về Git và Go.

Ngoài thông tin ở đây, cộng đồng Go còn duy trì một trang wiki CodeReview. Hãy đóng góp vào wiki khi bạn tìm hiểu thêm về quy trình review.

Lưu ý rằng front end gccgo nằm ở nơi khác; xem Đóng góp cho gccgo.

Trở thành người đóng góp

Tổng quan

Bước đầu tiên là đăng ký làm người đóng góp cho Go và cấu hình môi trường của bạn. Dưới đây là danh sách các bước bắt buộc cần thực hiện:

Nếu bạn thích, có một công cụ tự động hướng dẫn qua các bước này. Chỉ cần chạy: 

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

Phần còn lại của chương này giải thích chi tiết hơn về các hướng dẫn này. Nếu bạn đã hoàn thành các bước trên (bằng tay hoặc qua công cụ), hãy chuyển đến Trước khi đóng góp mã.

Bước 0: Chọn tài khoản Google

Mỗi đóng góp cho Go được thực hiện thông qua một tài khoản Google với một địa chỉ email cụ thể. Hãy dùng cùng một tài khoản trong suốt quá trình và cho tất cả các đóng góp tiếp theo của bạn. Bạn có thể cần quyết định xem dùng địa chỉ cá nhân hay địa chỉ công ty. Lựa chọn này phụ thuộc vào ai sẽ sở hữu bản quyền đối với mã bạn sẽ viết và nộp. Bạn có thể muốn thảo luận chủ đề này với người sử dụng lao động trước khi quyết định dùng tài khoản nào.

Tài khoản Google có thể là tài khoản Gmail, tài khoản tổ chức G Suite, hoặc tài khoản được liên kết với một địa chỉ email bên ngoài. Ví dụ, nếu bạn cần dùng một email công ty hiện có không được quản lý qua G Suite, bạn có thể tạo một tài khoản liên kết với địa chỉ email hiện có của bạn.

Bạn cũng cần đảm bảo rằng công cụ Git của bạn được cấu hình để tạo commit bằng địa chỉ email bạn đã chọn. Bạn có thể cấu hình Git toàn cục (làm mặc định cho tất cả các dự án) hoặc cục bộ (cho một dự án cụ thể). Bạn có thể kiểm tra cấu hình hiện tại với lệnh sau: 

$ git config --global user.email  # check current global config
$ git config user.email           # check current local config

Để thay đổi địa chỉ đã cấu hình: 

$ git config --global user.email name@example.com   # change global config
$ git config user.email name@example.com            # change local config

Bước 1: Thỏa thuận Cấp phép Người đóng góp

Trước khi gửi thay đổi đầu tiên của bạn lên dự án Go, bạn phải hoàn thành một trong hai CLA sau. CLA bạn cần ký phụ thuộc vào ai sở hữu bản quyền tác phẩm của bạn.

Bạn có thể kiểm tra các thỏa thuận đã ký và ký thỏa thuận mới tại trang web Google Developers Contributor License Agreements. Nếu người giữ bản quyền của đóng góp của bạn đã hoàn thành thỏa thuận này trong một dự án mã nguồn mở khác của Google, thì không cần thực hiện lại.

Nếu người giữ bản quyền cho mã bạn đang nộp thay đổi—ví dụ, nếu bạn bắt đầu đóng góp mã nhân danh một công ty mới—hãy gửi email đến golang-dev danh sách thư. Điều này giúp chúng tôi nắm được tình hình để đảm bảo một thỏa thuận phù hợp được hoàn thành.

Bước 2: Cấu hình xác thực git

Kho lưu trữ Go chính đặt tại go.googlesource.com, một máy chủ Git được Google lưu trữ. Xác thực trên máy chủ web được thực hiện thông qua tài khoản Google của bạn, nhưng bạn cũng cần cấu hình git trên máy tính để truy cập vào đó. Thực hiện các bước sau:

  1. Truy cập go.googlesource.com và nhấn vào "Generate Password" ở thanh menu phía trên bên phải của trang. Bạn sẽ được chuyển hướng đến accounts.google.com để đăng nhập.
  2. Sau khi đăng nhập, bạn sẽ được đưa đến trang có tiêu đề "Configure Git". Trang này chứa một đoạn script được cá nhân hóa, khi chạy cục bộ sẽ cấu hình Git để lưu khóa xác thực duy nhất của bạn. Khóa này được ghép nối với một khóa được tạo và lưu trữ trên máy chủ, tương tự như cách khóa SSH hoạt động.
  3. Sao chép và chạy script này trong terminal cục bộ để lưu token xác thực bí mật của bạn vào tệp .gitcookies. Nếu bạn đang dùng máy tính Windows và chạy cmd, hãy làm theo hướng dẫn trong hộp màu vàng để chạy lệnh; nếu không, hãy chạy script thông thường.

Bước 3: Tạo tài khoản Gerrit

Gerrit là công cụ mã nguồn mở được các maintainer của Go sử dụng để thảo luận và review các bản nộp mã.

Để đăng ký tài khoản, truy cập go-review.googlesource.com/login/ và đăng nhập một lần bằng cùng tài khoản Google bạn đã dùng ở trên.

Bước 4: Cài đặt lệnh git-codereview

Các thay đổi cho Go phải được review trước khi được chấp nhận, bất kể ai thực hiện thay đổi đó. Một lệnh git tùy chỉnh có tên git-codereview giúp đơn giản hóa việc gửi thay đổi lên Gerrit.

Cài đặt lệnh git-codereview bằng cách chạy, 

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

Đảm bảo git-codereview được cài đặt trong đường dẫn shell của bạn, để lệnh git có thể tìm thấy nó. Kiểm tra rằng 

$ git codereview help

in ra nội dung trợ giúp, không phải lỗi. Nếu nó in ra lỗi, hãy đảm bảo rằng $GOPATH/bin nằm trong $PATH của bạn.

Trên Windows, khi dùng git-bash bạn phải đảm bảo rằng git-codereview.exe nằm trong exec-path của git. Chạy git --exec-path để tìm vị trí đúng rồi tạo một liên kết tượng trưng hoặc chỉ cần sao chép tệp thực thi từ $GOPATH/bin vào thư mục đó.

Trước khi đóng góp mã

Dự án chào đón các bản vá mã, nhưng để đảm bảo mọi thứ được phối hợp tốt, bạn nên thảo luận về bất kỳ thay đổi đáng kể nào trước khi bắt đầu thực hiện. Khuyến nghị bạn báo hiệu ý định đóng góp trong trình theo dõi issue, bằng cách tạo một issue mới hoặc nhận một issue hiện có.

Đóng góp vào đâu

Dự án Go gồm kho lưu trữ chính go, chứa mã nguồn cho ngôn ngữ Go, cùng với nhiều kho lưu trữ golang.org/x/... Các kho này chứa nhiều công cụ và cơ sở hạ tầng hỗ trợ Go. Ví dụ, golang.org/x/pkgsite dành cho pkg.go.dev, golang.org/x/playground dành cho Go playground, và golang.org/x/tools chứa nhiều công cụ Go, bao gồm máy chủ ngôn ngữ Go, gopls. Bạn có thể xem danh sách tất cả các kho golang.org/x/... trên go.googlesource.com.

Kiểm tra trình theo dõi issue

Dù bạn đã biết muốn đóng góp gì, hay bạn đang tìm kiếm ý tưởng, trình theo dõi issue luôn là nơi đầu tiên cần ghé. Các issue được phân loại để phân nhóm và quản lý quy trình.

Phần lớn các kho golang.org/x/... cũng dùng trình theo dõi issue chính của Go. Tuy nhiên, một số kho quản lý issue của riêng mình, vì vậy hãy chắc chắn kiểm tra đúng trình theo dõi cho kho lưu trữ mà bạn muốn đóng góp.

Hầu hết các issue sẽ được gắn một trong các nhãn quy trình sau:

Bạn có thể dùng chức năng tìm kiếm của GitHub để tìm các issue cần giúp đỡ. Ví dụ:

Tạo issue cho mọi vấn đề mới

Ngoại trừ các thay đổi rất nhỏ, tất cả đóng góp phải được liên kết với một issue hiện có. Hãy tự nhiên mở một issue và thảo luận về kế hoạch của bạn. Quá trình này cho mọi người cơ hội xác nhận thiết kế, giúp tránh trùng lặp công sức, và đảm bảo ý tưởng phù hợp với mục tiêu của ngôn ngữ và công cụ. Nó cũng kiểm tra xem thiết kế có hợp lý trước khi viết mã không; công cụ review mã không phải nơi để thảo luận ở mức cao.

Khi lên kế hoạch công việc, hãy lưu ý rằng dự án Go tuân theo chu kỳ phát triển sáu tháng cho kho lưu trữ Go chính. Nửa sau của mỗi chu kỳ là ba tháng đóng băng tính năng, trong đó chỉ chấp nhận sửa lỗi và cập nhật tài liệu. Có thể gửi đóng góp mới trong thời gian đóng băng tính năng, nhưng chúng sẽ không được merge cho đến khi hết thời gian đóng băng. Việc đóng băng áp dụng cho toàn bộ kho lưu trữ chính cũng như mã trong các kho golang.org/x/... cần thiết để build các tệp nhị phân có trong bản phát hành. Xem danh sách các package được vendor vào thư viện chuẩn và lệnh go.

Các thay đổi đáng kể đối với ngôn ngữ, thư viện hoặc công cụ (bao gồm thay đổi API trong kho chính và tất cả kho golang.org/x, cũng như thay đổi giao diện dòng lệnh của lệnh go) phải trải qua quy trình đề xuất thay đổi trước khi được chấp nhận.

Các vấn đề bảo mật nhạy cảm (chỉ những vấn đề đó!) nên được báo cáo tới security@golang.org.

Gửi thay đổi qua GitHub

Những người đóng góp lần đầu đã quen với GitHub flow được khuyến khích dùng cùng quy trình đó cho các đóng góp cho Go. Mặc dù các maintainer của Go dùng Gerrit để review mã, một bot tên Gopherbot đã được tạo ra để đồng bộ các pull request GitHub lên Gerrit.

Mở một pull request GitHub như bình thường. Gopherbot sẽ tạo một danh sách thay đổi Gerrit tương ứng (gọi là "CL") và đăng liên kết đến nó trên pull request GitHub của bạn; các cập nhật cho pull request cũng sẽ được phản ánh trong Gerrit CL. Khi ai đó bình luận về CL, bình luận của họ cũng sẽ được đăng trong pull request của bạn, vì vậy bạn sẽ nhận được thông báo.

Một số điều cần lưu ý:

Gửi thay đổi qua Gerrit

Hiện tại, việc đồng bộ hoàn toàn Gerrit và GitHub là không thể, vì vậy chúng tôi khuyến nghị bạn học Gerrit. Nó khác biệt nhưng mạnh mẽ, và quen thuộc với nó sẽ giúp bạn hiểu quy trình.

Các phần sau đây cung cấp hướng dẫn ngắn gọn về việc gửi thay đổi qua Gerrit. Để biết thêm chi tiết về cách tương tác với Gerrit, tham khảo tài liệu của Gerrit. Đặc biệt, chúng tôi khuyến nghị đọc trang Tổng quan giao diện Review và Hướng dẫn cơ bản về Gerrit cho người dùng GitHub.

Tổng quan

Đây là tổng quan về toàn bộ quy trình:

Phần còn lại của mục này mô tả chi tiết hơn về các bước này.

Bước 1: Clone mã nguồn

Ngoài cài đặt Go gần đây, bạn cần có bản sao cục bộ của mã nguồn đã checkout từ kho lưu trữ đúng. Bạn có thể checkout kho nguồn Go vào bất kỳ đâu trên hệ thống tệp cục bộ miễn là nó nằm ngoài GOPATH (mặc định là thư mục go trong thư mục home của bạn). Clone từ go.googlesource.com (không phải GitHub):

Kho lưu trữ Go chính:

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

Kho golang.org/x/...

(golang.org/x/tools trong ví dụ này): 
$ git clone https://go.googlesource.com/tools
$ cd tools

Bước 2: Chuẩn bị thay đổi trong một branch mới

Mỗi thay đổi Go phải được thực hiện trong một branch riêng, tạo từ branch master. Bạn có thể dùng các lệnh git thông thường để tạo branch và thêm thay đổi vào vùng staging: 

$ git checkout -b mybranch
$ [edit files...]
$ git add [files...]

Để commit thay đổi, thay vì git commit, hãy dùng git codereview change. 

$ git codereview change
(open $EDITOR)

Bạn có thể chỉnh sửa mô tả commit trong trình soạn thảo yêu thích như thường. Lệnh git codereview change sẽ tự động thêm một dòng Change-Id duy nhất ở gần cuối. Dòng đó được Gerrit dùng để khớp các lần upload kế tiếp của cùng một thay đổi. Không chỉnh sửa hoặc xóa nó. Một Change-Id trông như thế này: 

Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

Công cụ cũng kiểm tra rằng bạn đã chạy go fmt trên mã nguồn, và rằng thông điệp commit tuân theo định dạng được đề xuất.

Nếu bạn cần chỉnh sửa lại các tệp, bạn có thể stage các thay đổi mới và chạy lại git codereview change: mỗi lần chạy sẽ chỉnh sửa commit hiện có trong khi giữ nguyên Change-Id.

Hãy đảm bảo rằng bạn luôn giữ một commit duy nhất trong mỗi branch. Nếu bạn vô tình thêm nhiều commit, bạn có thể dùng git rebase để gộp chúng lại thành một.

Bước 3: Kiểm thử thay đổi của bạn

Bạn đã viết và kiểm thử mã, nhưng trước khi gửi mã để review, hãy chạy tất cả các kiểm thử cho toàn bộ cây mã nguồn để đảm bảo các thay đổi không phá vỡ các package hoặc chương trình khác.

Trong kho lưu trữ Go chính

Đối với các package thư viện chuẩn, tất cả kiểm thử trong package phải pass: 

$ go test

Bộ kiểm thử ngắn cho toàn bộ cây có thể được chạy với all.bash (để build trên Windows, dùng all.bat): 

$ cd go/src
$ ./all.bash

Sau khi chạy một lúc và in ra nhiều kết quả kiểm thử, lệnh sẽ kết thúc bằng cách in ra, 

ALL TESTS PASSED

Bạn có thể dùng make.bash thay vì all.bash để chỉ build trình biên dịch và thư viện chuẩn mà không chạy bộ kiểm thử. Sau khi công cụ go được build, nó sẽ được cài đặt là bin/go trong thư mục bạn đã clone kho lưu trữ Go, và bạn có thể chạy nó trực tiếp từ đó. Xem thêm phần về cách kiểm thử thay đổi của bạn nhanh chóng.

Trong các kho golang.org/x/...

Chạy kiểm thử cho toàn bộ kho lưu trữ (golang.org/x/tools, trong ví dụ này): 

$ cd tools
$ go test ./...

Nếu bạn lo ngại về trạng thái build, bạn có thể kiểm tra Build Dashboard. Các lỗi kiểm thử cũng có thể được phát hiện bởi TryBots trong quá trình review mã.

Một số kho lưu trữ, như golang.org/x/vscode-go sẽ có cơ sở hạ tầng kiểm thử khác, vì vậy hãy luôn kiểm tra tài liệu của kho lưu trữ bạn đang làm việc. Tệp README ở thư mục gốc của kho lưu trữ thường có thông tin này.

Bước 4: Gửi thay đổi để review

Khi thay đổi đã sẵn sàng và được kiểm thử trên toàn bộ cây, hãy gửi nó để review. Việc này được thực hiện bằng lệnh con mail, dù tên gọi vậy, nó không thực sự gửi email; nó chỉ gửi thay đổi lên Gerrit: 

$ git codereview mail

Gerrit gán cho thay đổi của bạn một số và URL, mà git codereview mail sẽ in ra, chẳng hạn như: 

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

Nếu bạn gặp lỗi, hãy kiểm tra mục Xử lý sự cố lỗi mail.

Nếu thay đổi của bạn liên quan đến một issue GitHub đang mở và bạn đã tuân theo định dạng thông điệp commit được đề xuất, issue đó sẽ được cập nhật trong vài phút bởi một bot, liên kết Gerrit CL của bạn vào đó trong phần bình luận.

Bước 5: Chỉnh sửa thay đổi sau khi review

Các maintainer của Go sẽ review mã của bạn trên Gerrit, và bạn sẽ nhận thông báo qua email. Bạn có thể xem review trên Gerrit và bình luận tại đó. Bạn cũng có thể trả lời bằng email nếu bạn thích.

Nếu bạn cần chỉnh sửa thay đổi sau khi review, hãy chỉnh sửa các tệp trong branch bạn đã tạo trước đó, thêm chúng vào vùng staging của Git, rồi chỉnh sửa commit bằng git codereview change: 

$ git codereview change     # amend current commit
(open $EDITOR)
$ git codereview mail       # send new changes to Gerrit

Nếu bạn không cần thay đổi mô tả commit, chỉ cần lưu và thoát trình soạn thảo. Nhớ đừng chạm vào dòng Change-Id đặc biệt.

Một lần nữa, hãy đảm bảo rằng bạn luôn giữ một commit duy nhất trong mỗi branch. Nếu bạn vô tình thêm nhiều commit, bạn có thể dùng git rebase để gộp chúng lại thành một.

Thông điệp commit tốt

Thông điệp commit trong Go tuân theo một bộ quy ước cụ thể, được chúng tôi thảo luận trong phần này.

Đây là một ví dụ về thông điệp tốt: 

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

Dòng đầu tiên

Dòng đầu tiên của mô tả thay đổi theo quy ước là một dòng ngắn tóm tắt thay đổi, có tiền tố là package bị ảnh hưởng chính.

Quy tắc thực hành là nó nên được viết sao cho hoàn thành câu "Thay đổi này chỉnh sửa Go để _____." Có nghĩa là nó không bắt đầu bằng chữ hoa, không phải một câu hoàn chỉnh, và thực sự tóm tắt kết quả của thay đổi.

Theo sau dòng đầu là một dòng trống.

Nội dung chính

Phần còn lại của mô tả giải thích chi tiết hơn và cần cung cấp ngữ cảnh cho thay đổi, giải thích nó làm gì. Viết bằng câu hoàn chỉnh với dấu câu chính xác, giống như các bình luận trong Go. Không dùng HTML, Markdown, hay bất kỳ ngôn ngữ đánh dấu nào khác. Văn bản nên được xuống dòng ở khoảng 72 ký tự. Xem Thông điệp commit để biết thêm chi tiết.

Thêm bất kỳ thông tin liên quan nào, chẳng hạn như dữ liệu benchmark nếu thay đổi ảnh hưởng đến hiệu năng. Công cụ benchstat theo quy ước được dùng để định dạng dữ liệu benchmark cho mô tả thay đổi.

Tham chiếu issue

Ký hiệu đặc biệt "Fixes #12345" liên kết thay đổi với issue 12345 trong trình theo dõi issue của Go. Khi thay đổi này cuối cùng được áp dụng, trình theo dõi issue sẽ tự động đánh dấu issue là đã sửa.

Nếu thay đổi là bước tiến một phần hướng tới giải quyết issue, viết "Updates #12345" thay vào đó. Điều này sẽ để lại một bình luận trong issue liên kết lại với thay đổi trong Gerrit, nhưng sẽ không đóng issue khi thay đổi được áp dụng.

Nếu bạn gửi thay đổi cho một kho golang.org/x/..., bạn phải dùng cú pháp đầy đủ được GitHub hỗ trợ để đảm bảo thay đổi được liên kết với issue trong kho chính, không phải kho x/. Hầu hết issue được theo dõi trong trình theo dõi issue của kho chính. Dạng đúng là "Fixes golang/go#159".

Quy trình review

Mục này giải thích chi tiết quy trình review và cách tiếp cận các review sau khi thay đổi đã được gửi.

Các lỗi phổ biến của người mới

Khi một thay đổi được gửi lên Gerrit, nó thường được phân loại trong vài ngày. Một maintainer sẽ xem qua và cung cấp một số review ban đầu thường tập trung vào các vấn đề thẩm mỹ cơ bản và lỗi phổ biến đối với người đóng góp lần đầu. Những điều này bao gồm:

Trybots

Sau khi đọc lần đầu thay đổi của bạn, các maintainer sẽ kích hoạt trybots, một cụm máy chủ sẽ chạy bộ kiểm thử đầy đủ trên nhiều kiến trúc khác nhau. Hầu hết trybots hoàn thành trong vài phút, sau đó một liên kết sẽ được đăng trong Gerrit để bạn xem kết quả.

Nếu quá trình chạy trybot thất bại, hãy theo liên kết và kiểm tra nhật ký đầy đủ của các nền tảng mà các kiểm thử thất bại. Cố gắng hiểu điều gì đã bị hỏng, cập nhật bản vá của bạn để sửa nó, và upload lại. Các maintainer sẽ kích hoạt một lần chạy trybot mới để xem liệu vấn đề có được sửa không.

Đôi khi, cây có thể bị hỏng trên một số nền tảng trong vài giờ; nếu lỗi được trybot báo cáo có vẻ không liên quan đến bản vá của bạn, hãy truy cập Build Dashboard và kiểm tra xem cùng lỗi có xuất hiện trong các commit gần đây khác trên cùng nền tảng không. Trong trường hợp đó, hãy tự nhiên viết một bình luận trong Gerrit để đề cập rằng lỗi không liên quan đến thay đổi của bạn, để giúp các maintainer hiểu tình hình. Bạn cũng có thể tìm kiếm các issue GitHub cho thông báo lỗi đang xảy ra hoặc duyệt qua các issue watchflakes mới cập nhật. Nếu thay đổi của bạn dựa trên một commit cũ hơn hoặc có vẻ như ai đó khác đã sửa vấn đề rồi, hãy thử rebase lên commit master mới nhất qua git rebase.

Reviews

Cộng đồng Go coi trọng việc review kỹ lưỡng. Hãy coi mỗi bình luận review như một phiếu công việc: bạn được kỳ vọng "đóng" nó bằng cách hành động theo, hoặc bằng cách thực hiện gợi ý hoặc thuyết phục reviewer rằng có cách làm khác.

Sau khi bạn cập nhật thay đổi, hãy xem qua các bình luận review và đảm bảo trả lời từng bình luận một. Bạn có thể nhấn nút "Done" để trả lời rằng bạn đã thực hiện gợi ý của reviewer; nếu không, nhấn vào "Reply" và giải thích tại sao bạn không thực hiện, hoặc bạn đã làm gì thay thế.

Hoàn toàn bình thường khi các thay đổi phải trải qua nhiều vòng review, với một hoặc nhiều reviewer đưa ra bình luận mới mỗi lần và sau đó chờ thay đổi được cập nhật trước khi review lại. Điều này xảy ra ngay cả với những người đóng góp có kinh nghiệm, vì vậy đừng nản lòng vì điều đó.

Quy ước bình chọn

Khi tiến gần đến quyết định, các reviewer sẽ áp dụng một "phiếu" Code-Review cho thay đổi của bạn. Có hai loại phiếu có thể:

Để được nộp, một thay đổi phải có Code-Review +2 từ một maintainer.

Các maintainer cũng có thể áp dụng phiếu Hold +1 cho thay đổi, để đánh dấu thay đổi không nên được nộp ngay bây giờ (ví dụ, vì review đề xuất cho API mới trong thay đổi chưa hoàn thành).

Để được nộp, một thay đổi không được có bất kỳ phiếu Hold +1 nào từ maintainer.

Cuối cùng, để được nộp, một thay đổi phải có sự tham gia của hai nhân viên Google, hoặc là người tải lên thay đổi hoặc là reviewer bỏ phiếu ít nhất Code-Review +1. Yêu cầu này nhằm mục đích tuân thủ và bảo mật chuỗi cung ứng.

Nộp thay đổi đã được phê duyệt

Khi thay đổi đã sẵn sàng, một maintainer sẽ nộp thay đổi, thêm nó như một commit vào kho lưu trữ Gerrit.

Hai bước (phê duyệt và nộp) là riêng biệt vì trong một số trường hợp các maintainer có thể muốn phê duyệt nhưng không nộp ngay lập tức (ví dụ, cây có thể bị đóng băng tạm thời).

Nộp một thay đổi đưa nó vào kho lưu trữ. Mô tả thay đổi sẽ bao gồm liên kết đến code review, sẽ được cập nhật với liên kết đến thay đổi trong kho lưu trữ. Vì phương pháp dùng để tích hợp thay đổi là "Cherry Pick" của Git, các hash commit trong kho lưu trữ sẽ bị thay đổi bởi thao tác nộp.

Nếu thay đổi của bạn đã được phê duyệt vài ngày mà chưa được nộp, hãy tự nhiên viết một bình luận trong Gerrit yêu cầu được nộp.

Thêm thông tin

Ngoài thông tin ở đây, cộng đồng Go còn duy trì một trang wiki CodeReview. Hãy đóng góp vào trang này khi bạn tìm hiểu thêm về quy trình review.

Các chủ đề khác

Mục này tập hợp một số bình luận khác nằm ngoài chính quy trình issue/chỉnh sửa/review mã/nộp.

Gopls

Khi làm việc trên kho lưu trữ Go chính và dùng gopls với trình soạn thảo, lệnh go được gopls gọi phải tương ứng với phiên bản mã nguồn bạn đang làm việc. Lệnh go có thể được build bằng make.bash và thư mục bin nên được thêm vào PATH của bạn. Xem Gopls: Các chủ đề nâng cao để biết thêm chi tiết.

Tài liệu đầy đủ cho Gopls có thể tìm thấy tại https://godev.go-mizu.dev/gopls.

Các tệp trong kho lưu trữ Go không liệt kê tên tác giả, cả để tránh lộn xộn và tránh phải cập nhật danh sách liên tục. Thay vào đó, tên bạn sẽ xuất hiện trong nhật ký thay đổi.

Các tệp mới bạn đóng góp nên dùng tiêu đề bản quyền chuẩn: 

// Copyright 2026 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.

Các tệp trong kho lưu trữ được ghi bản quyền theo năm chúng được thêm vào. Không cập nhật năm bản quyền trên các tệp bạn thay đổi.

Xử lý sự cố lỗi mail

Cách phổ biến nhất mà lệnh git codereview mail thất bại là do địa chỉ email trong commit không khớp với địa chỉ bạn đã dùng trong quá trình đăng ký.
Nếu bạn thấy thông báo như... 

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

bạn cần cấu hình Git cho kho lưu trữ này để dùng địa chỉ email đã đăng ký. Để thay đổi địa chỉ email nhằm đảm bảo điều này không xảy ra nữa, hãy chạy: 

$ git config user.email email@address.com

Sau đó thay đổi commit để dùng địa chỉ email thay thế này bằng lệnh sau: 

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

Rồi thử lại bằng cách chạy: 

$ git codereview mail

Kiểm thử thay đổi của bạn nhanh chóng

Chạy all.bash cho mỗi thay đổi nhỏ trong cây mã nguồn là khá tốn kém. Mặc dù được khuyến nghị mạnh mẽ chạy nó trước khi gửi thay đổi, trong chu kỳ phát triển thông thường bạn có thể muốn chỉ biên dịch và kiểm thử package bạn đang phát triển.

Chỉ định reviewer / CC người khác

Trừ khi được chỉ định rõ ràng, chẳng hạn như trong cuộc thảo luận dẫn đến việc gửi thay đổi, tốt hơn là không chỉ định reviewer. Tất cả thay đổi được tự động CC đến danh sách thư golang-codereviews@googlegroups.com. Nếu đây là thay đổi đầu tiên của bạn, có thể có độ trễ kiểm duyệt trước khi nó xuất hiện trên danh sách thư, để ngăn spam.

Bạn có thể chỉ định reviewer hoặc CC những người quan tâm bằng các tùy chọn -r hoặc -cc. Cả hai đều chấp nhận danh sách địa chỉ email phân cách bằng dấu phẩy: 

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

Đồng bộ hóa client của bạn

Trong khi bạn đang làm việc, người khác có thể đã nộp thay đổi vào kho lưu trữ. Để cập nhật branch cục bộ của bạn, hãy chạy 

$ git codereview sync

(Phía sau nó chạy git pull -r.)

Review mã của người khác

Là một phần của quy trình review, các reviewer có thể đề xuất thay đổi trực tiếp (trong quy trình GitHub, đây sẽ là người khác đính kèm commit vào pull request). Gerrit cung cấp các lệnh giúp bạn import thay đổi được đề xuất bởi nhà phát triển khác để bạn có thể review/kiểm thử chúng cục bộ. Từ trang Gerrit cho CL bạn muốn import, mở menu "⋮", nhấn vào liên kết "Download patch". Tùy thuộc vào quy trình git ưa thích của bạn, chọn lệnh phù hợp. Các tùy chọn sẽ trông giống như thế này: 

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

Để hoàn tác, hãy chuyển lại branch bạn đang làm việc.

Thiết lập alias git

Lệnh git-codereview có thể được chạy trực tiếp từ shell bằng cách gõ, ví dụ, 

$ git codereview sync

nhưng thuận tiện hơn là thiết lập alias cho các lệnh con riêng của git-codereview, để lệnh trên trở thành, 

$ git sync

Các lệnh con của git-codereview được chọn để khác biệt với các lệnh con của Git gốc, vì vậy an toàn để định nghĩa các alias này. Để cài đặt chúng, hãy sao chép nội dung này vào tệp cấu hình Git của bạn (thường là .gitconfig trong thư mục home): 

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

Gửi nhiều thay đổi phụ thuộc nhau

Người dùng nâng cao có thể muốn xếp các commit liên quan vào một branch duy nhất. Gerrit cho phép các thay đổi phụ thuộc vào nhau, tạo thành một chuỗi phụ thuộc như vậy. Mỗi thay đổi cần được phê duyệt và nộp riêng nhưng sự phụ thuộc sẽ hiển thị với reviewer.

Để gửi một nhóm thay đổi phụ thuộc, giữ mỗi thay đổi là một commit khác nhau dưới cùng một branch, rồi chạy: 

$ git codereview mail HEAD

Hãy chắc chắn chỉ định rõ ràng HEAD, thường không bắt buộc khi gửi các thay đổi đơn lẻ. Thêm chi tiết có thể tìm thấy trong tài liệu git-codereview.

Bản phát hành nhỏ

Nếu bạn muốn thực hiện thay đổi cho một branch phát hành để backport, xem Bản phát hành nhỏ.

go.dev sử dụng cookie của Google để cung cấp và nâng cao chất lượng dịch vụ cũng như phân tích lưu lượng truy cập. Tìm hiểu thêm.