### 推送流程（想像成將文件上傳到雲端） 推送過程包括準備你的更改、用信息提交它們，然後將它們推送到像 GitHub 這樣的遠程倉庫。這類似於將文件上傳到雲端。 1. **將更改添加到暫存區：** ```sh git add . ``` 此命令將所有修改和新文件添加到暫存區，為下一次提交準備。 2. **提交更改：** ```sh git commit -m "你的信息" ``` 在這裡，你將暫存的更改連同解釋已更改內容的提交信息一起提交到本地倉庫。 3. **將更改推送到遠程倉庫：** ```sh git push ``` 此命令將你提交的更改上傳到遠程倉庫，使它們可以被他人訪問或與雲存儲同步。 ### 拉取流程（想像成從雲端下載文件） 拉取涉及從遠程倉庫獲取更新並將它們合併到你的本地分支。這就像從雲端下載文件。 1. **獲取最新更改：** ```sh git fetch ``` 此命令從遠程倉庫下載更新，但不會將它們合併到你的本地分支。這對於查看其他人所做的工作而不立即將這些更改合併到你的工作中非常有用。 2. **拉取最新更改：** ```sh git pull ``` 這結合了獲取最新更新和將它們合併到你當前的本地分支中，有效地下載並整合最新更改。 ### 創建一個新分支 為了開始開發一個新功能或修復，你可能需要創建一個新分支。這允許你獨立於主項目工作於你的更改上。 - **創建並切換到一個新分支：** ```sh git checkout -b main_page ``` `git checkout -b` 命令創建一個名為 `main_page` 的新分支並立即切換到這個分支，為在這個新分支上的工作設置你的工作區。 - **將新分支推送到 GitHub（遠程倉庫）：** 創建並切換到你的新分支後，如果你希望這個新分支在 GitHub 上也可遠程訪問，你可以使用以下命令推送它： ```sh git push -u origin <branch-name> ``` 將 `<branch-name>` 替換為你實際的分支名，例如 `main_page`。`-u` 標誌設置了你的分支的上游，意味著將來對這個分支的推送或拉取可以使用 `git push` 或 `git pull` 而無需指定分支名。 ### 處理多個PR和衝突解決 #### 情境： - 多個貢獻者提交PR，將他們的分支（例如，A分支、B分支）合併到主分支。 - 最初，A分支和B分支的PR之間沒有衝突。 - 如果首先將A分支的PR合併到主分支，B分支的PR可能會產生衝突。 - 將新的PR合併到主分支也可能導致其他人的本地分支發生衝突，尤其是如果這些分支是基於主分支的早期狀態。 #### 管理PR和衝突的步驟： 1. **切換到本地主分支：** ```sh git checkout main ``` 此步驟涉及更改到本地主分支以拉取最新更改。 2. **用最新更改更新本地主分支：** ```sh git fetch origin main git pull origin main ``` 從原始的主分支獲取並拉取最新代碼到你的本地主分支。 3. **切換到B分支：** ```sh git checkout B_branch ``` 更改到B分支，為變基做準備。 4. **在主分支上變基B分支：** 進行變基： ```sh git rebase main ``` 開始變基過程，將B分支的修改應用在主分支上。 5. **解決衝突（如果有的話）：** 遇到衝突時，問題文件將被突出顯示。使用你的Git客戶端(建議使用IDE 的merge edit編輯) 或命令行導航到衝突文件並選擇解決衝突。這可能涉及手動編輯文件或在更改之間選擇。 6. **完成變基並推送更改：** 解決衝突後： ```sh git add . git rebase --continue git push --force-with-lease ``` 變基後需要強制推送以用新歷史更新遠程分支。 7. **發PR merge 進去main** #### 補充說明： - **在Git客戶端中解決衝突：** 在你的Git客戶端中尋找解決衝突的選項（例如，右鍵點擊突出顯示的文件並選擇“解決衝突”）。 - **在VS Code和IntelliJ中解決衝突：** - 對於Visual Studio Code（VS Code），搜索“vscode git 解決衝突”。 - 對於IntelliJ IDEA，搜索“IntelliJ git 解決衝突”。 - **更新PR：** 如果在一個開放的PR的分支上推送了額外的提交，PR將自動用新提交更新。沒有必要開一個新的PR。 - **處理本地提交：** 如果一個分支被合併然後刪除，但有本地未推送的提交，那些提交將保留在本地。為了保留更改，總是在刪除分支前推送提交。 ### 如何審查PR #### 指派人 指派人是負責處理合併請求的個體。這包括推動合併請求最終合併或確保它符合合併標準。在一些團隊或項目中，指派人可能是負責實施代碼更改的開發者或負責該功能或修復的項目經理。指派人必須監控合併請求的進展，解決任何出現的合併衝突，並根據審查者的反饋進行必要的修改。 #### 審查者 審查者是被請求審查合併請求中更改的人或團隊成員。他們的角色是提供反饋、建議改進，並確認代碼更改符合項目的質量標準。審查者負責仔細檢查代碼修改，以確保新代碼不會引入錯誤，並與項目的整體架構和編碼標準保持一致。一個合併請求中可以涉及多個審查者，這有助於從不同的角度評估代碼更改，從而提高代碼質量。 在 GitLab 上的合併請求過程中，明智地使用指派人和審查者角色可以加快代碼審查過程，提高代碼質量，並促進團隊間的合作與溝通。這樣的機制確保代碼在合併前經過徹底審查，有助於項目的健康和穩定。 **審查者的角色：** 審查者專注於代碼，確保它符合項目的標準。解決任何衝突的責任在於開啟PR的個人。 **審查PR的做法：** 審查他人的PR的常見做法包括本地獲取他們的分支，以確保測試通過並且沒有編譯錯誤，然後徹底審查更改。 #### 審查PR的步驟 1. **打開終端或命令提示符。** 2. **使用 `cd` 命令導航到你的倉庫位置。** 例如： ```sh cd path/to/your/repo ``` 3. **檢查可用分支。** 在切換到特定分支之前，你可能想要查看所有可用的分支，包括那些來自遠端（他人的分支）。使用以下命令列出遠端分支： ```sh git fetch --all git branch -a ``` 這將顯示所有本地和遠端分支，遠端分支通常顯示為 `remotes/origin/branch-name`。 4. **切換到指定的分支。** 如果分支已經存在於你的本地副本中，你可以直接切換到它。如果它是一個遠端分支，你首先需要本地檢出它。使用命令： ```sh git checkout branch-name ``` 如果分支在本地不存在，Git 將自動從遠端倉庫檢出該分支。如果這是你第一次本地檢出遠端分支，你可能需要使用： ```sh git checkout -b branch-name origin/branch-name ``` 此命令創建一個新的本地分支，並將其設置為跟踪對應的遠端分支。 5. **現在你可以開始審查代碼。** 在這個分支上，你可以檢查更改，運行代碼，並執行任何必要的檢查或測試。 6. **審查後的操作。** 一旦你完成了代碼審查，你可以在 GitHub 上的 Pull Request 頁面留下評論、批准或請求更多更改。 當你完成審查並希望切換回主分支時，使用 `git checkout main`（或者如果你的主分支命名為 'master'，則使用 `git checkout master`）來切換回去。 這些步驟應該幫助你切換到需要審查的 Pull Request 對應的分支。 ### 意外在別人的分支上進行了修改 如果您在Git中直接在別人的分支上進行了修改，而忘記了先創建並切換到一個新的分支，您可以透過以下步驟來保存您的更改到一個新的分支，同時確保這些更改不會影響到當前分支： 1. **儲存當前更改**: 使用 `git stash` 暫存您的更改，這樣可以保證當前分支回到修改前的狀態。 ```bash git stash ``` 2. **創建並切換到新分支**: 使用 `git checkout` 命令創建並切換到一個新的分支。您可以使用 `-b` 選項來同時完成創建和切換操作。 ```bash git checkout -b <new-branch-name> ``` 3. **應用暫存的更改**: 使用 `git stash pop` 將之前暫存的更改應用到新的分支上。 ```bash git stash pop ``` 4. **查看並提交更改**: 現在您可以查看更改 (`git status`)，並將它們提交到新的分支上。 ```bash git add . git commit -m "描述您的更改" ``` 這樣，您的更改就被保存到了一個新的分支上，而不會影響到原來的分支。這個過程允許您在錯誤地修改了一個不應該更改的分支後，安全地將更改移動到一個新的分支上。