今天的故事

在 Day 2，我整理了 PawPal 這個專案是怎麼出現的，也回顧了自己第一次加入團隊專案時的感受。

當專案方向確定後，接下來就要正式進入分工與協作。

而這時候，我才第一次真正把 Git 和 GitHub 用在多人協作裡。

在開始 PawPal 專案之前，我對 Git 幾乎完全不了解。

以前看朋友寫後端專案時，朋友曾經提過類似「版本控制」的概念，但那時候我其實沒有真的聽懂，也沒有太深的感覺。

直到後來課程開始教 Git，我才突然想起來：

原來朋友之前說的，就是這件事。

一開始我以為 Git 只是把程式碼存起來，或是把作業上傳到 GitHub。

但真正進入 PawPal 團隊專案後，我才發現，Git 沒有想像中那麼簡單。

Git 處理的，也不只是我自己的程式碼。

它會牽涉到分支、Pull Request、Code Review、合併、衝突，還有整個團隊的開發流程。

對當時的我來說，Git 甚至比寫功能還讓我緊張。

我原本以為 Git 只是上傳程式碼

剛開始學 Git 的時候，我就是一個完全的新手小白。

我只知道課堂上有教一些基本操作，例如把檔案加入版本控制、commit、push 到 GitHub。

但那時候我還沒有真的理解：

為什麼需要版本控制？
為什麼要開分支？
為什麼不能大家都直接改同一條線？
為什麼 Pull Request 需要別人看過？

對我來說，Git 一開始比較像是一個「課程要求一定要會用的工具」。

我知道它很重要，但還沒有真正體會到它為什麼重要。

所以剛開始多人協作時，我其實沒有什麼「習慣不習慣」的感覺。

因為我很清楚自己什麼都不會。

我就先把自己當成新手，只懂課堂教過的內容。

遇到不會的地方，就去找方法、問同學、問老師，或是請 AI 幫我拆解步驟。

那時候的心態比較像是：

先照著流程做，至少不要亂來。

但後來我才知道，Git 不是只要照著按就好。

有些操作，如果沒有理解背後的意思，真的可能會影響到整個專案。

PawPal 團隊的分支協作方式

在 PawPal 專案裡，我們以 main、dev 和功能分支進行開發與協作。

平常開發時，不會直接在 main 上改東西。

我們主要是從 dev 分支開出新的功能分支。
也就是每一張票、每一個功能，會有自己對應的分支（branch）。

功能完成後，再透過 Pull Request 讓組員檢查，確認沒有問題後才合併回去。

最後比較穩定的版本，才會再整理到 main。

對當時的我來說，這整個流程其實很新。

真正進入團隊專案後，我才發現，Git 不只是自己會不會操作的問題，而是整個團隊能不能安全協作。

我們團隊也有自己的協作規則，Pull Request 開啟後不能直接合併。

PR 需要讓所有成員看過，確認沒有問題後才會進行合併。

除此之外，我們也每天進行站立會議，更新每個人的進度。

誰正在做哪一張票、哪些功能準備合併、現在卡在哪裡，這些都會在會議中同步。

現在回頭看，這些流程其實都是為了讓專案更安全。

但對當時的我來說，光是聽到這些流程，就已經有點壓力。

因為每一步都代表我不能只顧自己。

我的分支有沒有開對？
我的 commit 有沒有問題？
我的 PR 會不會影響別人？
我的程式碼合進去之後，會不會讓整個專案壞掉？

這些問題，在團隊專案裡會變得很真實。

比起寫功能，我更怕按錯 Git

在 PawPal 專案裡，比起寫功能，我有時候更怕 Git 相關的操作。

因為寫功能卡住時，至少還可以慢慢查、慢慢改。

可是 Git 操作給我的感覺很不一樣。

每次要按一個按鈕、送出一個 PR、合併某段程式碼，或是處理衝突時，我都會很忐忑。

我會怕自己不小心改壞整個專案。

也會怕在解衝突時，不小心刪掉組員的程式碼。

尤其是看到 GitHub 或 VS Code 跳出一堆看不太懂的畫面時，那種壓力真的很明顯。

明明只是按一個按鈕，心裡卻會想很多：

這樣按對嗎？
會不會推錯分支？
會不會把別人的東西蓋掉？
如果我解錯衝突，會不會害大家一起出問題？

這也是我第一次真正感受到，多人協作不是只會寫程式就好。

還要知道怎麼安全地把自己的程式碼放進團隊專案裡。

第一次踩坑：分支開錯了

我印象很深的一次，是在開發某一張票的時候。

那時候我照著任務開始做功能，也一路把功能做完。

結果後來才發現，我不是從 dev 開新的分支。

而是在上一張票的分支上，又開了一個新的分支。

當下我其實有點慌。

因為我知道分支是從某個時間點的程式碼開出去的，但那時候還沒有真正理解，如果分支的起點選錯，後面會造成什麼影響。

我只知道：

完了，我好像不是在正確的地方開始做這張票。

那時候我沒有直接亂操作。

我先把畫面截圖，再把目前發生的狀況描述清楚，去詢問 AI 接下來應該怎麼處理。

