前言
开发过程中，合理、清晰的git流程，会使项目的维护变得更加简单。 如果不清楚git操作会发生什么，或者不了解git，推荐在线git练习工具：git Online
git merge 与 git rebase
概念
这两个命令旨在将更改从一个分支合并到另一个分支，但合并方式略有不同。 当你在自己dev的分支进行开发时，另一个团队在master分支提交新的commits，就会导致分叉的历史记录。
现在需要把master分支合并到自己的dev分支，可以选择用merge和rebase
merge用法
git merge Dev // Dev表示某分支，表示在当前分支合并Dev分支
git merge -m “Merge from Dev” Dev //-m可以加上merge时要添加的描述性语句，如果出现冲突，那么先解决冲突，再将文件git add，git commit，之后再merge
rebase用法
和merge的形式一样，git rebase dev，作用也一样是在当前分支合并Dev分支，如果git rebase遇到冲突，第一步是解决冲突，然后 git add，之后不需要git commit，是直接运行git rebase --continue，这样git就会继续应用剩下的补丁了，假如不想解决冲突且不再进行合并，那么可以使用git rebase --abort
merge方式
如果使用merge，就会在dev分支中产生一个merge提交，从而将两个分支的提交历史连接到一起。⬇
优点：这是一种非破坏性操作，现有的分支不会有任何的更改。
缺点：会产生一个新的额外提交，如果提交活跃，会污染dev的提交记录。
rebase方式
会把dev分支挪到master分支的顶端，通过为原始分支中的每个提交创建全新的 commits 来 重写 项目历史记录。
优点：线性的项目历史记录，在dev分支上没有任何分叉的情况下，一直追寻到项目的初始提交。
缺点：重写项目历史记录可能会对你的协作工作流程造成灾难性后果。而且，rebase 会丢失合并提交的上下文，也就无法看到上游更改是何时合并到 dev 中的。
交互式 Rebase
交互式 rebase 可以在将 commits 移动到新分支时更改这些 commits。提供了对分支提交历史的完全控制。
使用交互式 rebase，需要使用 git rebase 和 -i ：
git checkout dev
git rebase -i master
之后会打开一个文本编辑器，列出即将移动的所有提交：
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
通过更改 pick 命令或重新排序条目，可以使分支的历史记录改成你想要的任何内容。
消除这种无意义的提交使你的功能历史更容易理解。这是 git merge 根本无法做到的。
commits 条目前的 pick、fixup、squash 等命令，在 git 目录执行 git rebase -i 即可查看到，按需重排或合并提交即可。
rebase法则
不要在公共分支上使用它。
rebase 将所有 master 分支上的提交移动 dev 分支的顶端。是这只发生在 你自己 的存储库中。所有其他开发人员仍在使用原始版本的 master。由于 rebase 导致全新 commit，Git 会认为你的 master 分支历史与其他人的历史不同。
此时，同步两个 master 分支的唯一方法是将它们合并在一起，但是这样会产生额外的合并提交和两组包含相同更改的提交（原始提交和通过 rebase 更改的分支提交）。
因此，在你运行 git rebase 命令之前，还要考虑是否还有其他人在用这个分支 如果有，那么就开始考虑采用非破坏性的方式进行改变（例如，git revert 命令）。
git命令
常用命令
git add . 将所有改动放进暂存区
git commit -m "描述" 提交并附带概要信息
git pull 从远程仓库拉取代码
git push 推送代码到远程仓库（master分支）
其余命令
git log 查看日志
git log -p 查看详细历史
git log --stat 查看简要统计
git status 查看工作区状态
git branch 名称 创建分支
git checkout 名称 切换分支
git checkout -b 名称 创建并切换到新分支
git branch -d 名称 删除该分支（不能删除当前所在的分支，不能删除没有合并到master上的分支）
git branch -D 名称 删除该分支（可以删除没有合并到master上的分支）
git commit --amend 对最新的一条commit进行修正
git reset --hard HEAD^ 丢弃最新提交（未提交的内容会被擦掉）
git reset --soft HEAD^ 丢弃最新提交（未提交的内容不会被擦掉）
git revert HEAD^ 回到某个commit
git rebase 目标基础点 重新设置基础点
git merge 名称 将分支合并到head指向的分支
git push origin localbranch 将代码推送到远程仓库的指定分支
git push -d origin branchName 删除远程分支
git stash 暂存代码
git stash pop 弹出暂存代码
常见问题
pull失败
Your local changes to the following files would be overwritten by merge:
其他人修改了该文件提交到版本库中，本地也修改了该文件，致使拉去代码的时候发生冲突
解决办法——贮存更改
依次进行如下操作
git stash 将工作区恢复到上次提交的内容，同时备份本地所做的修
git pull 拉取
git stash pop 弹出自己最近保存的内容
查看对应文件 解决冲突
pull失败 2
Pulling is not possible because you have unmerged files.
修改的文件未提交
解决方法
选择文件提交
只想拉取远端代码 不想commit
直接pull：
our local changes to the following files would be overwritten by merge:
fangfa
git stash 暂存自己的打码
git pull 拉取代码
git stash pop 弹出暂存
git的提交规范
格式： AngularJS 在 github上 的提交记录
type(scope) : subject
需要下载commitizen，提交时，用git cz代替git commit。
优点：
- 符合业内标准（许多项目使用 AngularJS 的commit 规范）
- 提交过程更加规范（使用 commitizen 规范工具，风格统一）
- 能够生成风格统一的 commit log（type(scope):subject)
缺点：
- 需要安装 commitizen 工具包，使项目更大、更重了（适合大型开源项目）
- 提交过程受约束较大
- 有一定的学习成本
制定自己的提交规范
格式
type: description
type类型（commit类别）：
- feat/add : 新功能
- fix : 修复bug
- update: 更新
- docs : 文档改变
- style : 代码格式改变
- refactor : 某个已有功能重构
- perf : 性能优化
- test : 增加测试
- build : 改变了build工具 如 grunt换成了 npm
- revert : 撤销上一次的 commit
- chore : 构建过程或辅助工具的变动
description 是本次提交的简短描述。 推荐以动词开头，如： 设置、修改、增加、删减、撤销等
靠大家自觉嘛～～～
git工具
降低难度，就用可视化工具，这里推荐Sourcetree
引用：
