讓讓讓讓讓讓 - 讓讓讓讓讓讓 讓 一 - 讓讓讓讓讓讓讓 - Git Calvin Huang
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
讓他來告訴你- 開發用不著打一架 -
分散式版本控制 - Git
Calvin Huang
WHY Git
• 大家都用 Git
• Github 超屌 ( 那你知道 Github 用 Rails 做的嗎 ?該寫 Rails 囉 )
• 所以我一定也要用 Git
Apple
在我們選擇一項工具之前，都必須要先來搞清楚一下 WHY, WHAT, HOW
Apple
進行軟體開發的時候總避不了的是多人協作，
WHY Git• 強大的 Branching 能力• 不用那麼害怕 conflict( 雖然說這樣，但騷年，你還是應該要怕 conflict)
• 月光寶盒
WHAT IS Git• Github （不對！ )
• 分散式版本控制系統，不用伺服器端軟體就可以運用版本控制。• 每個 commit 都會建立一份檔案的快照 (Snapshot)
• 無痛分支• Push 到 remote 前可以做很多壞事
Apple
分散式版本控制的最大特色就是我們可以在每一個開發者的開發環境建立獨立的運作環境想想看，這樣子的話我們可以在互不干擾的情況下進行開發，並且在需要的時候合併工作內容
先從 Git 上岔開來看一下有聽過 SVN （ Subversion ）嗎 ?
• 傳統集中式版本控制系統• 每一個 commit 都算一次版號增加 ( 如果將每一次小功能完成就
commit 一次版號無限增加很可怕 )
• 如果遇到 conflict ， Lock-Modify-Unlock 或是 Copy-Modify-Merge 。
• brach merge 不會紀錄任何 merge 的資訊，所以很容易造成一堆conflict
• 其實也有 revert ，但僅限於尚未 commit 前，已經送出去的想追回來還頗麻煩
Apple
如果採取Lock-Modify-Unlock的方式解決conflict，當沒有把file unlock另一個鞋作者就永遠沒辦法上傳新的版本，最慘的情況就是忘了已經lock然後SVN就卡在那裡。另一個Copy-Modify-Merge是手動合併之後，協作者再重新取得合併後的檔案。不管如何反正就是如果遇到conflict就是頭痛的開始。比較起git branching，SVN branching是一切苦痛的開始
HOW TO Git
• 基本功的 add, commit, pull, push, reset, checkout
• 重要的 branch, merge, rebase, diff……
• 還有很多其他的像是 stash, blame……
Apple
但我們今天不談這個簡單介紹完git基本用法之後再來切入gitflow最重要的用法
HOW Git WORKSSVN 這樣做
Git 全都記
Apple
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
Apple
所以Git branching比起SVN branching輕量多了隨便開不用錢
先暫時簡單介紹到這邊其實重點一直著重在兩點上面• 開 branch 不用錢• 可以完美的建立分離的工作環境 ( 啊奇怪在我的環境下可以跑啊怎麼到你那邊就不行了 )
Apple
好啦，可以完美分離工作環境不是為了有理由替bug解套是為了能夠在讓個別開發者再開發的同時產生的bug不影響/造成協作夥伴工作效率的防呆措施。
既然如此，可以怎麼做• 新功能要寫 - 開 branch ，有 Bug 要修 - 開
branch ，重構開 branch ，總之想幹嘛先開branch 就對了
branch~~ 有 code 要改救救我
Apple
雖然說都不用錢，什麼都找branch就對了，可是我們還是得搞清楚為什麼要開branch
開 branch 的好處• 確保工作分配• 避免互相影響 ( 壞的方面 )
• 專案開發進度清晰化
所以，我們就這樣開branch
Apple
總之開發前先開一個
BUT……!?
Apple
master未免也太忙，要是master是要用來deploy的branch，每一次merge不就等於要把環境重啟一次(重新包一個app)?另外要是branch命名方式不固定，用來修bug的branch有時候叫做fix有時候叫做bug有時候又從名字裡面猜不出brach用來幹麻，那這樣要怎麼管理branch
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 強制性的要求雙方共同檢視修改
Apple
討論這些commit合不合適，符合規範嗎？有沒有邏輯缺陷？
協作的精神就是討論pull request 強制性的要求雙方共同檢視修改
Apple
甚至可以對stage hunk做訊息留言不過我隨便找了一下沒看到
嗯？你說剛剛都是說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
Related Documents
