# Git - 進階篇

## 使用分支（branch）

在增加新功能、修正 bug，或是想嘗試一些新做法時，都可以另外開一個分支來進行，等開發完確認沒問題之後再合併回來，就不會影響正在運行的功能。簡而言之，branch 的作用就是讓開發過程各自獨立。


### 分支的本質

在 Git 裡⾯的分⽀，其實就跟**⼀張貼紙**⼀樣，它會貼在某個 Commit 上：


當完成了一個新的 Commit，新的 Commit 會指向它的前一個 Commit，而目前的分支，會貼到剛剛完成的新的 Commit 上。也就是說分支會隨著每次 Commit 的新增一起移動：


在 Git 的分⽀並不是複製⽬錄或檔案來進⾏開發與修改，**分⽀就只是⼀個指標、⼀張貼紙，貼在某個 Commit 上⾯⽽已**。

### 查看專案分支

$ git branch
* master

### 建立分支

開發新功能之前，養成建立新分支的好習慣。

$ git branch develop
$ git branch
  develop
* master

### 切換分支

$ git checkout develop
Switched to branch 'develop'

$ git branch
* develop
  master

#### 在切換分⽀的時候發⽣了什麼事？

1. 更新暫存區以及⼯作⽬錄

Git 在切換分⽀的時候，會⽤該分⽀指向的那個 Commit 的內容來「更新」暫存區以及⼯作⽬錄。但是**在切換分⽀之前所做的修改則還是會留在⼯作⽬錄**，也就是說換切分⽀並**不會影響已經在⼯作⽬錄的那些修改**。

2. 變更 HEAD 的位置

除了更新暫存區以及⼯作⽬錄的內容外，同時 HEAD 也會指向剛剛切換過去的那個分⽀，也就是說 `.git/HEAD` 這個檔案會跟著被修改。

### 修改分支名稱

分支改名**不會影響到檔案或目錄**。

$ git branch -m <old branch-name> <new branch-name>

### 刪除分支

$ git branch feature
$ git branch
* develop
  feature
  master
$ git branch -d feature
Deleted branch feature (was babb78d).

如果要刪除的分支還沒被完全合併，Git 會有小提示：

$ git branch -d feature
error: The branch 'feature' is not fully merged.
If you are sure you want to delete it, run 'git branch -D cat'.

如果刪除了**尚未被合併完成**的分支，但事後反悔了想將檔案救回來，還是有方法可行的。


從上圖可以看到，即便刪除了分支，但在該分支上原先的 Commit 依然保存著，那是因為**分支只是一個指向某個 Commit 的指標，刪除這個指標並不會造成那些 Commit 消失**。既然 Commit 沒有消失，就意味著還是可以重新把它找回來：

$ git branch return_dev b174a5

這個指令的意思是「建立一個名為 `return_dev` 的分支，讓它指向 `b174a5a` 這個 Commit」，簡單來說就是再去拿一張新的貼紙貼回去的意思。

:::warning
**補充**

如果沒有把被刪除的分支的 SHA-1 值記下來，該怎麼復原？

可以使用 **`git reflog`** 指令去查找。當 **`HEAD`** 有移動的時候（例如：切換分支或是 reset，都會造成 **`HEAD`** 移動），Git 就會在 Reflog 裡記上一筆。
:::

### 合併分支

當在 `develop` 分支開發完新功能，要將功能上線到穩定系統，也就是把 `develop` 分支合併到主要分支 `master`，需要以下步驟：

0. 使用 `git log` 指令查詢歷史紀錄：

    $ git log --oneline
    87e0bb8 (HEAD -> develop) <create> product management feature
    a3664cb <create> product page
    6b9bf18 (master) <create> main feature
    dbbcdd9 <create> home style
    4c6862a <create> home page

1. 切回主要分支 `master`

    $ git checkout master
    Switched to branch 'master'

2. 輸入要合併的分支名稱

    $ git merge develop
    Updating 6b9bf18..87e0bb8
    Fast-forward
    product.html | 0
    product.js   | 0
    2 files changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 product.html
    create mode 100644 product.js

在 `develop` 分支新增的 `product.html` 與 `product.js` 兩個檔案，因為主要分支 `master` 現在已經合併了 `develop` 分支，所以現在在主要分支 `master` 上也有這兩個檔案了。

:::danger
**注意**

所謂的 Merge 並不是指分支與分支之間的合併，而是去 Merge 「**該分支所指向的那些 Commit**」。
:::

#### 快轉模式（Fast Forward）

