這個專案目前只有我自己一個人在開發，所以當時想像的 gitflow 很單純就像下圖。從 master 直接開一個 develop 分支，如果有需要合併的異動，就再提交 PR 進 master

不過在 Day 27 的時候重新建立一個新的 App 提交，此時，是從 master 上開出去一個 hotfix 分支來處理被拒絕上架的修正。此時現況的 develop 還有內容還沒有提交進 master，但有一個 hotfix 已經提交 PR (見橘色節點的虛線) 準備回到 master 上

之後，該 hotfix 回到 master 之後，再將 master 的內容合併進 develop。這個動作是確保， develop 的內容跟 master 是一致，免得 develop 沒有更新最新的程式碼異動，最後再提交 PR。

gitflow 有很多派別，也有因應開發複雜程度，有不同做法。這邊提供 Bitbucket 網站上比較各種 git workflow 當然他們也有一些如何操作各種方式的 git 教學，有興趣的朋友可以去他們的官網看看