公司新人培訓 Boot Camp 分享 -- CI (git)

今年受公司大佬們的委託給本次Boot camp新兵訓練營的培訓學員(入職公司的應屆生新人)作關於 CI 的分享, 主題是 「CI: Git + Jenkins + Jira」, 往年的分享通常都是圍繞 Git 展開, 今年雖然題目上加了 Jenkins 和 Jira, 感受重點仍然是 Git, 1個小時的時間講不了太多的東西.
下面將分享的內容大體以文字的形式分享一下.
CI 概念
CI, 即 「Continuous integration」 持續集成的意思, 爲何要」持續」集成呢, 就是爲了防止時間久了集成引發多的各類問題, 所以就頻繁地, 一直持續的集成, 早出現問題早解決.
通常關於 CI 可能會有如下幾個好的實踐方案, 內容摘自 wiki
• Maintain a code repository
• Automate the build
• Make the build self-testing
• Everyone commits to the baseline every day
• Every commit (to baseline) should be built
• Keep the build fast
• Test in a clone of the production environment
• Make it easy to get the latest deliverables
• Everyone can see the results of the latest build
• Automate deployment

這裏就不一一翻譯了, 大體意思就是: 利用 git/svn 等各類版本控制工具維護一個代碼庫, 開發人員天天/次提交的代碼均可以自動編譯, 自動測試, 自動部署.
常見的 CI Server 有, 如 Jenkins, Travis 等工具.
Git
產生背景
在git出來以前, 常見的版本控制工具軟件有 SVN/CVS 等, 這種工具備不少弊端, 好比必須得聯網, 代碼庫太大了, 不太方便進行交互等. Linus 當初爲了解決 Linux 源碼的管理問題(Linux最開始是用一個商業軟件 BitKeeper 進行版本管理, 後來由於終止合做了), 因而就花了幾周搞出了最第一版本的 Git.

(集中式和分佈式版本控制系統的區別)
• 集中式: SVN等就是這種方式, 有一箇中央Server保存全部代碼, 你們都依賴於這個集中的Server, 若是集中的Server掛了, 就無法搞了.
• 分佈式: 分佈式版本控制系統根本沒有「中央服務器」，每一個人的電腦上都是一個完整的版本庫. 分佈式版本控制系統一般也有一臺充當「中央服務器」的電腦(Remote Server)，但這個服務器的做用僅僅是用來方便「交換」你們的修改，沒有它你們也同樣幹活，只是交換修改不方便而已。
基本概念
Git 中的幾個基本概念比較重要, 理解這幾個概念可以更好的掌握後面的 git 常見命令及做用.
工做區域劃分

(git工做區域劃分)
• 工做目錄/工做區(working directory): 就是當前工做的目錄, 實實在在操做的文件
• 暫存區/索引區 (staging area): 經過 git add 以後, 會把文件保存到暫存區域裏面
• 版本庫: commit 以後, 文件就存在了版本庫裏面了
文件的生命週期

(git文件生命週期)
• untracked: 尚未被版本庫所track, 與版本庫尚未產生任何關聯
• unmodified: 已經添加到版本控制裏面了, 版本庫裏面保存的文件的狀態
• modified: 與版本庫裏面的文件版本不一致了, 處於被修改後的狀態
• staged: 修改了文件, 通過add後, 就保存在暫存區(staged)裏面, 此時通過 commit, 文件就會又變成 unmodified 狀態
Commit 以後到版本庫, commit以前在staging區(add後), add前working區.
常見配置
git 配置文件通常有3個地方:
• System 系統配置, 對整個OS的全部用戶都同樣, 通常可能的配置文件位置在 /etc/gitconfig, 通常我的用的話, 可能不會配置這個. 對多人共享的 Server 可能會配.
• User 配置, 配置文件位置在 ~/.gitconfig, 好比配置一些行位換行符策略(core.autocrlf, 項目中有人採用不一樣的OS的時候要注意), push 的策略, 當前用戶等. ~/.git-credentials 這個文件存儲了受權登陸的信息, 注意此文件的保密(可能有明文存儲了用戶名密碼信息), 還能夠配置一些 命令 的 alias, 節省輸入命令時的時間.
• Project 配置, 就在當前項目的目錄下 currentProduct/.git/config , 固然優先級就是越 specific 越優先.
推薦你們都設置一下 alias, 好比我就設置了 alias gfom='git fetch origin master' , 鍵盤輸入4個字符就至關於完成的 'git fetch origin master'. 固然, 若是你是用的 zsh 的話, 能夠直接用 zsh 的 git 插件, 裏面配置了很多 alias, 例如

alias g='git'
alias ga='git add'
alias gaa='git add --all'
alias gb='git branch'
alias gba='git branch -a'
alias gbr='git branch --remote'
alias gc='git commit -v'
alias gc!='git commit -v --amend'

常見命令
在培訓中, 我主要介紹瞭如下命令的用法. 其實就是但願你們對相應的命令有一個印象, 就與以前分享過的 Shell 助力開發效率提高 同樣, 知道每一個命令的試用場景, 可以瞭解某個場景下能夠用某個命令來解決實際問題就行, 具體命令的參數, 能夠到時候再 git commond --help 一下便可, 固然最基本的參數須要掌握, 用得多了就自動熟悉了.

git init     git remote   git rebase   git submodule
git status   git push     git reset    git revert
git add      git stash    git tag      git reflog
git commit   git merge    git blame    git cherry-pick

我這裏就不列舉全部命令了, 挑幾個重點講一下. 培訓中講完整命令列表及案例能夠在這裏找到 bootcamp-git.
git checkout v.s git reset
• git checkout --fileName: 丟棄工做區對文件fileName的修改, 注意一下, 執行此命令, 對fileName的修改就沒了.
• git reset HEAD file: 將提交到暫存區的修改撤銷掉(unstage), 回到 git add前的狀態, 文件從 staging 區 到 working 區, 文件內容沒有變化(已修改未暫存狀態).
git rebase v.s git merge
• git merge: Merge takes all the changes in one branch and merges them into another branch in one commit. 一次性合併, 如有衝突解決完衝突後, 再 add, commit 會產生新的一個commit. git merge --no-ff: 保留被合併的分支的commits, 默認 fast-forward
• git rebase: Rebase says I want the point at which I branched to move to a new starting point. 交互式的, 把在一個分支裏提交的改變commits移到另外一個分支裏重放一遍。一個 commit 一個commit的進行, 當前衝突須要解決完以後, 再git rebase --continue, 直到全部commits合併完畢, 使得 commit history 美觀, 缺點是可能要屢次進行衝突解決.

(git merge和rebase的區別)
這部份內容詳細能夠參考 atlassian merging-vs-rebasing 和 cnblogs merge-vs-rebase
因此 rebase 和 merge 後的 log history 順序可能不同, 若是有衝突, rebase 可能會屢次對同一個文件進行fix. 本身單獨的開發的分支, 用 rebase 保持乾淨整潔的 commits, 可能多人開發等分支有多種衝突的(特別是已經push到remote供其餘人使用時) 用 merge.
git rebase -i 重建提交歷史
另外, 還能夠用 git rebase -i hash 從新修改提交的歷史. 能夠對commits信息進行整理從新排列, 刪除和合並等操做, 使得更佳美觀.
其實通常開發人員應該使每個commit都有意義, 而現實當中通常的開發團隊可能比較難以作到. 若是嚴格要求的話, 可能很多同窗都須要用 rebase 對歷史提交進行從新整理.

(git rebase從新整理commits歷史)
例如上面例子中, 已經提交了10個commits, 如今須要刪除其中的第6個, 而後合併其餘全部的commits爲一個commit. (作了一次git動圖進行演示, 不知道效果怎麼樣).
其餘
其餘還有下面兩個命令可能用得較多.
• git cherry-pick: 能夠跨分支得提取commit, 相似rebase -i 後的 pick, 從 branchA 的 commit hasha 提取出來, 放到 branchB 中.
• git stash: 臨時保存工做區的狀態. 經常使用於這樣的場景, 好比 當前在 featureA 中開發, 還未開發完成, 這個時候線上可能有個緊急 bug 須要修復, 須要暫存一下當前的狀態, 從 master 分支切 hotfix 分支進行開發, 因而就能夠先 git stash 將當前的修改暫存一下 (不會提交到暫存區, 另外有個相似棧的結構保存), 而後 hotfix 改完以後, 再切到 featureA 分支, 而後 git stash pop 就能夠恢復當時的狀態.
• git submodule: 項目太大, 子項目相對獨立, 父項目含有一個子項目的指針而已. 這樣更加方便管理. 舉個例子, 我本身的vim配置, 全部的插件都是一個子項目.
其餘, 可能還有用的是
• hooks: 能夠設置 hooks, 在 .git/hooks/ 目錄中, 該目錄有一些示例, 改文件名就能夠生效. 好比設置 commit 以前 跑一下 pre-commit 的hook, 該 hook 能夠跑一下好比 靜態的coding style check, 若是不經過就不讓commit.
• commit.template: git config commit.template commit-template-file.config. 能夠給團隊配置相同的模板, 這樣你們的commit 的 comments 都統一, 方便管理和track.
常見 Workflow
git flow

(git flow)
這篇文章 對 git flow 有較爲詳細的闡述.
簡單來講, 就是team裏的成員都在一個repo裏面開發, 基於不一樣的 branch 去完成.
一點建議就是, 若是team裏用的是這種workflow, merge MR/PR 的時候, 別忘了勾選刪除原分支. 否則會形成一個repo裏面太多分支且雜亂無章.
github flow

(github flow)
github flow 詳見官網 對其的闡述. 簡而言之, 就是你們在不一樣的repo進行開發, 往一個主repo裏去 merge.
CI Server
其實 CI Server 能夠直接簡單的理解爲, 存在這樣一臺機器, 當你push 代碼的時候(固然這個動做能夠相似git hooks同樣能夠配置), 會自動幫你順序執行一系列的程序命令, 而後將執行結果以某種方式通知你.
最多見的就是下面這兩種: Jenkins 和 Travis.
• Jenkins: Jenkins 是一款主流的 CI Server 吧, 優勢是開源免費, 含有豐富的插件系統. 本文就不作多的介紹了, 通常中小型公司也都會用這個吧?
• Travis CI: travis-ci, 我第一次接觸這個玩意仍是好久前發現能夠直接用它幫我編譯個人博客程序jekyll, 而後把生成好的html直接push到github, 這樣就免得我本身去build了, 每次新寫一篇blog, 直接push 到 master 便可, travis 就會默默地進行工做, 還還挺方便的, 不須要本身買VPS等Server, 就能夠動態build 程序. (不須要後臺動態語言支持, 全靜態博客(hexo/jekyll/octopress等)做者推薦使用, 關鍵免費呀)
很多開源的程序都會藉助 travis, 與 github 無縫連接, 實時標記 build狀態等.
Jira
Jira 用於項目管理, issue trakcing 等等.
相似的還有 trello 等等.
References
• Wiki Continuous_integration
• progit
• Git教程
• git docs
• Jenkins入門

點擊下面閱讀原文能夠看到文中帶的連接等信息, 歡迎關注微信公衆號.