git分支管理和工做流规范：基本概念说明

「单点登陆与权限管理」系列第二部分，Demo项目的设计和开发，须要一段时间才能完成。这段时间，会把之前学习、实践、梳理过的知识分享给你们，但愿你们可以喜欢。

「单点登陆与权限管理」系列第一部分索引：

1. session和cookie介绍
2. HTTP重定向
3. 单点登陆介绍
4. cookie安全问题
5. 权限管理介绍

接下来，会分享「git分支管理和工做流规范」相关内容，当一个项目大了后，会有多人共同协做开发，若是没有相关规范，代码合并的时候会有不少冲突，代码的版本和提交历史也会显得很乱。针对这2个问题，能够经过分支的管理、工做流规范很好的解决。

针对不一样的场景建立不一样的分支，始终保持主分支可靠、干净，好比新增功能、修复线上问题、修复测试环境的bug等场景，须要建立不一样的分支。另外，要对下一版本要上线的功能提早规划好，把功能细分，分配给每一个人去完成，功能相互依赖的在同一个分支，不肯定要上线的功能要单首创建分支，这样能够减小合并时的冲突。

提交代码时，要保持提交历史的清晰，提交的注释也要规范，关于提交历史，总结了3个要点：

• 一个git用户很是重要的技能是可以维护一个清晰的语义化的变动历史;
• 经过查看版本变动历史就能够反映出团队的开发目的、功能变动；
• 版本变动历史记录的是代码的发展，而不是开发者在编码时的活动；

会分3篇文章分享「git分支管理和工做流规范」：

• git相关概念
• 具体规范
• 不一样场景细化和演示

本篇主要介绍下git相关概念，太基础的我就不介绍了，网上资料比较多，主要包括：

• 文件的状态
• 分支的概念
• merge合并
• rebase衍合
• git工做流程

文件的状态

状态类型

• 已修改：修改了某个文件，但尚未提交保存;(没有add)
• 已暂存：已修改的文件放在下次提交时要保存的清单中;（已add，没有commit）
• 已提交：文件已经被安全地保存在本地数据库中;（已commit）

工做目录、暂存目录、git目录

3个目录与文件的状态是对应的，不一样的状态放在不一样的目录。

git对象

• 对象包括提交、文件树、文件内容、其余操做对象;
• 用40位十六进制数字组成;
• 可经过git cat-file 命令查看对象信息;

基本工做流程

• 在工做目录中修改某些文件;
• 对修改后的文件进行快照，而后保存到暂存区;
• 提交更新，将保存在暂存区域的文件快照永久转储到git目录中;

状态相关命令

• git status 显示哪些文件已修改、哪些文件已暂存、未提交;
• git diff 比较不一样状态的文件
  • 默认比较工做目录、暂存区文件快照的差别;（修改后，未暂存的文件）
  • --cached 比较已暂存、上次提交时的快照之间的差别;
• git reset 进行撤销操做，将当前分支重设到指定的commit
  • --hard 重设工做目录和暂存区；
  • --mixed 默认方式，仅重设暂存区，工做目录不变；
  • –soft 仅仅把HEAD指向，commit以后的commit会进入暂存区；

分支的概念

本质上，分支仅仅是指向commit对象的可变指针。

git如何知道你当前在哪一个分支上工做？

• 保存着一个名为HEAD的特保指针；
• HEAD是一个指向你正在工做中的本地分支的指针；

经过git branch -a 查看分支时，会看到全部分支，包括本地分支、远程分支；

分支的合并主要有2种方式，merge和rebase。merge主要是自动合并，针对不一样场景有不一样的合并策略，rebase主要是手动合并，可针对每次commit指定不一样的合并策略，下面会分别介绍。

merge合并

• --commit --no-commit 合并后，是否自动产生一个合并结果的commit节点;
• --edit --no-edit 是否接受自动合并的信息;
• --ff --no-ff选项
  • 默认状况下，git执行“快进式合并”(fast-farward merge)，不会创造一个新的commit节点;
  • --no-ff，会建立一个新的commit;
• --log --no-log
  • 合并提交时，除了分支名之外，是否还包括commit节点的日志信息
• --squash
  • 不保留待合并分支上的历史信息，也不提交、不移动HEAD，须要一个额外的commit命令;
  • 判断是否使用--squash选项的最根本的标准是，待合并分支上的历史是否有意义;
• -- abort
  • 抛弃当前合并冲突的处理过程并尝试重建合并前的状态;

rebase衍合

$ git rebase -i [branch|]

三个操做命令：--continue、--absort 和 --skip，这三个命令的意思分别是“继续”、“退出”和“跳过”

必定要注意的地方：

• 一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操做;
  • 在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些相似但不一样的新的提交对象;
  • 若是你把原来分支中的提交对象发布出去，而且其余人更新下载后在其基础上开展工做，而稍后你又用git rebase 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合做者就不得不从新合并他们的工做，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟;
• 把衍合当成一种在推送以前清理提交历史的手段，并且仅仅衍合那些还没有公开的提交对象；

具体的示例，网上资料不少，就不在此说明了。

git工做流

协做必须有一个规范的工做流程，让你们有效地合做，使得项目层次分明地发展下去。

网上对这一部分的介绍也不少，介绍比较多的就是git flow规范，能够参考下面2篇文章： [1] 阮一峰：git工做流程 [2] git-flow工具

最后附上经常使用的命令速查表：