昨天我們已經把我們的 statcast_search function 的基本型建出來，今天要來大家介紹如何在 Github 上建立一個 Pull Request 來跟其他開發者互動。大家可以先複習一下我在 上傳程式碼回 Github 提到的如何 commit 跟 push。不過這次我們變成不是直接 push 主枝幹，而是要先把我們這次創建的 branch 給 push 上去。

先來看看我們在本地端這次的改動：

可以看到幾個改動的點：

1. 多了幾個 __pycache__ 資料夾
2. 新增了 statcast 資料夾來存放我們的 function statcast_search
3. 原本的 example.py 放到最外面

example.py

先來看新的 example.py，原本是用來測試上傳到 TestPyPI 有沒有問題的檔案，現在我改成測試我們在 src 開發的程式碼了，變成只是一個測試程式碼。不過這只是一個很陽春的手動測試，裡面的內容就是簡單的呼叫這次寫的 statcast_search，看能不能順利執行。之後要更完善一點就會需要自己寫 pytest 的 Test File。

# example.py
"""Example usage of the baseball_stats_python package."""

from src.baseball_stats_python.statcast.statcast_search import statcast_search


def example():
    df = statcast_search(pitchers_lookup="477132")
    print(df)


example()

.gitignore

接下來是 __pycache__ 的資料夾，裡面會存放我在執行 python {檔案名}.py 後所產生的快取檔，可以讓我們下次執行同個檔案可以執行更快，如果想避免產生她的話就要使用 python -B {檔案名}.py。

這種自動產生的快取檔，會因為每個人的本地 Python 環境而有所不同，所以不用特地上傳到 Github 上面給別人看。這時候就會需要一個設定檔 gitignore 讓 git 不去追蹤我們寫在 .gitignore 檔裡的資料夾或檔案（記得要用 . 開頭）。
.gitignore 檔案內容會像是：

# Ignore all cache files
__pycache__/
*.pyc

# Ignore auto-generated dist directory
dist/

存檔後就會發現原本亮起來的 __pycache__ 按掉了，另外我這邊習慣那些會自動產生的檔案都不上傳，所以我們之前需要產生的上傳打包檔 dist 我也一起 Ignore 掉。不過要注意的是已經讓 git 追蹤過的資料夾，如果要 ignore 掉要先使用 git rm -r --cached {資料夾或檔案名}。
詳情可以看這篇文章：https://stackoverflow.com/questions/59561657/how-can-i-ignore-dist-folder-in-gitignore-file

Push to Origin

.gitignore 跟 example.py 處理完後，我們再根據我們的感動把他們 commit 起來就可以準備好上傳了。
再上傳之前可以先用 git log 來看一下我們一些 commit 紀錄：

可以發現到幾點：

1. 最新的 commit 有顯示 (HEAD -> feature/statcast-fns)
2. 在我們上次的 commit 有顯示 (origin/main, origin/HEAD, main)

第一項比較好懂，HEAD 就代表我們目前所在的 commit 位置，然後是在 feature/statcast-fns 的 branch 底下。第二項的話 main 是在說我們之前本地端的 main branch 所在的 commit，那沒那些前面有加 origin 的呢？他們其實就是我們在 Github 上目前所在的 commit 跟 main 在哪。我可以使用 Git 指令 git remote -v 來查看，就能發現我們現在會有個 origin 來搭配我們之前在 clone 的時候使用的網址。

雖然現在只有 origin 這個代表，但以後如果有其他使用者使用 Github 的 Fork，就有機會用 git remote add {新代號} {clone_url} 把他新增到我們的 remote 裡。篇幅問題所以今天先不詳細介紹，之後如果還有時間我可能可以用 pybaseball 來當作示範解說。

總而言之，目前 origin 就代表我們在 Github 上面的 Repo 頁，所以在我們改完 feature/statcast-fns 的時候，Github 上面是還沒有的，我就需要也把他 push 上去。如果我們直接使用 git push 會獲得錯誤，因為 Git 會不知道目標會在哪。但如果我們再加上 origin 變成 git push origin feature/statcast-fns 就會發現上傳成功了。

回去 Repo 頁會發現有一個通知問我們要不要創建 Pull Request

Pull Request 簡單來說，就是向我們的目標 branch 發出合併的請求，希望可以把這次的改動回去主要的程式碼裡，透過標題跟敘述讓其他開發者知道這次的改動有哪些，也讓管理者可以確認改動的內容，就不會有隨便亂更動到主要程式碼的問題產生。
點進去就會要有看到有輸入標題跟敘述的空間，再往下滑回有這次改動跟預設 branch main 的程式碼差異（diff）。我們也可以把目標改成其他的 branch。

Pull Request 的標題與敘述也會有撰寫的規則，跟前面的 commit 和 branch 命名一樣，都是為了團隊開發能更快瞭解改動的內容所需才要訂定，之後可以設定 template 讓撰寫更快速。我自己習慣為：

• 標題：用 [] 表達這次的 PR 種類，像是 [Feature], [Bugfix]，也可以不止一個，有時候還會加上 [WIP] 表示 Work in Progress 還在開發，不要 merge 之類的提醒
• 敘述：清楚描述這次改動的範圍，改動的內容，測試連結等。如果是 Bug 的處理，可能要寫發現 Bug 的地方，怎麼重現，跟什麼原因與怎麼處理等。

撰寫的方式很多種，最後一樣也是大家說好規則去遵守就好，這次只是簡單的 PR，所以我就不會寫的那沒詳細。
當我們寫好標題與敘述後，點選 Create Pull Request 按鈕，就能看到我們第一個 PR 建立出來，就能用連結來分享給其他人看：https://github.com/ss77995ss/baseball-stats-python/pull/1

裡面除了我們剛剛寫的標題與敘述，也能看到我們這次改動的 commit，跟檔案的 diff，如果有其他 Reviewers 的話，他們也可以在 File Change 那邊開始 Review 留言，跟開發者進行互動。範例的話可以參考我在 pybaseball 上的互動。

確定這次的改動都沒問題後，就可以拉到下面點選 Merge pull request 完成 merge。不過因為我就是管理者，所以可以直接合併，不過通常都會增加一些規則，像是要經過 Reviewer 同意才可以，或是之後我們有設定自動化測試，要通過才能合併。Merge 成功後會問要不要刪除這次的 branch，我通常是都會刪掉。

本日小結

從 push 到 origin 然後再開 PR 後 merge 的流程大概介紹到這邊，可以再回到我們的 Repo 頁看到我們這次的更新。基本上要一起開發開源軟體都會需要知道如何建立一個 Pull Request，大家可以自己開一個 Repo 多練習。
最後一樣感謝大家耐心地看完今天的文章，明天會再把 functions 更完整，有任何問題或建議也一樣歡迎留言告訴我，明天見了，掰掰。