簡體   English   中英

如何使用 Gitlab 設置代碼審查?

[英]How to set up a code review using Gitlab?

如何使用 Gitlab 設置代碼審查? 我看到它被列為 Gitlab 網站上的一項功能,但我似乎找不到有關如何設置的說明(就此而言,任何指向 Gitlab 用戶手冊的鏈接都將不勝感激)。

我的一些搜索表明“合並請求”是要走的路......但我發現它們有限制。 發出的合並請求顯示一個分支和另一個分支之間的所有提交。 我似乎只能查看為每個單獨提交生成的差異。 例如,假設我有一個要查看的文件。 這是一個新文件,但我已經在 dev 分支上提交了超過 10 次提交的更改。 如果我從集成中為該開發分支發出合並請求,我會看到 10 個提交,每個提交都顯示對文件所做的增量更改...我想查看整個內容。 這是新的!

我在這里吠錯樹了嗎? 是否有我可以在 GitLab 中使用的實際代碼審查工具,或者合並請求是否可行,如果是,我是否錯誤地使用了它們? 在這里設置適當的代碼審查的最佳方法是什么?

注意:從 GitLab 6.4 開始,可以使用並排差異視圖:請參閱“ pull request 5308 ”。

(2013 年 7 月) 不過,目前還不可能對每一行進行評論,只能在文件級別進行評論。
Daniel Sokolowski 在評論中提到現在支持每行評論(09/2014):

您的團隊成員可以對合並請求進行一般性評論,也可以對帶有行注釋的特定行進行評論。

這仍然有助於代碼審查活動。

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 年后,對於GitLab 13.1(2020 年 6 月)

合並請求評論移至核心

最初在 GitLab 11.4 中作為 GitLab 高級功能引入,合並請求審查允許合並請求審查者:

  • 一次提交多條評論,
  • 減少合並請求作者的通知噪音,以及
  • 允許更有凝聚力和簡化的審查過程。

https://about.gitlab.com/images/13_1/batch_comments.png

自推出以來,我們重新評估了它在基於買方的定價模型中的地位,作為 13.1 的一部分,我們很高興地宣布此功能現已轉移到 GitLab Core。

請參閱文檔問題


使用GitLab 13.9 (2021 年 2 月),您還可以:

要求審稿人進行后續審閱

合並請求作者會收到審閱者的反饋 通常,需要重新審查這些反饋,以確保所有問題都得到了適當的解決。 作為貢獻的作者,您需要向您的審稿人傳達跟進的需求。

對於已經審核過合並請求的審核者,您現在可以請求重新審核。 此請求會觸發待辦事項和電子郵件通知,以提醒用戶您需要對您的貢獻進行后續審查。

https://about.gitlab.com/images/13_9/create_code_review-request-re-review.png -- 要求審稿人進行后續審查

請參閱文檔問題


使用GitLab 13.11 (2021 年 4 月)

添加獨立評論以合並請求評論

當您查看更改時,您可能想要總結您的反饋,或評論與特定更改無關的內容。 評論在GitLab只允許評論更改或答復現有評論,這意味着其他種類的意見提交了審查后作出。

作為審核過程的一部分,您現在可以提交一般性評論以及您的回復或特定於更改的評論。 通用注釋使向作者提供反饋並使用快速操作更新合並請求中的項目變得簡單。

感謝Lee Tickett的貢獻!

https://about.gitlab.com/images/13_11/code-review-add-comment-mr-review.png -- 添加獨立評論以合並請求評論

請參閱文檔問題

我在 Gitlab 中進行代碼審查已經兩個多月了,幾乎沒有任何摩擦。 我已經設置了rss2email以在開發人員每次推送新提交時發送電子郵件通知。 然后我使用Gitlab 的comment 功能進行commits 對推送的代碼做一些評論。

不幸的是,Gitlab 不允許對文件本身進行評論,只允許在提交中(就像 Github,我猜)。 每當我發現自己需要評論之前提交中遺漏的某些內容時,我都會使用blame工具來查找引入/更改要評論的代碼部分的提交。

它遠非完美,但到目前為止運行良好。

您可以在其他存儲庫或當前存儲庫的合並請求中查看提交的代碼。
示例http://demo.gitlab.com/diaspora/diaspora/commits/master

然后您可以向提交的文件更改(按鈕Reply )或整個提交添加注釋

示例http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

由此產生的交流是代碼審查 但是,我個人建議盡可能在一台 PC 上進行代碼審查,並進行面對面的交流,並使用工具來記錄結果或需要更多形式。

對於有很多提交的文件評論,例如http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md使用blame查看它以了解誰做了什么。 但是,在此視圖中,無法進行交流和添加評論。 在這種情況下,我建議只將更改添加為注釋。

是的。 合並請求是同行評審的完成方式。

應該有一個“差異”選項卡,將顯示所有提交的更改(此處提到:http: //youtu.be/DyAX8ws5OIc?t=3m2s )。

該視頻還很好地解釋了如何將其用於同行評審。

代碼審查的正常用例是在合並到 master 或類似分支之前審查分支上的代碼。 我有一種情況,我開發了一個項目,並希望團隊中的每個人都審查所有代碼。

我所做的是:

簽出第一個提交,對其進行更改,提交並推送

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

簽出最后一次提交,對其進行更改,提交並推送

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

在 GitLab / GitHub 上,創建一個拉取請求

  • 它是從 LAST_COMMIT 到 FIRST_COMMIT 的合並

為我工作!

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM