公司新人培训 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入门

点击下面阅读原文能够看到文中带的连接等信息, 欢迎关注微信公众号.