§使用 Git
本指南旨在協助新參與者開始使用 Play。這裡提到的某些事項是我們認為不錯且有助於參與 Play 的慣例，但這些慣例絕對不是強制性的，您應該使用最適合自己的方法。
§Git 遠端
我們建議將官方 Play 儲存庫的遠端稱為 origin，而將您的分支遠端稱為您的使用者名稱。當在多個分支之間共用程式碼時，此慣例非常適用，而且是我們將在本指南中所有其餘 git 指令中使用的慣例。它也是與 GitHub 命令列工具 搭配使用時最能順利運作的慣例。
§分支
通常，所有工作都應該在分支中完成。如果您直接在主分支上工作，則一次只能提交一個拉取請求，因為如果您嘗試從主分支提交第二次，則第二次將包含來自您的第一次和第二次提交。在分支中工作允許您將拉取請求相互隔離。
分支的名稱由您決定，有些人喜歡在分支名稱中包含問題編號，而另一些人則喜歡使用階層結構。
§壓縮提交
我們希望所有拉取請求都是單一提交。這樣做的原因有幾個
- 將單一提交回傳到穩定分支比回傳提交組更容易，而且錯誤更少。如果更改只在一個提交中，則沒有錯誤的機會，整個更改都被挑選出來，或者沒有。
- 我們的目標是讓我們的 main 分支始終可發布，不僅是現在，而且在歷史上的所有時間點都是如此。如果我們需要備份某些內容，我們希望確信之前的提交是穩定的。
- 當更改自包含在一個提交中時，更容易全面了解歷史中發生的事情。
當然，在某些情況下不適合壓縮提交，這將根據具體情況決定，但我們不需要壓縮提交的示例包括
- 當拉取請求包含多個人的提交時。在這種情況下，我們希望在有意義的情況下壓縮同一個人連續的提交。
- 當拉取請求來自社區中共享的分支或分支時，重寫歷史會導致從該分支或分支拉取更改的人出現問題。
- 當 pull request 的工作量很大，而且提交記錄有助於了解該工作的演變時。
但是，對於一般情況，如果你的 pull request 包含多個提交，那麼你需要壓縮它。為執行此操作，或者如果你已經提交 pull request，而我們要求你壓縮它，那麼你應該執行下列步驟
-
確保你的儲存庫中包含核心主分支的所有變更
git fetch origin -
開始互動式 rebase
git rebase -i origin/main -
這會在你的編輯器中開啟一個畫面，讓你說明每個提交應該如何處理。如果第一個提交的提交訊息適合用來描述所有提交，那麼就保持原樣，否則，將其命令從
pick變更為reword。 - 對於每個其餘的提交，將命令從
pick變更為fixup。這會告訴 git 使用前一個提交的提交訊息，將該提交併入前一個提交。 - 儲存檔案並離開你的編輯器。Git 現在會開始 rebase。如果你告訴它重新表述第一個提交，它會在新的編輯器中提示你輸入該提交的表述。如果一切順利，那麼你就完成了，但將變更套用到最近的主分支時可能會發生衝突。如果是這樣，修正衝突，暫存修正，然後執行
git rebase --continue如果還有更多變更發生衝突，可能需要重複此步驟。
- 現在你已經 rebase，你可以推送你的變更。如果你之前已經推送過這個分支（包括如果你已經建立 pull request），那麼你必須執行強制推送。這可以這樣做
git push yourremote yourbranch --force
§回應評論/建置中斷
如果您的 pull request 未通過 CI 建置，如果我們審查並要求您更新 pull request，或者由於任何其他原因您想要更新 pull request，那麼請修改現有的提交，而不是建立新的提交。這可以在提交時提供 --amend 旗標來完成
git commit --amend
在進行修改後，您需要使用 --force 旗標進行強制推送
git push yourremote yourbranch --force
§重新開始
有時人們發現他們的 pull request 完全錯誤，並希望重新開始。這很好，但是沒有必要關閉原始的 pull request 並開啟新的 pull request。您可以使用強制推送將全新的分支推送到 pull request 中。
要重新開始，請確保您已取得 Play 核心中的最新變更，並從該點建立新的分支
git fetch origin
git checkout -b mynewbranch origin/main
現在進行變更，然後當您準備提交 pull request 時，假設您的舊分支稱為 myoldbranch，將您的新分支推送到儲存庫中的舊分支
git push yourremote mynewbranch:myoldbranch --force
現在 pull request 應該會更新為您的新分支。
§關於變更歷程的說明
您可能聽說過在發布 git 歷程後不應變更 git 歷程。使用 rebase 和 commit --amend 都會變更歷程，而使用 push --force 會發布您變更的歷程。
在發布後，肯定有時候不應變更 git 歷程。主要時間點是當其他人可能會分岔您的儲存庫，或從您的儲存庫中提取變更時。在這些情況下變更歷程將使他們無法安全地將變更從您的儲存庫合併到他們的儲存庫中。因此，我們絕不會在官方 Play Framework 儲存庫中變更歷程。
不過，對於你的個人分支，對於僅打算作為拉取請求的分支，則情況不同 - 工作流程的目的是，你的變更一旦合併到主分支中，就會「發布」。在此之前，歷史記錄可以視為進行中的工作。
然而，如果你的分支是許多人的協作，而且你相信其他人有充分的理由從你的分支拉取，請讓我們知道，我們不會在沒有意義的情況下強制壓縮提交。
下一步：關於 Play
在此文件中發現錯誤？此頁面的原始碼可以在 這裡 找到。在閱讀 文件指南 後，請隨時提交拉取請求。有問題或建議要分享？前往 我們的社群論壇 與社群展開對話。