功能驱动
git 主要有三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，完成开发后，该分支就合并到主分支，然后被删除。
Git flow
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
它最主要的特点有两个
1.项目存在两个长期分支
master 主分支
develop 开发分支
//前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版，最不活跃的；后者用于日常开发，存放最新的开发版。
2.存在三种短期分支
功能分支（feature branch）
补丁分支（hotfix branch）
预发分支（release branch）
// 缺点： 部门开发中通常要不就一条master走到底，要不就是master+develop，其实基本满足需要了。多了徒增复杂度，维护起来很麻烦
Github flow （推荐）
Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
它只有一个长期分支，就是master，因此用起来非常简单。
Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。
假设有1个github 地址 https://github.com/976500133/FETopic.git
1.克隆仓库 Repository 地址
git clone https://github.com/976500133/FETopic.git
2.首先切换到devlop分支 (devlop 也可以叫其他的， 比如deploy 等)
git checkout -b devlop ( 及其重要：一定要确保 devlop是 基于 master 新建的， 也就是在master 的分支上运行 )
3.分出一个功能性分支
git checkout -b feature-user-profile
4.如果进行了一顿猛如虎的代码修改
5.测试没问题，提交更改
git add . // feature-user-profile
git commit -m "add user-profile feature "
6.拉取最新代码（非必要）
git pull (非必要，在push 不上去的时候 需要执行)
7.推送分支到远程
git push origin feature-user-profile
或者
git push --set-upstream origin feature-user-profile //(只设置一次就行)
git push //以后可以直接push
8.假设是master 为主分支,通知主分支合并feature-user-profile,
git rebase origin/master
//如果出现冲突 conflict , 解决完之后 执行
git add .
git rebase --continue //多次冲突的话需要多次执行命令
//如果放弃的话， 使用如下命令
git rebase --abort
9.把rebase 过的代码推送到远程
git push -f origin feature-user-profile
10.直接master 合并 feature-user-profile 就是直线了~！！赞
git checkout master
git pull
git merge origin/feature-user-profile
Merge节点
Git merge 有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none fast-forword），会生成单独节点。
前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用--no-ff参数）。只要发生合并，就要有一个单独的合并节点。
部分非完全精准的总结
git merge | 直接合并某个分支或节点。用于2个不同分支直接的代码合并
git cherry-pick 摘取合并某次提交的信息 , 比如我某次提交就叫了一句注释，就会合并进来这句注释
git rebase 时间基线会修改，修改时间线,让线看起来笔直的