接著照著它給的步驟，一步一步慢慢確認、慢慢解決。

雖然現在已經有點忘記當時具體用了哪些指令，但那次經驗讓我很明確地感受到：

Git 不能只靠感覺操作。

尤其是分支，如果一開始開錯地方，後面 Pull Request、合併、整理紀錄都可能變得比較麻煩。

以前我可能會覺得，只要功能有做出來就好。

但在團隊專案裡，功能做出來只是其中一部分。

你的分支乾不乾淨、來源對不對、能不能順利合併，這些也很重要。

第二次踩坑：解衝突把動畫刪掉了

另一個讓我印象更深的事件，是手機版側邊欄動畫。

那是一個比較後期才發現的問題。

在某一次解衝突的過程中，我不小心把手機版側邊欄的動畫刪掉了。

但當下其實沒有立刻發現。

因為解完衝突後，只要畫面看起來大致還能跑，就很容易以為沒事。

直到專案後期在做優化時，才發現：

咦？手機版側邊欄的動畫怎麼不見了？

後來回頭追問題時，才發現是我在解衝突時改壞的。

那時候其實有一點小抱歉。

因為這不是單純自己功能壞掉，而是我在解衝突時，不小心影響到原本已經做好的效果。

這件事也讓我真正發現：

衝突不能亂解。

不能只是看到 Git 提示有衝突，就想趕快把衝突消掉。

更重要的是，要理解衝突兩邊的程式碼各自在做什麼。

哪一段是自己的修改？
哪一段是組員的修改？
哪一段要保留？
哪一段如果刪掉，可能會影響原本功能？

這些都不能只靠感覺。

那次之後，我對解衝突這件事變得更小心。

因為我知道，有些問題不一定會馬上爆出來。

可能到後面某個功能被測試、某個畫面被重新檢查時，才會發現原來之前就被改壞了。

Git 不是只保護自己的程式碼

經過 PawPal 專案後，我對 Git 的想法改變很多。

一開始我以為 Git 只是用來存自己的程式碼。

像是：

• 把檔案記錄下來
• 把作業推到 GitHub
• 讓老師或組員看得到

但後來我才慢慢發現，Git 在團隊專案裡的角色更重要。

它可以記錄每一次修改。

也可以讓不同人分別在自己的分支上開發，不會全部擠在同一條線上。

Pull Request 可以讓大家在合併前先檢查程式碼。

如果之後發現問題，也可以回頭追蹤是哪一次修改造成的。

像手機版側邊欄動畫不見那件事，如果完全沒有版本紀錄，其實很難知道到底是哪裡被改掉。

所以 Git 不是只保護我自己的程式碼。

它是在保護整個團隊的專案。

它讓大家可以一起開發，但又不會完全失控。

這也是我後來才理解到的事情。

我對 Git 的想法改變了

前期上課時，我對 Git 的重要性其實沒有太深的感覺。

那時候比較像是老師說要用，所以就跟著學。

但 PawPal 開始之後，我才慢慢理解，為什麼團隊需要清楚的分支與協作流程，也需要透過 Pull Request 和 Code Review 檢查修改，不能讓每個人都直接把程式碼推到主線。

分支開錯，讓我知道開始的位置很重要。

解衝突時刪掉動畫，讓我知道合併程式碼不是只要讓衝突消失就好。

Pull Request 需要大家看過，也讓我知道，程式碼進入團隊專案之前，應該要被檢查。

這些經驗加起來，讓我對 Git 的理解不再只是「工具」。

它更像是一種團隊協作的規則。

也因為這次經驗，我開始覺得，未來選擇公司時，不只是看使用什麼技術，也會想了解團隊有沒有良好的版本控制和協作流程。

因為會不會使用 Git，不只是工程師個人的問題。

它也代表一個團隊怎麼管理專案、怎麼保護程式碼、怎麼讓大家一起工作。

本篇重點與心得

這一天回頭整理 Git 的經驗，我最大的感覺是：

Git 對新手來說，真的不簡單。

它不像某一段 JavaScript 語法，只要理解輸入和輸出就好。

Git 比較像是一套協作規則。

你要知道自己在哪個分支。
要知道這個分支從哪裡開出來。
要知道自己的修改會合到哪裡。
也要知道如果和別人的修改撞在一起，應該怎麼處理。

一開始我真的很怕按錯。

但也因為這些害怕，我才開始慢慢理解 Git 的重要性。

現在回頭看，Git 不是要讓新手害怕的工具。

它其實是多人協作時很重要的安全網。

只是這個安全網，要真的踩過幾次坑，才會知道它為什麼存在。

下一篇預告

今天，我整理了自己第一次在 PawPal 團隊專案裡使用 Git 和 GitHub 的經驗。

從完全不懂版本控制，到開始理解分支、Pull Request 和合併衝突，我才知道多人協作真的沒有想像中簡單。

接下來，我想聊聊正式開始開發時，AI 是怎麼幫助我走過卡關，又為什麼不能取代我真正理解專案。

下一篇會聊聊：

第一次真正開始開發，AI 如何幫助我，而不是取代我。