开篇

Git是个老生长谈的问题了，如何在工作协作中使用Git，不同团队有不同的使用方式，最简单的可能就单个master分支直接撸，把Git当成svn来使用，这样用起来简单，但是缺乏分布式的思想，而且在并行开发过程中，光建立trunk、branch、tag等等的就很繁琐了。业界通用的用法还是Git workflow工作流。

workflow工作流

标准的workflow工作流是如下图所示：

具体的使用方式可以参考以下两篇文章：

什么是GitFlow工作流？.
Git Flow工作流程.

我们在此框架上，结合团队特点，简化了流程，定的规则是：

基本分支： master、develop、feature、release、bugfix
master分支： 只向master做并入操作，当feature开发完毕，向master并入并打上标签。
develop分支: 当新feature需要开发的时候，直接从develop创建分feature分支；
feature分支： feature分支作为特定版本开发分支，提测通过后，向develop并入，同时向master合并并打上标签，切出release分支，配置上线参数，删除feature分支。
release分支： 作为打包发布的分支，同时也作为bugfix的分支，修复完就向develop和master合并；
hotfix分支 从release上fork出来，然后并入到release中，其后生命周期和release一样，视情况而定，有时直接在release分支上做bugfix就不需要用到hotfix了；

rebase onto

在说rebase onto之前，我们先来谈一谈rebase。把其他分支或者其他修改commit合并到工作分支上，一般的处理方式是merge和rebase（衍合）。
merge的两种主要用途：

用于pull （pull=fetch+merge）
用于其他的分支合并到工作分支

首先我们有两个分支feature分支和master分支，feature分支有节点E、F、G，master分支有A、B、C、D。

现在我们在当前的master分支上执行merge feature分支的操作git merge feature，这个命令将会把在master分支上二者共同的节点（B节点）之后分离的节点（即feature分支的E F G节点）重现在master分支上，直到feature分支当前的commit节点（G节点），并位于master分支的顶部。并且沿着master分支和feature分支创建一个记录合并结果的新节点，该节点带有用户描述合并变化的信息。

即下图中的H节点，G节点和D节点都是H节点的父节点。这就是我们常见的钻石链了。如下图所示：

git rebase 则不一样，它形成的是feature分支在共同节点B以后的快照（E’、F’、G’），并直接插入到master的尾部commit节点上，完成变基操作，这就是git rebase master feature的整个过程。

rebase是一个变基操作，rebase onto则是多主题变基操作。
来看看以下的情况：

我们在feature分支上开发到F节点的时候，突然发现有个bug需要修复，然后就从F节点上新建了分支bugfix，提交了H、I、J节点，修复完成后想直接讲这三个节点合并到master上。
这个时候，如果直接用rebase命令的话，那么接在master D节点后面的就会是E、F、H、I、J这五个节点的快照，但是我们只想要H、I、J的快照啊。
这时，就可以用git rebase --onto master feature bugfix了。其中feature、bugfix形成了一个前开后闭的区间，及前面feature分支上的E、F不要了，后面的bugfix分支H、I、J才需要。
最后的结果是

reset

git reset命令是Git提供的后悔药之一，它可以帮我们把内容恢复到指定的commit提交版本。
这个操作比较吓人，一般慎用。还是用revert多一点
一共有三种调用模式

比如我们得知某个提交的哈希值是df132es

git reset df132es --hard

使用HEAD作为参数

git reset HEAD^ --hard

HEAD执行当前分支, ^ 当前分支所指向提交的前一个提交，^ ^ 表示当前分支所指向提交的前一个分支的前一个分支，以此类推；^^过多自然不太方便，可以使用HEAD~2表示

将分支指向最后一次commit，下面使用分支名称(master)作为参数，将分支指reset 向前一个commit向前一个commit)作为参数，将分支指reset 向前一个commit向前一个commit

git reset master^ --hard

revert

git revert 撤销某次操作，此次操作之前和之后的 commit 和 history 都会保留，并且把这次撤销作为一次最新的提交。git revert是提交一个新的版本，将需要revert的版本的内容再反向修改回去，版本会递增，不影响之前提交的内容。
命令用法与reset类似，但是revert并不会对原有的提交记录产生影响，只会生成一个反向的commit来进行恢复，所以回滚版本的时候一般会选择这个。
具体可以参考这个：
回滚revert和reset区别

Git workflow工作流及边角知识相关推荐

Git Workflow工作流示意图
来自:http://blog.osteele.com/posts/2008/05/my-git-workflow UPDATE: git pretty 来自: http://justinhilema ...
Git三大特色之WorkFlow(工作流)
开篇 Git 三大特色,分支,暂存区,工作流,今天终于要写到 WorkFlow 了,我彷佛已经看到胜利的曙光,走起. 何谓工作流 WorkFlow 的字面意思,工作流,即工作流程.在分支篇里,有说过这 ...
企业级开发：Gitflow Workflow工作流
http://www.jianshu.com/p/104fa8b15d1e http://www.jianshu.com/p/104fa8b15d1e http://www.jianshu.com/p ...
Git workflow 选型分析
前言「A successful Git branching model」这篇文章,应该是我第一次真正开始从 workflow 的层次来思考和看待 git 的使用问题. 而实际根据文章中提到的「g ...
Git workflow
Git workflow 大神镇楼: 这人不用说,应该都认识,他基本干了两件事,一个是Linux,一个就是git.每一件事,都在IT史上创建了一个巨大的Tag. Git是什么 Git能干什么? Git ...
实用 Git Workflow
创建分支分支是 Git 的核心概念,同时 Git Workflow 也是基于分支进行操作. 当你新增功能或修复 bug 时候,新建一个分支是一个不错的选择,这将不会影响主分支 master. 所以你 ...
ABAP WORKFLOW工作流创建（一）
SAP的工作流是个很老的内容了做过几次工作流的项目,现在有时间稍微写几篇博客一.TCODE:SWDD 创建一个新的workflow 工作流的流程无非就是两种,第一:同意.第二:拒绝(或者驳回) 1 ...
git flow工作流
git flow工作流背景: 在团队开发中,因为项目的众多,每个项目也都有不同的分支,往往会造成分支的混乱.比如我最近遇到了这样的情况,因为正在开发一个较为长期的项目,正改到一半,却派出来一个紧 ...
git flow 工作流
Git flow 工作流介绍 Git Flow 工作流是一个非常成熟的方案,也是非开源项目中最常用到的工作流.它定义了一个围绕项目发布的严格分支模型,通过为代码开发.发布和维护分配独立的分支来让项目的 ...

Git workflow工作流及边角知识