Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

VSTS-Git with Visual Studio 入門教學

3,103 views

Published on

使用 Visual Studio Team Service 的 Git 範本進行專案版本管理,以及如何使用 Visual Studio 2015 連接 VSTS 並進行 Git 版本控管、分支、分支策略等。

Published in: Software
  • Dating for everyone is here: ❶❶❶ http://bit.ly/2F4cEJi ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❶❶❶ http://bit.ly/2F4cEJi ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

VSTS-Git with Visual Studio 入門教學

  1. 1. VSTS – GIT WITH VISUAL STUDIO WORKSHOP 陳傳興, BRUCE CHEN HTTPS://KKBRUCE.TW HTTP://BLOG.KKBRUCE.NET
  2. 2. VISUAL STUDIO TEAM SERVICES • https://www.visualstudio.com/products/visual-studio-team-services-vs • 個人均可免費申請使用。 • 5 人以下團隊免費使用。
  3. 3. GIT AND GITHUB • Git 是分散式 Version Control 軟體 • Github 以 git 為基礎擴充的伺服器服務, 使專案更便於協作與發佈 • VSTS 支援 Git 版控
  4. 4. GIT 2.7.4 • Git for Windows 2.7.4 之前含一個重大漏洞 ( http://mvc.tw/004N ),請更新至最新版。 • Download: https://git-scm.com/
  5. 5. VSTS – GIT
  6. 6. TEAM EXPLORER – SELECT GIT PROJECT
  7. 7. TEAM EXPORER - CLONE
  8. 8. NEW PROEJCT
  9. 9. CHANGES • 第一次,請先確認 Configure 裡的個人資料
  10. 10. CONFIGURE • Developer 個人資料
  11. 11. GITHUB FLOW • 適合中、小型團隊使用。 • https://guides.github.com/introduction/flow/
  12. 12. STEP 1. CREATE A BRANCH • master 代表隨時可上戰場的版本 • master 僅進行分支與合併 • 開發應該在其他 Branch 上進行 • 取個好名子 • fix-bugid-9527 • cool-feature-async • users/kkbruce/test-img-resize (建議用”/”) • 分支命名規範:http://mvc.tw/004M
  13. 13. STEP 2. COMMIT CHANGES • Commit 到你的 branch。 • 每次的 commit 都代表往前一小步(一個節點)。 • 為了 bug 或 feature,通常會進行多個 commit。
  14. 14. STEP 2.1 IGNORE • Settings  Git  Repository Settings • /.gitIgnore:排除的檔案 • /.gitattributes:針對特定路徑的設定值被稱為 Git 屬性(attributes) • https://www.gitignore.io/
  15. 15. 唯一的指令 • 已提交至 Repository 的檔案,事後再設 定 .gitignore 是沒有用的。 • 可透過指令明確跟 Git 說此檔案不需要版本控 管了。 • git rm --cached 檔案名稱
  16. 16. STEP 3. PUSH YOUR BRANCH • Push 你的 branch 到遠端儲存庫。
  17. 17. STEP 4. CREATE A PULL REQUEST • 通知某(些)人進行 Code Review,以提供更多 feedback。 • 換個說法,分支進行合併前進行最後的討論。 • 也許會進行更多的 commit 與 push。 • 由分支負責人進行同意合併動作。
  18. 18. STEP 5. COMPLETE PULL REQUEST • 解決任何的衝突,以完成分支合併。
  19. 19. CHANGES(變更) • 確認 commit 的 Branch 是否正確
  20. 20. 關聯 WORKITEM (重要)
  21. 21. VSTS定義查詢 • Query在VSTS去定義 • My Queries 僅自己使用的查詢 • Sheard Queries 是共享的查詢
  22. 22. QUERIES SAMPLE Assigned to All Task
  23. 23. ACTIONS(動作)
  24. 24. SYNC(同步) • Commit 是簽入至本機儲存庫。 • Sync 才會同步至遠端儲存庫。 • 可 Commit 多個本機的版本後再執行 Sync。
  25. 25. HOME – SYNC(同步)
  26. 26. VSTS – CODE / EXPLORER
  27. 27. COMMIT 連續技 • Commit • Commt and Push • Commit and Sync
  28. 28. SYNC – PUSH AND PULL push • 將本機變更推送到遠端 pull • 將遠端變更提取到本機
  29. 29. BRANCHES
  30. 30. NEW BRANCH
  31. 31. PUBLISH BRANCH
  32. 32. LOCAL BRANCH • 建立後第一次需要 Publish Branch 至 Server • 後續就是不斷 commit 與 push。
  33. 33. PULL REQUESTS • Pull Request 字面為「提取要求」,代表子分 支請求父分支擁有者給提取回去的要求。 • Pull Requests 是一個通用的工作流程,即是對 branch 進行 Code Review 與合併。 • 換句話說,目前 branch 已開發、測試至可整 合的程度,希望專案擁有者進行審查與合併 的動作。
  34. 34. NEW PULL REQUEST • Pull 已完成的 commit 至遠端。 • 建立 Pull Requests • 審查與完成審查需連線到 VSTS (online) 完成。
  35. 35. TITLE & DESCRIPTION • Title 簡明說明此次 pull request 的更改 • Description 簡明說明此更改如何實作以及其 他有助理解此更改的資源。 • 還可指定 Reviewers 與 Work Items
  36. 36. DISCUSSION
  37. 37. FILES
  38. 38. COMMITS
  39. 39. COMPLETE PULL REQUEST • 遠端同意後,記的本機切換回 master 分支(本 範例) Sync 一下。
  40. 40. MASTER - HISTORY
  41. 41. PULLING Fetch 下載所做的更改,但不套用在你的程式碼 Merge 套用取自 Fetch 到你本地儲存庫的分支 Pull 這是一次執行 Fetch 與 Merge 的簡單作法。
  42. 42. MERGE • Team Explorer 會在你執行 pull 或 sync 動作時 會進行 merge。 • Sync 是 pull 與 push 的組合操作,它是同步本 地與遠端的分支的 commit 資料。
  43. 43. MERGE CONFLICTS • 同一支檔案被多人異動。 • Git 無法解決,則產生合併衝突。
  44. 44. MERGE CONFLICTS • 以本機儲存庫為主 • 以遠端儲存庫為主
  45. 45. GIT BRANCHING MODEL • 2010年時,有位 Vincent Driessen 整理出了一套 Git branching model
  46. 46. 主要(MASTER)分支 • master:處於production-ready的狀態,只從 release 與 hotfix merge 回來,不直接在上面 commit 變更。換句 話說,即是該版的source code是可運行的、符合專案 需求的、設計良好的、穩定的、可維護的、可擴展的 及已文件化的。 • develop:也稱開發分支為整合分支,自動化測試所根 據的程式碼(source code)即是以此分支上的版本為基準 來進行測試。
  47. 47. 支援分支 • Feature branches:從 develop 分支出來,當功能開發修 改完成後 merge 回 develop • Release branches:從 develop 分支出來,是準備釋出的 版本,只修改版本號與 bug,完成後 merge 回 develop 與 master,並在 master 標上版本號的 tag • Hotfix branches:從 master 分支出來,主要是處理已釋 出版本需要立即修改的錯誤,完成後 merge 回 develop 與 master,並在 master 標上版本號的 tag • 支援分支與主要分支最大的差別在於,支援分支在支援 任務結束後就會移除,而主要分支則是始終存在。
  48. 48. 功能(FEATURE)分支 • 從develop branch分離。 • 合併回develop branch。 • 分支命名規則:除了master, develop, release-, or hotfix- 以外的功能名稱都行。 • 此分支通常只會存在於該功能的開發者的本機端的儲存 庫(local repository),遠端的中央儲存庫(remote repository 或者 remote origin)是不會有的。
  49. 49. 發佈(RELEASE)分支 • 從開發分支分離。 • 合併回開發分支或主要分支。 • 分支命名規則:release-*
  50. 50. 發佈分支 • Release branch分支是為了新版本發佈而存在 • 合適進行整合性測試,並進行小bug修復及增加一些metadata(例如版本號或是build日期等)。 • 制定版本號碼的最佳時機是在開發佈分支時。
  51. 51. 修補(HOTFIX)分支 • 通常是因為出現了一個急需在短時間內修復的bug(急 件) ,無法等到下一次發佈時才修復。 • 此分支通常從主分支某個已標上tag的commit分出,bug 經過修復後,可合併到開發分支,或者是合併回主分支, 並標上另一版本號的tag。 • 開此分支的目的在於開發分支上的成員可以繼續原本的 工作,而bug修復工作也同時由另外的成員來執行,使 得對彼此間的影響降到最低。 • 特別注意的是,若修補程式分支與發佈分支同時存在, 則當bug修補已完畢時,就不是合併回開發分支,而是 發佈分支。
  52. 52. GITFLOW FOR VISUAL STUDIO 2015 • http://mvc.tw/004O
  53. 53. VISUAL STUDIO 2015 UPDATE 2
  54. 54. 結論 • Git 是一套成功的分散式版本控管。 • VSTS 提供一個強大的 DevOps 平台,Version Control 與 Git 可以無縫整合。 • Team Explorer 去除煩雜的指令,提供簡易介面與操作。 • Git + VSTS + Visual Studio 提供高生產力的開發作業流程。 • 進一步的 Git 需求,那麼請花點時間瞭解 Git 指令。
  55. 55. 參考資料 • https://git-scm.com/book/zh-tw/v1 • https://msdn.microsoft.com/en-us/library/vs/alm/code/git/overview • https://www.visualstudio.com/en-us/get-started/code/gitquickstart • https://guides.github.com/introduction/flow/ • http://nvie.com/posts/a-successful-git-branching-model/ • http://git-tutorial.readthedocs.org/zh/latest/branchingmodel.html • http://www.ruanyifeng.com/blog/2012/07/git.html • http://huan-lin.blogspot.com/2012/04/git-ignore-file.html • Book:http://books.gotop.com.tw/v_ACA021200

×