Jenkins 在掃描遠端分支的時候，若遠端分支數有上百個，光是要找到符合條件的去下一步都會花上時間。所以在核準 PR 後，要記得把該分支做刪除。當然在開發過程當中，我們也會推很多測試或是實驗用的分支到遠端，但時間久了之後也需要檢視這些分支是否還有用途，若用途不明，或是已經超過時效性的話，建議也可以跟著一併刪除。

遠端分支的數目多寡，也取決於開發者的規模，以及需求迭代速度。

控制了數目，那怎麼來設置分支的條件？以下直接使用圖片做 git flow 做說明。

Source: https://gitbook.tw/chapters/gitflow/why-need-git-flow

從這張示意圖之下，可以看見各分支的流向。目前一個帳密登入功能要實做，這個需求被定成一個 feature，所以當我要開發的時候，會在 develop 分支上建立 feature/login 的分支，做為實做功能的異動。其他團隊的開發者可能也是在 develop 分支上建立自己的分支進行實作，而當在處理完登入功能之後，我提交程式碼想請其他人做檢視，登入功能要回到 develop 分支上。

那 release 分支則是當我要交付給 QA 的時候去做發佈，而最終要上線之後，在 release 的版本合併回 master 主幹，並壓上 git Tag 做紀錄。

以上是簡單的說明 git flow 的走向，前面提到建立分支的時候，使用了 feature 的前綴字。而我們開發過程當中的分支們都需要經歷過 CI 時，在跑相關 Job 的時候，就可指定前綴字為 feature。而 master 跟 hotfix 也許是可以做為排除條件，不需要執行 CI 流程。

來整理一下，原本的觸發條件是，只要有出現新的遠端分支就執行 Job。所以 git flow 來說，feature、develop、release、hotfix 還有 master 只要有異動，就會執行該 Job。因此當指定分支加上 feature/* 關鍵字之後，當掃描遠端的分支們為 feature 開頭才視為執行 Job 的觸發條件，是不是我們的 Job 的執行的效率提高很多了。

當然開發團隊有更多自定義的前綴字，也端看開發人員的在命名上的共識。這樣也可以讓執行 Job 的運用更有彈性，也能夠有效率的運用 Jenkins 的機器的資源。