快轉模式是指當主要分支 `master` 合併 `feature` 分支時，`master` 當前的節點一直和 `feature` 的根節點相同，沒有發生改變，此時就會採取「快轉模式」，其實就是把 `master` 這張貼紙撕起來，往前貼到 `feature` 分支所指的那個 Commit 而已。


#### 非快轉模式（No Fast Forward）

當主要分支 `master` 當前的節點與 `feature` 分支的根節點不同時，此時合併分支並不會觸發快轉模式，會額外產出一個 Commit。


### 另一種合併方式：rebase

rebase 這個英文單字的翻譯是「重新定義分支的**參考基準**」。Rebase 合併分支跟 Merge 合併分支最明顯的差異在於，使用 Rebase 合併分支，Git 不會特別產生一個專門用來合併的 Commit。

>　A `git rebase` copies the commits from the current branch, and puts these copied commits on top of the specified branch.


#### rebase 參考資料

[另一種合併方式（使用 rebase）](https://gitbook.tw/chapters/branch/merge-with-rebase)

### 合併時發生衝突（Merge Conflict）

Git 有能力幫忙檢查簡單的衝突，所以並不是改到同一個檔案就一定會發生衝突，但是改到**同一個檔案的同一行程式碼**就沒辦法了。Git 無法幫你選擇哪一個當作最終版本，所以當發生衝突時，只能「自己手動調整」。

假設現在有一個 `index.html` 檔案，主要分支 `master` 與 `develop` 分支都同時修改了這個檔案的同一行程式碼，如果想要把 `develop` 分支 Merge 到主要分支 `master` 上，會出現以下訊息：

$ git merge develop
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

使用 `git status` 指令查詢目錄狀態：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

>　You have unmerged paths.

你有一個未合併的路徑。意思就是**目前的合併尚未完成**。

進入 `index.html` 檔案會顯示衝突發生的位置，需要手動調整檔案內容：


Git 會把有衝突的段落標記出來：

* 上半部是 `HEAD`，也就是目前所在的主要分支 `master`
* 中間是分隔線
* 下半部是被合併的分支，也就是 `develop` 分支

修改完發生衝突的段落後，還是要把檔案重新安置到暫存區，並完成 Commit Message，才算解決 Merge Conflict。

$ git add index.html
$ git commit -m 'conflict fixed'
[master d634e31] conflict fixed


## 使用 GitHub 遠端共同協作

Git 是一個分散式版本控制工具，藉由它可以產生一個儲存庫（Repository），裡面存放著被 Git 版本控制的專案。

GitHub 是目前全球最大的 Git Server，許多 open-source 的專案都是使用 Github 進行程式碼的管理，可以把 GitHub 想成「**提供存放 / 使用 Git 專案儲存庫（Repository）的服務**」。

### 將本地端 Repository 推送到遠端

1. 在 Github 上建立一個 Repository


2. 建立好遠端 Repository 後，有兩種方式將本地端 Repository 與 GitHub 的遠端 Repository 連結：

* 如果是全新開始的專案，依照「create a new repository on the command line」指示進行
* 如果是要上傳現有專案，依照「push an existing repository from the command line」指示進行


3. 以全新開始的專案為例：

    $ cd /desktop          
    $ mkdir git-practice
    $ cd git-practice

    $ echo '# Git Practice' >> README.md
    
    $ git init
    Initialized empty Git repository in /desktop/git-practice/.git/

    $ git add README.md

    $ git commit -m 'initial commit'
    [master (root-commit) 542dc7e] initial commit
    1 file changed, 1 insertion(+)
    create mode 100644 README.md

4. 將本地端 Repository 推送到 GitHub

    $ git remote add origin https://github.com/avery210412/git-practice.git

意思是「**將本地端 Repository 新增一個名為 `origin` 的遠端 Repository**」。

* `git remote`：主要是跟遠端有關的操作
* `add`：要加入一個遠端的節點
* `origin`：是一個「代名詞」，指的是後面那串 GitHub 伺服器的位置

    $ git push -u origin master
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 229 bytes | 229.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    To https://github.com/avery210412/git-practice.git
    * [new branch]      master -> master
    Branch 'master' set up to track remote branch 'master' from 'origin'.

`git push` 指令其實做了幾件事：

* 把 `master` 這個分支的內容，推向 `origin` 指向的 GitHub 伺服器位置
* 在 `origin` 指向的伺服器上，如果 `master` 分支不存在，就建立一個叫做 `master` 的同名分支。
* 如果伺服器上原本就存在 `master` 分支，便會移動伺服器上 `master` 分支的位置，使它指到目前最新的 Commit 上。
* `-u`：設定 `upstream`，使本地端分支開始追蹤指定的遠端分支，也就是說現在開始，「**本地端的 `master` 分支，會去追蹤遠端 origin 上的 `master` 分支**」

5. 回到瀏覽器上重新整理頁面：


看到這個畫面，表示已經順利把本地端 Repository 的東西，推送到這個遠端 Repository 裡面了。

:::success
**狀況題**

如何修改已經 Push 到遠端的 Commit？

假設現在已經完成一個 Commit，並且也推送到遠端 Repository 上，如果此時專案中的檔案做了一些小修改，但是又不想在這個 Commit 以後再新增一個 Commit 記錄此次的修改，只想要修改上一次的 Commit 並且重新 Push 到遠端 Repository，可以這樣操作：

1. 使用 **`--amend`** 參數進行 Commit，來修改上一次的 Commit，此時 SHA-1 值會重新計算

2. 使用 **`git push --force-with-lease origin <branch>`**，將 Commit 推送至遠端 Repository
:::

#### `git push` 參考資料

[如何使用 git push 指令只 Push 部份的進度？](https://youtu.be/VShhhq_5sMc)

[怎麼有時候推不上去](https://gitbook.tw/chapters/github/fail-to-push)

[修改已經 Push 到遠端 Repository 的 Commit](https://tinyurl.com/y6gtw7s8)

---

### 將遠端 Repository 同步至本地端

#### Fetch

當本地端 Repository 完成推送到遠端 Repository 時，目前的分支圖如下：


假使這個專案由多人協作開發，某位開發者 Push 了新的功能，此時遠端 Repository 就會新增一個 Commit：


此時，若想要把遠端 Repository 的最新版本下載回本地端，但又擔心下載後，會與本地端的 Repository 發生合併衝突（Merge Conflict）的情形，此時可以使用 `git fetch` 指令。

當執行 Fetch 指令時，Git 會看一下遠端 Repository 的最新版本內容，再比較一下此時本地端 Repository 的內容，它會**把遠端有但是本地端沒有的內容**下載到本地端 Repository，但是**不會將這些內容合併到本地端 Repository**，因此分支圖還是會維持上面的情況：


由於 `origin/master` 這個遠端分支，是從本地端 `master` 分支推送到 GitHub 進而產生的，因此 `origin/master` 分支跟 `master` 分支**本是同根生**。如果要把 Fetch 得到的最新版本內容合併到本地端 Repository，會觸發快轉模式（Fast Forward），此時的分支圖如下：



#### Pull

> *git pull = git fetch + git merge*

Pull 指令就是將遠端 Repository 的最新版本下載回本地端，並且將遠端分支合併到本地分支，也就是將 `origin/master` 這個遠端分支**直接合併**到本地端 `master` 分支。


### 從 GitHub 伺服器上取得 Repository

如果在 GitHub 上看到某個專案很有趣，想要下載到本地端研究，使用 Clone 指令就可以把整個專案複製一份到本地端了。

$ git clone https://github.com/sparanoid/chinese-copywriting-guidelines.git
Cloning into 'chinese-copywriting-guidelines'...
remote: Enumerating objects: 907, done.
remote: Counting objects: 100% (212/212), done.
remote: Compressing objects: 100% (98/98), done.
remote: Total 907 (delta 137), reused 181 (delta 113), pack-reused 695
Receiving objects: 100% (907/907), 354.90 KiB | 2.25 MiB/s, done.
Resolving deltas: 100% (529/529), done.

Clone 指令會把整個專案的內容複製一份到本地端，也就是你的電腦裡，這裡指的「內容」不是只有檔案，而是指**整個專案的歷史紀錄、分支、標籤等**內容都會複製一份下來。

:::danger
**注意**

如果這個專案你是第一次看到，想要下載到你的電腦裡，請使用 **Clone** 指令；如果你已經下載過這個專案，只是想要把本地端的內容，更新成最新的線上版本內容，請使用 **Pull**（**Fetch**）指令。

**Clone 指令通常只會在第一次下載時使用，Clone 之後的更新，就是 Pull / Fetch 的事了。**
:::

## 使用 GitHub Flow 參與開源專案

Git 儲存庫並沒有**權限控管**的概念。當越多人參與同一個專案，每個人都有存取這個儲存庫的權限時，可能會遇到一些協作開發上的問題，例如：每個人都可以 Commit 到專案正式上線的分支（例如：`master`），在這種情況下，不同人彼此之間的程式碼會互相干擾。

GitHub 提供了 Fork 與 Pull Request 的機制，賦予儲存庫基本的權限控管。

### GitHub Flow


GitHub Flow 是一個基於分支（branch）的輕量化工作流程，藉由分支去管理功能的開發，以及來自社群的貢獻。

遵守 GitHub Flow 進行開發有一個規則：**`master` 分支必須保持隨時可以部屬正式環境（Production Ready）的狀態**。

### GitHub Flow 步驟

#### Fork


如果想要參與一個你沒有推送（Push）權限的專案，可以先複製（**Fork**）一份原始專案的**副本**到自己的 GitHub 帳號底下，你對這個副本有全部的權限，之後的任何修改都在這個副本中執行。

所有人都可以 Fork 專案，對 Fork 出來的副本 Push 更新內容，然後去發送 Pull Request，來把這些更新內容貢獻回原始專案裡。

> Fork 在這邊翻譯成「複製」，但並不是這個詞的原意。在技術圈來說，這個詞使用的情境是「原作者做得不夠好，其它人覺得可以做得更好，或是想加入一些個人喜好的功能，而修改出另外的版本」。

#### Branch


將副本 Clone 到本地端，第一件事情就是**建立新分支**，之後的修改和討論都會**以這個分支為基準**。

在專案建立一個分支，代表建立了一個環境來開發新功能，在分支上所做的修改，都不會影響到 `master` 分支，所以可以自由的嘗試並提交修改。

#### Commits


在對專案進行功能開發、修改之前，執行 `git remote -v` 查看 Git 的遠端設定：

$ git remote -v
origin  https://github.com/avery210412/chinese-copywriting-guidelines.git (fetch)
origin  https://github.com/avery210412/chinese-copywriting-guidelines.git (push)

建議對 Git 的遠端設定進行調整，**將 fetch 的遠端位置，改成原始專案的位置**：

$ git remote set-url origin https://github.com/sparanoid/chinese-copywriting-guidelines.git
$ git remote -v
origin  https://github.com/sparanoid/chinese-copywriting-guidelines.git (fetch)
origin  https://github.com/sparanoid/chinese-copywriting-guidelines.git (push)

$ git remote set-url --push origin https://github.com/avery210412/chinese-copywriting-guidelines.git
$ git remote -v
origin  https://github.com/sparanoid/chinese-copywriting-guidelines.git (fetch)
origin  https://github.com/avery210412/chinese-copywriting-guidelines.git (push)

這樣設定可以達到以下好處：

* 之後會從原始專案中取得最新的專案資料（fetch），保持專案的一致性
* 所有修改的資料只會推送到自己的專案中（push），不會影響到其他人

完成設定後，就可以對專案進行功能開發。

#### Pull Request


功能開發完成後，將本地端的 Repository 推送到遠端的 GitHub Repository。

此時可以在 GitHub 上建立一個 Pull Request，Pull Request 提供了一個方式法來通知專案維護者，是否考慮使用你所做得修改。

這邊特別說明一件事，每個專案可能都有自己的規範，通常會寫在專案的 `README.md` 或是 `CONTRIBUTING.md`，請務必在修改或提交前，閱讀專案的規範，維持開源專案的品質。

#### Discuss And Review


專案維護者在檢視你所貢獻的程式碼後，可以在該 PR 中進行討論，討論程式碼內容或關於修改的建議。過程中如果有需要修改的地方，可以直接在該分支中進行修改，因為 **PR 是看分支的**，所以該分支於 PR 確認合併前，都可以新增 Commit，並納入該 PR 中。

#### Deploy


正式合併到 `master` 分支之前，在這個階段可以先部署到測試環境，以進行合併前的最終測試。如果測試沒有通過或產生任何可以討論的議題，則可以取消合併，在通過一系列的測試後，才可以發佈到正式環境（Production Ready）上。

#### Merge


當所貢獻的程式碼經過一連串的檢閱、測試後，具有**原始專案合併權限的人**，就可以將你的貢獻合併到原始專案中了，你也成為原始專案的貢獻者（Contributions）之一了。

#### GitHub Flow 參考資料

[如何使用 GitHub Flow 來參與開源專案](https://blog.poychang.net/guide-to-use-github-flow/)

[讓我們來了解 GitHub Flow 吧！](https://reurl.cc/1ZYDqp)

## 總結


### Git 版本控制參考資料

[為你自己學 Git](https://gitbook.tw/)

[CS Visualized: Useful Git Commands](https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1)