①Git工作流:在项目开发过程中,使用Git的方式。
一、集中式工作流(类似svn),用的相对较少,git很多特性并没有用到。
二、GitFlow工作流。充分利用了分支的特点,实际开发中这种模式用的最多。
我们开发很多功能,需要用到分支。我们去修复bug用分支。产品正式上线之前,预发布的时候也要用到分支。
三、Forking工作流。主要针对团队外的成员,贡献代码的流程。
②GitFlow工作流详解:
分支种类:
GitFlow工作流:
当出现bug,如果整个项目做到了高内聚,低耦合,则结构会非常清晰,bug也比较容易修复。
③分支实战说明。
可以看出分支的创建(由程序员A操作),然后审查代码去合并分支(由项目经理或者有经验的架构师或者程序员操作)全部是在本地做的,而不在远程做。轻易不要去动Master主干分支。
④分支实战操作。
从上图看出,已经切换到了hot_fix
这个大于号说明,该内容已经提交给本地库至少一次,但是在工作区又作出了更改,需要添加给(拖拽到)暂存区。
然后将修改推送到远程。
分支图上显示加号,不显示禁止符号,则表示成功。
假设TestGit02是项目经理所在的本地仓库工程。
要进行一个拉取的操作。
等待进度条完成后,可以切换分支。此时hot_fix分支还不在本地。只在远程。
选择check out as 新的本地分支
检出远程的新分支,再点Finish
等待进度条完成。
发现TestGit02也切换到了,hot_fix分支。
如果项目经理发现有代码内容需要更改,则程序员A重新更改,重新push,项目经理再重新pull。但都是在hot_fix分支上进行的。
这个过程是不断迭代进行的。
然后就是项目经理在本地合并分支。
如果要将hot_fix分支合并到master分支上面,那么就得先切换到master分支上面:
看上图发现已切换成master主干。
然后合并分支:
从下图看:选择一个要合并的分支,是选择远程的,还是本地的。我们已经拉取了,所以选择本地的hot_fix分支。
合并结果如上图。
解决冲突。
解决冲突以后将master主干推送到远程仓库。有大于号或者其他,需要先commit,然后推送。这就是常规操作。
⑤eclipse中利用git向上向下回滚各个版本。
黄色的点,和线,表示冲突发生了。
清除密码: