1. Ngôn ngữ lập trình Go
  2. Documentation
  3. Hướng dẫn đóng góp

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

Dự án Go chào đón tất cả contributor.

Tài liệu này là hướng dẫn giúp bạn thực hiện quy trình đóng góp cho dự án Go, quy trình này hơi khác so với quy trình được sử dụng bở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 tại đây, cộng đồng Go duy trì một trang wiki CodeReview. Bạn có thể đóng góp cho wiki khi tìm hiểu quy trình xem xét.

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

Trở thành contributor

Tổng quan

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

Nếu muốn, bạn có thể sử dụng 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 (dù thực hiện thủ công hay thông qua công cụ), hãy chuyển đến Trước khi đóng góp mã.

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

Một đó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ỉ e-mail cụ thể. Hãy đảm bảo sử 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 nên sử dụng địa chỉ cá nhân hay địa chỉ công ty. Lựa chọn này sẽ phụ thuộc vào người sẽ sở hữu bản quyền đối với mã mà bạn sẽ viết và gửi. Bạn có thể muốn thảo luận chủ đề này với nhà tuyển dụng của mình trước khi quyết định sử dụng tài khoản nào.

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

Bạn cũng cần đảm bảo rằng công cụ Git của mình được cấu hình để tạo commit bằng địa chỉ e-mail đã chọn. Bạn có thể cấu hình Git ở mức toàn cục (làm mặc định cho tất 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 bằng lệnh sau: 

$ git config --global user.email  # kiểm tra cấu hình toàn cục hiện tại
$ git config user.email           # kiểm tra cấu hình cục bộ hiện tại

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

$ git config --global user.email name@example.com   # thay đổi cấu hình toàn cục
$ git config user.email name@example.com            # thay đổi cấu hình cục bộ

Bước 1: Thỏa thuận cấp phép contributor

Trước khi gửi thay đổi đầu tiên của bạn đến dự án Go bạn phải hoàn tất một trong hai CLA sau. Việc bạn nên ký CLA nào phụ thuộc vào người sở hữu bản quyền đối với công việc của bạn.

Bạn có thể kiểm tra các thỏa thuận đã ký hiện tại và ký các thỏa thuận mới tại trang web Các thỏa thuận cấp phép contributor của Google Developers. Nếu chủ sở hữu bản quyền cho đóng góp của bạn đã hoàn tất thỏa thuận liên quan đến một dự án mã nguồn mở khác của Google, thì không cần hoàn tất lại.

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

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

repository Go chính nằm tại go.googlesource.com, một máy chủ Git do Google lưu trữ. Việc 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 của mình để truy cập vào đó. Hãy làm theo các bước sau:

  1. Truy cập go.googlesource.com và nhấp vào "Generate Password" trong thanh menu ở góc 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 một trang có tiêu đề "Configure Git". Trang này chứa một tập lệnh đượ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 cặp với một khóa được tạo và lưu trữ trên máy chủ, tương tự như cách các khóa SSH hoạt động.
  3. Sao chép và chạy tập lệnh này cục bộ trong terminal của bạn để lưu mã thông báo xác thực bí mật vào tệp .gitcookies. Nếu bạn đang sử dụng máy tính Windows và chạy cmd, thay vào đó bạn nên 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 tập lệnh thông thường.

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

Gerrit là một công cụ mã nguồn mở được các maintainer của Go sử dụng để thảo luận và xem xét các nội dung gửi mã.

Để đăng ký tài khoản, hãy 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 mà bạn đã sử dụng ở trên.

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

Các thay đổi đối với Go phải được xem xét 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 các thay đổi đế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 văn bản 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 sử 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í phù hợp, sau đó 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 này.

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

Dự án hoan nghênh 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 công việc. Bạn nên thông báo ý định đóng góp của mình 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 ở đâu

Dự án Go bao gồm repository go chính, chứa mã nguồn của ngôn ngữ Go, cũng như nhiều repository golang.org/x/.... Các repository 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 repository golang.org/x/... trên go.googlesource.com.

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

Cho dù bạn đã biết mình muốn thực hiện đóng góp nào, hay đang tìm kiếm một ý tưởng, trình theo dõi issue luôn là nơi đầu tiên cần đến. Các issue được phân loại để sắp xếp chúng và quản lý quy trình làm việc.

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

Hầu hết issue sẽ được đánh dấu bằng một trong các nhãn quy trình làm việc sau:

Bạn có thể sử dụng chức năng tìm kiếm của GitHub để tìm các issue cần hỗ trợ. Ví dụ:

Mở một issue cho mọi vấn đề mới

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

Khi lập 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 repository Go chính. Nửa sau của mỗi chu kỳ là giai đoạn đóng băng tính năng kéo dài ba tháng, trong đó chỉ chấp nhận các bản sửa lỗi và cập nhật tài liệu. Các đóng góp mới có thể được gửi trong thời gian đóng băng tính năng, nhưng chúng sẽ không được hợp nhất cho đến khi giai đoạn đóng băng kết thúc. Giai đoạn đóng băng áp dụng cho toàn bộ repository chính cũng như mã trong các repository golang.org/x/... cần thiết để xây dựng các binary có trong bản phát hành. Xem danh sách các gói được vendored vào thư viện chuẩn và go command.

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

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

Gửi một thay đổi qua Gerrit

Chúng tôi khuyến khích sử dụng Gerrit để gửi các thay đổi để review. Mặc dù có một chút đường cong học tập đối với người dùng chỉ sử dụng quy trình làm việc của GitHub, đây là quy trình làm việc chính được các contributor của dự án Go sử dụng và là một quy trình làm việc mượt mà hơn với nhiều tính năng hơn.

Các phần sau cung cấp hướng dẫn ngắn gọn về việc gửi một thay đổi qua Gerrit. Để biết thêm chi tiết về cách tương tác với Gerrit, hãy tham khảo tài liệu của Gerrit. Đặc biệt, chúng tôi khuyên bạn nên đọc Tổng quan về Review UI và các trang Hướng dẫn cơ bản về Gerrit — Dành 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: Sao chép mã nguồn

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

repository Go chính:

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

repository 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ị các thay đổi trong một nhánh mới

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

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

Để commit các 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 ưa thích như bì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 sử dụng để khớp các lần tải lên tiếp theo của cùng một thay đổi. Không chỉnh sửa hoặc xóa dòng đó. Một Change-Id có dạng như sau: 

Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

Công cụ này 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ể đưa các thay đổi mới vào staging và chạy lại git codereview change: mỗi lần chạy tiếp theo sẽ cập nhật commit hiện có trong khi vẫn 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 nhánh. Nếu bạn thêm nhiều commit do nhầm lẫn, bạn có thể dùng git rebase để gộp chúng lại thành một commit duy nhất.

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

Bạn đã viết và kiểm thử mã của mình, nhưng trước khi gửi mã đi để xem xét, hãy chạy tất cả các bài kiểm thử cho toàn bộ cây để đảm bảo các thay đổi không làm hỏng các gói hoặc chương trình khác.

Trong repository Go chính

Đối với các gói thư viện chuẩn, tất cả bài kiểm thử trong gói phải vượt qua: 

$ go test

Bộ kiểm thử ngắn cho toàn bộ cây có thể được chạy bằng all.bash (để xây dựng trên Windows, hãy 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 này sẽ kết thúc bằng cách in ra, 

ALL TESTS PASSED

Bạn có thể dùng make.bash thay cho all.bash để chỉ xây dựng 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 xây dựng, nó sẽ được cài đặt dưới dạng bin/go trong thư mục nơi bạn đã sao chép repository Go, và bạn có thể chạy trực tiếp từ đó. Xem thêm phần về cách kiểm thử nhanh các thay đổi của bạn.

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

Chạy các bài kiểm thử cho toàn bộ repository (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 xây dựng, bạn có thể kiểm tra Bảng điều khiển Build. Các lỗi kiểm thử cũng có thể được phát hiện bởi các TryBots trong quá trình xem xét mã.

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

Bước 4: Gửi các thay đổi để xem xét

Khi thay đổi đã sẵn sàng và được kiểm thử trên toàn bộ cây, hãy gửi nó để xem xét. Việc này được thực hiện bằng lệnh con mail, mặc dù có tên như vậy nhưng không trực tiếp gửi thư; nó chỉ gửi thay đổi đế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, ví dụ như: 

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

Nếu thay vào đó bạn nhận được lỗi, hãy kiểm tra phần Khắc phục lỗi mail.

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

Bước 5: Sửa đổi thay đổi sau khi được xem xét

Các maintainer của Go sẽ xem xét mã của bạn trên Gerrit, và bạn sẽ nhận được thông báo qua e-mail. Bạn có thể xem phần xem xét trên Gerrit và bình luận về chúng tại đó. Bạn cũng có thể trả lời bằng e-mail nếu bạn muốn.

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

$ git codereview change     # sửa commit hiện tại
(mở $EDITOR)
$ git codereview mail       # gửi các thay đổi mới tới Gerrit

Nếu bạn không cần thay đổi mô tả commit, chỉ cần lưu và thoát khỏi trình chỉnh sửa. Hãy nhớ khô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 hơn, bạn có thể dùng git rebase để gộp chúng lại thành một commit duy nhất.

Gửi một thay đổi qua GitHub

Mặc dù quy trình Gerrit được khuyến nghị và được hỗ trợ tốt hơn, các contributor đã quen thuộc với quy trình GitHub có thể sử dụng cùng quy trình này cho các đóng góp cho Go. Mặc dù các maintainer của Go sử dụng Gerrit để xem xét mã, một công cụ có tên GerritBot đã được tạo để đồng bộ các pull request trên GitHub với Gerrit.

Hãy mở một pull request trên GitHub như bạn vẫn thường làm. GerritBot sẽ tạo một danh sách thay đổi Gerrit tương ứng (một "CL") và đăng liên kết tới nó trong pull request trên GitHub của bạn; các cập nhật đối với pull request cũng sẽ được phản ánh trong CL trên Gerrit. 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 ý:

Các commit message tốt

Các commit message trong Go tuân theo một tập hợp quy ước cụ thể, được thảo luận trong phần này.

Dưới đây là một ví dụ về một commit message tốt: 

math: cải thiện độ chính xác của Sin, Cos và Tan đối với các đối số rất lớn

Cách triển khai hiện có có các đặc tính số học kém đối với
các đối số lớn, vì vậy sử dụng thuật toán McGillicutty để cải thiện
độ chính xác trên 1e10.

Thuật toán được mô tả tại https://wikipedia.org/wiki/McGillicutty_Algorithm

Fixes #159

Dòng đầu tiên

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

Một quy tắc ngón tay cái là nên viết dòng này để hoàn thành câu "Thay đổi này sửa đổi Go để _____." Điều đó có nghĩa là dòng này không bắt đầu bằng chữ cái viết hoa, không phải là 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 tiên bằng một dòng trống.

Nội dung chính

Phần còn lại của mô tả sẽ giải thích chi tiết hơn và cung cấp ngữ cảnh cho thay đổi cũng như giải thích những gì nó thực hiện. Hãy viết bằng các câu hoàn chỉnh với dấu câu chính xác, giống như các chú thích trong Go của bạn. Không sử dụng HTML, Markdown hoặc 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 cột. Xem Commit message để biết thêm chi tiết.

Thêm mọi thông tin liên quan, 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 phần 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à đã được sửa.

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

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

Quy trình review

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

Những lỗi thường gặp của người mới bắt đầu

Khi một thay đổi được gửi lên Gerrit, thay đổi đó thường được phân loại trong vòng vài ngày. Một maintainer sẽ xem xét và đưa ra một số review ban đầu, đối với contributor lần đầu thường tập trung vào các vấn đề về hình thức cơ bản và những lỗi thường gặp. Các vấn đề này bao gồm:

Trybots

Sau khi đọc sơ bộ 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 toàn bộ bộ kiểm thử trên nhiều kiến trúc khác nhau. Hầu hết trybot hoàn thành trong vài phút, tại thời điểm đó một liên kết sẽ được đăng trong Gerrit để bạn có thể xem kết quả.

Nếu lần chạy trybot thất bại, hãy theo liên kết và kiểm tra toàn bộ log của các nền tảng mà trên đó các bài kiểm thử thất bại. Hãy cố gắng hiểu điều gì đã hỏng, cập nhật patch để sửa lỗi đó, rồi tải lên lại. Các maintainer sẽ kích hoạt một lần chạy trybot mới để xem vấn đề đã được khắc phục hay chưa.

Đôi khi, cây mã nguồn 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 patch 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 hay không. Trong trường hợp này, bạn có thể viết một comment trong Gerrit để đề cập rằng lỗi này không liên quan đến thay đổi của bạn, giúp các maintainer hiểu tình huống. Bạn cũng có thể tìm kiếm các issue GitHub với thông báo lỗi gây ra lỗi hoặc duyệt các issue watchflakes được cập nhật gần đây. Nếu thay đổi của bạn dựa trên một commit cũ hơn hoặc có vẻ như người khác có thể đã sửa vấn đề, hãy thử rebase đến commit master mới nhất bằng git rebase.

Đánh giá

Cộng đồng Go coi trọng các bài đánh giá rất kỹ lưỡng. Hãy nghĩ mỗi nhận xét trong bài đánh giá giống như một ticket: bạn được kỳ vọng sẽ tìm cách "đóng" nó bằng cách xử lý nó, either bằng việc triển khai đề xuất hoặc thuyết phục người đánh giá theo cách khác.

Sau khi cập nhật thay đổi, hãy xem lại các nhận xét đánh giá và đảm bảo trả lời từng nhận xét. Bạn có thể nhấp vào nút "Done" để trả lời, cho biết rằng bạn đã triển khai đề xuất của người đánh giá; nếu không, hãy nhấp vào "Reply" và giải thích lý do bạn chưa thực hiện, hoặc những gì bạn đã làm thay thế.

Việc các thay đổi trải qua nhiều vòng đánh giá là hoàn toàn bình thường, với một hoặc nhiều người đánh giá đưa ra nhận xét mới mỗi lần và sau đó chờ một thay đổi được cập nhật trước khi đánh giá lại. Chu kỳ này xảy ra ngay cả với những contributor có kinh nghiệm, vì vậy đừng nản lòng vì điều đó.

Quy ước về biểu quyết

Khi gần đi đến quyết định, những người đánh giá sẽ áp dụng một “vote” Code-Review cho thay đổi của bạn. Có hai vote có thể có:

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

Maintainer cũng có thể áp dụng vote Hold +1 cho thay đổi, để đánh dấu một thay đổi chưa nên được gửi vào lúc này (ví dụ, vì đánh giá đề xuất cho API mới trong thay đổi chưa hoàn tất).

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

Cuối cùng, để được gửi, một thay đổi phải có sự tham gia của hai nhân viên Google, hoặc với vai trò là người tải lên thay đổi hoặc là người đánh giá bỏ vote ít nhất là Code-Review +1. Yêu cầu này nhằm đáp ứng các lý do về tuân thủ và bảo mật chuỗi cung ứng.

Gửi một thay đổi đã được phê duyệt

Khi một thay đổi đã sẵn sàng, một maintainer sẽ gửi thay đổi đó, thêm nó dưới dạng một commit vào repository Gerrit.

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

Gửi một thay đổi sẽ đưa thay đổi đó vào repository. Mô tả thay đổi sẽ bao gồm một liên kết đến việc xem xét mã, liên kết này sẽ được cập nhật với một liên kết đến thay đổi trong repository. Vì phương thức được dùng để tích hợp các thay đổi là "Cherry Pick" của Git, các mã băm commit trong repository sẽ bị thay đổi bởi thao tác gửi.

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

Thông tin thêm

Ngoài thông tin ở đây, cộng đồng Go duy trì một trang wiki CodeReview. Bạn có thể đóng góp cho trang này khi tìm hiểu thêm về quy trình xem xét.

Các chủ đề khác

Phần này tập hợp một số nhận xét khác nằm ngoài chính quy trình issue/edit/code review/submit.

Gopls

Khi làm việc trên repository Go chính và sử dụng gopls với trình soạn thảo của bạn, lệnh go được gọi bởi gopls phải tương ứng với phiên bản của mã nguồn mà bạn đang làm việc. Lệnh go có thể được xây dựng 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 đủ về Gopls có thể được tìm thấy tại https://godev-vn.tamnd.com/gopls.

Các tệp trong repository Go không liệt kê tên tác giả, vừa để tránh lộn xộn vừa để tránh phải cập nhật các danh sách này thường xuyên. Thay vào đó, tên của bạn sẽ xuất hiện trong nhật ký thay đổi.

Các tệp mới mà bạn đóng góp nên sử dụng tiêu đề bản quyền tiêu 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 repository được bảo hộ bản quyền vào 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 mà bạn thay đổi.

Khắc phục lỗi mail

Cách phổ biến nhất khiến lệnh git codereview mail bị lỗi là vì địa chỉ e-mail trong commit không khớp với địa chỉ bạn đã sử dụng trong quá trình đăng ký.
Nếu bạn thấy nội dung giống 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 repository này để sử dụng địa chỉ e-mail mà bạn đã đăng ký. Để thay đổi địa chỉ e-mail nhằm đảm bảo điều này không xảy ra lần nữa, hãy chạy: 

$ git config user.email email@address.com

Sau đó thay đổi commit để sử dụng địa chỉ e-mail thay thế này bằng lệnh: 

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

Sau đó thử lại bằng cách chạy: 

$ git codereview mail

Kiểm thử nhanh các thay đổi

Chạy all.bash cho từng thay đổi trong cây mã nguồn là việc tốn nhiều công sức. Mặc dù bạn được khuyến nghị mạnh mẽ chạy lệnh này trước khi gửi một 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ử gói mà bạn đang phát triển.

Chỉ định người đánh giá / Thêm CC cho người khác

Trừ khi được yêu cầu rõ ràng khác đi, chẳng hạn như trong cuộc thảo luận trước khi gửi thay đổi, tốt hơn là không nên chỉ định người đánh giá. Tất cả thay đổi được tự động CC đến golang-codereviews@googlegroups.com trong danh sách gửi thư. 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 trong danh sách gửi thư để ngăn thư rác.

Bạn có thể chỉ định người đánh giá hoặc CC cho các bên quan tâm bằng cách sử dụng các tùy chọn -r hoặc -cc. Cả hai đều chấp nhận danh sách địa chỉ e-mail được phân tá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 máy khách của bạn

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

$ git codereview sync

(Bên dưới, lệnh này chạy git pull -r.)

Xem xét mã do người khác viết

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

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

Để hoàn tác, chuyển lại về nhánh mà bạn đang làm việc.

Thiết lập bí danh git

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

$ git codereview sync

nhưng sẽ thuận tiện hơn khi thiết lập bí danh 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 git-codereview đã được chọn để khác biệt với các lệnh riêng của Git, vì vậy an toàn khi định nghĩa các bí danh này. Để cài đặt chúng, sao chép văn bản này vào tệp cấu hình Git của bạn (thường là .gitconfig trong thư mục chính của bạn): 

[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

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

Để gửi một nhóm thay đổi phụ thuộc, hãy giữ mỗi thay đổi là một commit khác nhau trong cùng một nhánh, sau đó chạy: 

$ git codereview mail HEAD

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

Các bản phát hành nhỏ

Nếu bạn muốn thực hiện thay đổi cho một nhánh bản phát hành để backport, hãy xem Các 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.