Git 协同工作流

目前主流的协同工作流

1. 中心式工作流

Git是可以像SVN这样的中心工作流一样工作的 我相信很多程序员都是采用的这样的工作方式;
这个过程一般是这样子:

    1. 从服务器上做 git pull origin master把代码同步下来
    2. 改完后 git commit到本地仓库中
    3. 然后 git push origin master到远程仓库中 其他人就可以得到你的代码

如果在第3步发现 push失败,因为别人已经提交了,那么你需要先把服务器上的代码给pull下来,为了避免有merge动作,
你可以使用 git pull –rebase 。 这样就可以把服务器上的提交直接合并到你的代码中, 对此 , Git 操作是这样的 :

    1. 先把你的本地提交的代码放到一边
    2. 然后把服务器上的改动下载下来
    3. 然后在本地把你之前的改动重新一个一个的做 commit, 直到全部成功

2. 功能分支协同工作流

上面的那种方式有一个问题, 大家在一个主干上开发程序, 对于小团队你可以这么干 ,项目一大或者人较多的团队就会有很多问题 。

我们不想让所有的开发人员都在Master分支上共享他们的代码。 我们想要的协同方式是这样的 : 同时开发一个功能的开发人员可以分享各自的代码,但是不会把代码分享给开发其他功能的开发人员,直到整个功能开发完毕,才会分享给其他开发人员。

因此,引入”功能分支” , 这个协同工作流开发过程过下:

    1. 首先使用 git checkout -b new-feature 创建 "new-feature" 分支
    2. 然后共同开发这个功能的程序员就在这个分支上工作, 进行 add commit 等操作
    3. 然后通过 git push -u origin master new-feature 把分支代码 push到服务器上
    4. 其他程序员可以通过git pull --rebase来拿到最新的这个分支的代码
    5. 最后通过 Pull Requesr 的方式做完 Code Review后合并到Master分支上

3.GitFlow 协同工作流

在真实的生产过程中,前面的协同工作流还是不能满足工作的需求。主要是我们的生产的过程是比较复杂的,软件生产过程中会有格式各样的问题。
我们需要在不停的开发新的代码的同时还要维护线上的代码,于是,就有了下面的这些需求:

    1. 希望有一个分支是非常干净的,上面的是可以发布代码的,上面的改动永远是可以发布到生产环境中的,这个分支不能有中间开发过的不可以上生产线的代码的提交
    2. 希望当代码达到上线的状态时,在测试和交付的过程中,依然可以开发下一个版本的代码
    3. 最好,对于已发布的代码,也会有一些Bug-fix的改动, 不会将正在开发的代码提交到生产线上去。

为了这些这些问题 GitFlow 协同工作流就出来了, 整个代码库一共有五种分支

     1. Master 分支。 主分支  用作发布环境的,上面的每一次提交都是可以发布的。
     2. Featrue 分支。 功能分支  用于开发功能,对应的是开发环境
     3. Developer 分支  开发分支  一旦功能开发完成,就向Developer分支合并,合并完成后,删除功能分支。这个分支对应的是继承测试环境
     4. Release 分支。  Developer分支测试到达可以发布的状态时,开出一个Release分支来,然后做发布前的准备工作。之所以需要这个Release分支,是我们的开发可以继续向前,不会因为要要发布而被block住而不能提交

     一旦Release 分支上的代码达到可以上线的状态,那么需要把Release分支向Master分支和Dev分支同时合并,以保证代码的一致性,然后把Release分支删除

     5. Hotfix 分支。 用于处理生产线上的代码的Bug-fix,每个线上代码的Bug-fix都需要开一个Hotfix分支,完成后向DevMaster分支合并,然后删除Hotfix分支

这就是整个GitFlow 协同工作流的工作过程,我们需要 长期维护 Master和Dev分支 ,其中的方式还是有一定复杂度的,尤其是Release和Hotfix分支需要同时向两个分支作合并。如果没有一个好的工具来支撑的话,这会因为我们可能忘了做一些操作而导致代码的不一致

发表评论

电子邮件地址不会被公开。 必填项已用*标注