Branches

了解 gitflow 各個分支（branch）所扮演的角色，就差不多能理解整個開發流程了。

master

• git 預設一開始就有的分支。
• gitflow 兩條主要分支之一（代表不管怎樣都不能將它砍掉）。
• 這條分支上的軟體是穩定版，意即跟線上在跑的那一份一模一樣。
• 只允許進行合併（merge）hotfix/* 和 release/* 這兩條分支的動作，不能直接向它提交（commit）變更紀錄。

develop

• git 預設一開始沒有的分支，理論上在一開始就要從 master 分出來。
• gitflow 兩條主要分支之一（代表它與 master 生死與共）。
• 這條分支上的軟體是未來要釋出的版本。
• 可以直接向它提交變更紀錄，但是建議只提交修正小 bug 或是替某段程式碼加上註解等比較不重要的紀錄。
• 如果是要開發新的功能，就要另開 feature/* 分支。

feature/*

• 開發新功能的分支。
• 從 develop 分出來。
• 出來跑的總是要還，新功能開發完就要合併回 develop。
• 命名慣例：feature/it-is-an-amazing-feature。

release/*

• 當軟體的新功能開發到一個階段，要釋出到穩定版前就要開這個分支。
• 從 develop 分出來。
• 在這個分支上只能提交修正 bug、寫寫文件或註解等變更紀錄。
• 當一切準備就緒，就要同時合併回 master 和 develop。

hotfix/*

• 修復穩定版軟體 bug 的分支。
• 從 master 分出來。
• 當 bug 修完，要同時合併回 master 和 develop。
• 命名慣例：hotfix/fix-a-bug。

Pull Requests

Git 的分支總是分久必合，合久必分，但是合併分支通常影響軟體的狀態甚鉅，為了確保程式碼的品質，當要合併回主要分支時，應該一律開 pull request。

What are pull requests?

Pull requests 並非 git 內建的功能，而是由儲存庫的服務平台提供。

簡單來講，開 pull requests 就是發出合併分支的請求，平台會提供介面讓其他開發者完整檢視軟體將會有哪些變更，他們可以就每一行變動的程式碼討論、提出問題，這階段就是所謂的 code review。

人人都可以開 pull requests，但是在比較嚴謹的情況下，只有該儲存庫的管理員帳戶能通過這個請求。

Repository Hosting Services

接下來要介紹存放 git 儲存庫的平台，主要有三位候選人：Bitbucket、GitHub 和 Gitlab。

我們對平台的需求主要就私人儲存庫、pull requests 和 issues 等功能，如果考慮到未來可能要有自動佈署的功能，就需要 webhooks 這種功能。

以上的功能三個候選平台都具備，所以就直接看那個成本最低。

Free Plan

於是 Github 就掰了。

以我們目前的團隊人數來講，Bitbucket 和 Gitlab 都可以用，目前也看不出哪一個比較好。

由於我上一份工作用的是 Bitbucket，再加上下一章要介紹的工具跟這個平台搭配得還不錯，故我偏向使用 Bitbucket。

Tools

但是使用輔助工具也是有好處：

• 可以直覺操作的圖形介面
• 記憶 push 時要輸入的儲存庫平台帳號密碼等
• 整合 gitflow 開發流程
• ...

SourceTree

接下來就實際操作並介紹這個軟體的特色，順便會跟 GitHub Desktop 比較。

Tips

一些小心得。

不要改變過去

避免使用 git push -f 這條指令。

開啟 git 自動修正換行字元的功能

輸入指令：

              git config --global core.autocrlf true
            

或是在 .git 所在位置新增 .gitattributes 檔：

              * text=auto
            

git pull --rebase