Embed Size (px)
Citation preview
讓他來告訴你- 開發用不著打一架 -
分散式版本控制 - Git
Calvin Huang
WHY Git
• 大家都用 Git
• Github 超屌 ( 那你知道 Github 用 Rails 做的嗎 ?該寫 Rails 囉 )
• 所以我一定也要用 Git
WHY Git• 強大的 Branching 能力• 不用那麼害怕 conflict( 雖然說這樣，但騷年，你還是應該要怕 conflict)
• 月光寶盒
WHAT IS Git• Github （不對！ )
• 分散式版本控制系統，不用伺服器端軟體就可以運用版本控制。• 每個 commit 都會建立一份檔案的快照 (Snapshot)
• 無痛分支• Push 到 remote 前可以做很多壞事
先從 Git 上岔開來看一下有聽過 SVN （ Subversion ）嗎 ?
• 傳統集中式版本控制系統• 每一個 commit 都算一次版號增加 ( 如果將每一次小功能完成就
commit 一次版號無限增加很可怕 )
• 如果遇到 conflict ， Lock-Modify-Unlock 或是 Copy-Modify-Merge 。
• brach merge 不會紀錄任何 merge 的資訊，所以很容易造成一堆conflict
• 其實也有 revert ，但僅限於尚未 commit 前，已經送出去的想追回來還頗麻煩
HOW TO Git
• 基本功的 add, commit, pull, push, reset, checkout
• 重要的 branch, merge, rebase, diff……
• 還有很多其他的像是 stash, blame……
HOW Git WORKSSVN 這樣做
Git 全都記
HOW Git WORKSGit 的 Repository 又稱作 Object Database 資料庫，共有四種 Objects 類型：• Blob 記錄檔案內容• Tree 記錄該目錄下有哪些檔案 ( 檔名、內容的 SHA1) 和
Trees• Commit 記錄 commit 訊息、 Root tree 和 Parent
commits 的 SHA1• Tag 記錄標籤
HOW Git WORKS參照 Reference
• Reference 會指向一個 Commit
• tag 不會移動，指向的 commit 都一樣• ( 帶有額外資訊的 tag 內部會用 Object 儲存 )
• branch 指向該 branch 最新的 commit
• HEAD 指向 current branch
先暫時簡單介紹到這邊其實重點一直著重在兩點上面• 開 branch 不用錢• 可以完美的建立分離的工作環境 ( 啊奇怪在我的環境下可以跑啊怎麼到你那邊就不行了 )
既然如此，可以怎麼做• 新功能要寫 - 開 branch ，有 Bug 要修 - 開
branch ，重構開 branch ，總之想幹嘛先開branch 就對了
branch~~ 有 code 要改救救我
開 branch 的好處• 確保工作分配• 避免互相影響 ( 壞的方面 )
• 專案開發進度清晰化
所以，我們就這樣開branch
BUT……!?
branch 管理又是一門大哉問
• 所以有人提出了 gitflow
gitflow - 主要分兩條▪ 主要分支
▪ master: 永遠處在 production-ready 狀態▪ develop: 最新的下次發佈開發狀態
直接 copy from - https://ihower.tw/blog/archives/5140
gitflow - 剩下的分三條支援性分支
▪ Feature branches: 開發新功能都從 develop 分支出來，完成後 merge 回 develop▪ Release branches: 準備要 release 的版本，只修 bugs 。從 develop 分支出來，完成後 merge 回 master 和 develop▪ Hotfix branches: 等不及 release 版本就必須馬上修 master 趕上線的情況。會從 master 分支出來，完成後 merge 回 master 和 develop
直接 copy from - https://ihower.tw/blog/archives/5140
聽起來很麻煩？• 其實有工具可以用 ( 不過個人覺得 release 可以等同
master ，所以 branch 還是偏好自己開 )
https://github.com/nvie/gitflow
小劇場加碼 - 怎麼整理branch
今天有一個功能要開發不過把工作內容再細分後分派給不同人員進行開發
小劇場加碼 - 怎麼整理branch
如果直接merge 回去的話似乎有點雜亂不過線圖一多就總有種好像工作效率超好做很多事情的錯覺 ?
小劇場加碼 - 怎麼整理branch
本是同一個大功能 Message所以在 Voice Message 上 rebase 到 Message
小劇場加碼 - 怎麼整理branch
再來使用 merge fast forward 的方式把兩條合併
小劇場加碼 - 怎麼整理branch
小時候媽媽有說過push 出去的 branch 不要 rebase 知不知道
我知道我知道，但還真不知道為什麼
push 出去的 branch 其實會拒絕你• 因為當 push 到 remote server ，別人 pull 了那一份，天曉得你把哪個 commit 改掉了• push —force 可以強制更動，不過協作者要 push的他那份修改會被禁止• 這時候就要 reset 到被你 rebase 的那一個 commit重新整合
協作的精神就是討論pull request 強制性的要求雙方共同檢視修改
協作的精神就是討論pull request 強制性的要求雙方共同檢視修改
嗯？你說剛剛都是說Github？不，其實同樣的東西 Gitlab 上面也有
結論： Git 讓程序猿們相處融洽誰寫的醜先拖出來斬了就不會有問題
做後端很常遇到，其實 app 也會需要拿測試版給測試人員的時候 ?
• 如果我們在開發後需要打包 / 重啟環境以便提供最新版本的程式給不存在的 QA 或是 PM 的時候，每一次都要等個好幾分鐘或是又要輸入指令重開真是有夠麻煩
同場加映只有一點點ＬＡ
持續集成工具 - CI• 自動建置• 自動化測試• code 分析• 自動部署• 自動整合資料庫• 取得系統健康度
資料參考• Git-scm - http://git-scm.com/book/en/v2/Getting-Started-Git-Basics#Snapshots,-Not-Differences• 連猴子都懂得 Git入門指南 - http://backlogtool.com/git-guide/tw/• SVN衝突 (conflict) 的介紹與解決 -
http://www.cc.ntut.edu.tw/~wkchen/game/SVN%20documents/SVNConflictOverview.pdf• svn 回復到前一版本的方法 -
http://repeat.tw/blog/post/23079738-svn-%E5%9B%9E%E5%BE%A9%E5%88%B0%E5%89%8D%E4%B8%80%E7%89%88%E6%9C%AC%E7%9A%84%E6%96%B9%E6%B3%95
• Git magic - http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_tw/• ihower Git 控制系統 - https://ihower.tw/git/• ihower - Git flow 開發流程 - https://ihower.tw/blog/archives/5140• gitflow tool - https://github.com/nvie/gitflow• gitflow cheatsheet - http://danielkummer.github.io/git-flow-cheatsheet/• A successful git work flow - http://nvie.com/posts/a-successful-git-branching-model/• rebase vs merge -
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
