已經超過 5 年，我沒在 Github 開過技術性的 PR 或 issue，但這週我學到了一些好做法和術語，整理成了這篇文章。
前言
這週我做了一件很簡單的事：我更新了一個開源專案的 README，這個專案是 He4rt 社群的 4noobs。我換了一個徽章、調整了一個標誌的對比度、整理了幾個資料夾，還加了一個索引方便瀏覽。說到底都不是什麼很複雜的事。
只是，在走到「說到底都不是什麼很複雜的事」之前，我曾經因為一個蠢問題糾結了好一陣子：
「如果我直接把這些推到主分支，把一切弄亂了怎麼辦？」
如果你在動到一個不只屬於自己的儲存庫之前，也曾經有過這種緊張感，這篇文章就是給你的。不管你已經當了很多年工程師，還是這輩子從沒開過終端機……「如何在不弄壞任何東西的情況下做出貢獻」背後的邏輯其實都一樣，而且比想像中簡單得多。
協作式 Git 的定義
幾年前我學 Git 的時候，只學到了版本控制，以及把檔案送到 Github 裡面，但它其實不只這樣，對吧？
它讓大型團隊能夠有條理地針對同一個專案互動，評論、管理任務、提出改進，並了解其他相關成員正在做什麼。這就是協作式 Git的部分。
Git 透過一個核心概念來解決這件事：branches（或「分支」）。每個分支就像是專案的一份平行副本，你可以隨意修改，而不會影響到「正式」版本（通常稱為 main 或 master）。當你完成自己的部分後，再提出把這些變更納入回去的 Pull Request（PR）。
也就是說，基本流程是：
- 從主專案建立一個新的分支
- 在那個隔離的空間裡進行修改
- 把這個分支
push到遠端儲存庫 - 開啟一個 Pull Request，請求這些變更被審查，若通過則與主分支
merge
沒有人會直接動到專案的「正式版」。這就是為什麼成百上千的人可以對同一個儲存庫做出貢獻，卻不會讓混亂失控。
主要收穫
實際上，就是在動手的過程中，我學到了（也重新想起了）一些我覺得值得分享的事：
新分支不是不信任，而是安全。 為每一次貢獻建立一個分支，不是沒有意義的繁瑣流程——它保證了如果真的出錯，錯誤會被隔離在那裡，不會影響主專案。這對貢獻者和審查者都一樣重要。
git push 不等於開 Pull Request。 這點讓我有點意外：push 只是把你的分支送到 GitHub；PR 則是另一個步驟，用來正式提出審查請求。順帶一提，終端機在你 push 之後，通常也會直接給你建立 PR 的連結。
不一定要有 issue 才能貢獻。 我曾經卡在這件事上好一陣子。我會想：「啊，可是沒有人提出這個改善，我真的可以直接送嗎？」可以！ 尤其是文件類修改：如果你看到了可以改善的地方，這個貢獻本身就是理由。
好的 PR 描述，不是把每一行改了什麼都列出來。 它應該是一個分類清楚的摘要，例如：
- 做了什麼，
- 為什麼要做，
- 以及按主題整理的重點。
這能替審查者省下非常多時間。
.github 資料夾可以是儲存庫層級的，也可以是整個組織共用的「標準設定」，這取決於帳號底下是否有一個真的就叫做 .github 的特殊儲存庫。這是個小細節，但能幫助理解為什麼有時候某些設定會「出現在」好幾個儲存庫裡，卻沒有人真的逐一複製貼上。
這些點單獨看都不難。通常真正卡住我們的，不是技術——而是害怕。
管理做錯的恐懼
老實說，這大概是我覺得這篇文章最重要的部分。
每次我要動到一個不只屬於自己的儲存庫，不管是開源專案，還是在工作上，心裡都會有種擔心：「如果我弄錯了怎麼辦？如果我把東西弄壞了怎麼辦？如果別人覺得我不知道自己在做什麼怎麼辦？」
而且說真的，這種感覺不會一下子就消失。但有兩件事大大改變了我和這種恐懼的關係：
理解工具，會削弱恐懼的力量。
我們害怕的很多事情，本質上都是因為未知。當我理解到分支其實就是一個完全隔離的空間，而且在有人核准合併之前，我在那裡做的任何事都不會影響 main，恐懼感就減少很多了。這不是要你很勇敢，而是因為你知道系統本來就是被設計來保護大家不要出錯的。
在公開場合出錯，本來就是流程的一部分；不是流程失敗。
整個 開源社群 都是建立在大家互相犯錯、修正、審查彼此工作的基礎上。被拒絕的 PR，或是需要調整的 PR，並不是對你能力的判決，而是這個系統正常運作的證明。
如果有一件事是我希望自己在開始貢獻之前就有人告訴我的，那就是：沒有人期待你一開始就什麼都懂。分支、PR、審查，這些機制存在的原因，正是因為犯錯本來就是過程的一部分。
所以，如果你一直拖著不敢開第一個 PR，只因為怕自己做錯了：就建立分支、做出修改，然後直接送出去吧。最糟的情況也不過是有人給你回饋——而說到底，這正是我們學習和進步的方式。
補充資料
以下是我在上面描述的實作過程中，被推薦或閱讀過的所有資料。有些是教結構，有些是教好做法。我也得到了朋友很多幫助，並且透過 AI 做了不少查詢，來理解我原本看不懂的術語或程式碼片段。
- How to Write a Bug Report
- What Makes a Good Bug Report
- Revisando alterações propostas em um Pull Request — GitHub 文件
- Where to Publish: Article Types — Frontiers
- Conventional Branch
- Semantic Versioning (SemVer) in 繁體中文
如果這篇文章有幫助到你，請留下愛心 💜，也歡迎在留言區分享：
你的第一個 PR，或你第一次對一個不屬於你的專案做出貢獻，是什麼時候？一起來聊聊吧！
原文出處：https://dev.to/he4rt/1a-vez-trabalhando-com-git-com-time-tudo-que-voce-precisa-saber-19il
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
