比如有如下一张节点树的图，这里说的节点是指：各分支上的commit。换言之，一个commit就是一个节点。
当我们commit过后工作区中的代码就最新的版本了，那么原理是什么呢？
git就像上图所示的一个链表一样，每一个节点都有一个hash值，用来唯一标识这个commit(节点)。当我们commit了一次，会移动指向当前节点的指针，(这个指针就是分支branch)，每个节点保存了commit的内容，以及上一个节点的hash值。然后工作区的显示就是commit中的改变的内容。
下面看一个项目的节点树
点击“dev”分支时，右侧的节点树会标记“dev”最近一次的commit，也就是说会标记出dev HEAD指针的位置。
图中每一条线都代表一个分支，最应该关心的则是分岔的节点，因为分岔的地方就是一个新的分支。
从图中可以看哪些信息呢？
1.所有的分支是从哪里checkout出来的
比如想看origin/feat-paas-200-xxx，先找到该分支的头指针HEAD所指向的commit。
然后，看它是否从上一个节点分出来，如果没有，一直想下找，找到分岔的节点位置。
2.合并多个commit。
当开发一个新的feature时，可能会有很多的commit，这样不利于merge request。
因为merge操作需要确认代码不会影响到被merge的分支，所以代码管理者可能会一个commit一个commit的去看，这样很不方便。根据gitflow标准，一个merge request应该只有一个commit(其实也可以有更多，但是推荐1个)。
我们需要使用git reset --soft hashcode。这个hashcode是commit的版本号，一个hashcode对应一个commit，我们需要找到分岔节点的hashcode，可以使用命令git log查看。
这个reset可以理解为跳过提交的操作。当我们使用了git reset --soft hashcode后，之前的commit将都被还原，也就是git add之前的状况。那么这样既保证代码的改动还在，而且之前的commit也被撤销了，我们可以重新git commit -m "最好用一个commit"，这样多个commit就只有一个commit了。
然后git push -uf origin develop，这是一条危险的命令，会用本地的当前分支覆盖远程仓库，所以在git push之前务必确保git reset --soft hashcode中的hashcode的值，应该写为分岔节点的hashcode。
