閱讀文件

有幾個文件是必讀的，這些文件有可能是 .md 檔、.rst 檔、或是網站裡面的某一頁：

  • README.md：介紹專案的檔案。
  • Contribution Guide：要怎麼貢獻這個專案、提交貢獻時需要遵守哪些格式或規定等。
  • Code of Conduct：社群的行為守則，基本上你不要太誇張應該都不會踩到線，但還是要看一下。

Issue Tracker

了解專案使用的是什麼 Issue tracker，常見的有直接用 GitHub issues 或是用 JIRA。新手通常是去找現有的 issue 來解，如果要自己開 issue 的話，務必先搜尋一下有沒有重複的 issue 已經被開過了。

Commits

注意該專案有沒有要求 commit message 的格式，建議養成好習慣，不要亂寫 commit message。如果沒有特別要求，可以參考 Conventional Commits 。基本上格式會像下面這樣：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

範例：

feat: Add XXX feature.

fix(frontend): Fix XXX bugs.

而最常見的 type 有以下幾種：

  • feat：增加新功能。
  • fix：修 Bug。
  • docs：改文件。
  • refactor：Refactoring，也就是程式碼邏輯沒有變。
  • test：新增或修改測試。
  • chore：雜事，不知道怎麼分類就用 chore。

有的專案的符號或是大小寫的格式會不太一樣，例如：

[Feat] Add XXX feature.

[Fix][Frontend] Fix XXX bugs.

另外有的專案會提供 pre-commit hooks，有的話請照著指示安裝。

有的專案會要求每個 commits 都必須被 sign-off，詳細請參考我的另一篇教學 開發開源專案常用的 Git 操作指南 。

Pull Request

如果沒有特殊情形，一個 Pull Request 就是對應一個 issue。基本上要發 Pull Request 前，如果沒有對應的 issue，要先去開一個 issue。但是如果專案沒有強制規定，且你的 Pull Requst 改動的內容也很少，則也可以直接發 Pull Request。

一些特殊用語

有時候 reviewer 會留下一些不常見的縮寫詞或用語，除了自己要看得懂之外，你也可以學著用這些用語，感覺都變專業了😂

  • LGTM：Looks good to me。表示 reviewer 覺得你的 code 沒有問題。
  • PTAL：Please take a look。請求其他人幫忙 review。
  • WIP：Work in progress。表示這個 PR 還沒準備好。
  • ditto：「同上」的意思。
  • nit：表示 reviewer 建議你修改，但他覺得這不是很重要的修改，所以你可修可不修。例如：nit: Rename this variable to XXX。