gitGit相关文章今日看点

Git开发流程整理

2016-09-24  本文已影响859人  UEUEO

Git分支管理

分支开发流程

  1. 首先将代码下载到本地,如果本地已经有代码则直接进入下一步:

    git clone https://github.com/lijinzhe/gittest.git
    
  2. 查看所有分支,这时最少会看到3个分支,一个本地分支master分支,和两个远程分支origin/masterorigin/develop分支:

    git granch -a
    

    显示结果如下:

    * master
      ...
      //更多本地分支
      
      remotes/origin/HEAD -> origin/master
      remotes/origin/master
      remotes/origin/develop
      ...
      //更多远程分支
    
  3. 确认是否有本地develop分支,如果没有则从远程orgin/develop分支检出到本地develop分支:

    git checkout --track origin/develop
    

    然后查看所有分支:

    git granch -a
    

    显示结果如下:

    * develop
      master
      ...
      //更多本地分支
      
      remotes/origin/HEAD -> origin/master
      remotes/origin/master
      remotes/origin/develop
      ...
      //更多远程分支
    
  4. 现在开发新功能,先创建新的远程特性分支,比如开发登录功能,则创建远程特性分支origin/feature-login分支,步骤如下:

    git checkout develop //切换本地分支到develop分支
    git pull //拉取远程Git仓库中的最新的develop分支的代码
    git checkout -b feature-login //创建本地特性分支
    git push -u origin feature-login //推送本地特性分支到远程Git仓库(即创建远程特性分支),-u为追踪远程分支
    

    如果远程代码管理平台支持直接在平台上创建分支,则可以直接在平台上创建远程分支。

    • 最好以功能为单位创建特性分支,而不是以版本号
    • 相对独立相互没有关联的功能最好创建不同的特性分支
    • 因为同一个版本的几个功能在开发过程中可能会因为需求变更而导致只发布部分功能,这时如果所有功能都在相同分支上,则很难将不同功能的代码分离出来
    • 特性分支命名为:feature-{name},BUG修复的分支则为:hotfix-{name},发布分支为:release-{name},这样其他人看到这个分支就知道这个分支是什么作用
  5. 如果远程Git仓库中已经存在了feature-login特性分支,则直接checkout即可:

    git checkout -b feature-login origin/feature-login
    
  6. 现在你就可以在本地feature-login分支上开发了,此时所有的提交都是提交在你的本地feature-login分支上:

    git commit -m "提交说明"
    
  7. 当你在本地开发工作告一段落,需要把本地代码推送(Push)到远程分支上,而推送之前必须先更新远程分支的修改,因为在你开发过程中可能有其他人有修改推送到了远程feature-login分支上:

    git pull --rebase  //拉取远程分支代码,--rebase最好加上
    

    执行完上面命令后,如果不存在代码冲突,则直接把本地修改推送到远程仓库:

    git push //推送到远程分支
    

    如果有冲突则在本地merge代码解决冲突,然后再推送到远程仓库:

    git commit -m "merge说明"  //将merge的代码先提交到本地分支
    git push //然后推送到远程分支
    
  8. 到现在,你的所有代码已经提交到远程仓库上,现在需要对新功能进行测试,在测试之前需要先把代码合并到远程origin/develop分支上:

    注意:当前版本不上线的功能不要合并到远程origin/develop分支上。

    //以下两步的作用是保证你本地的feature-login分支的代码为最新,因为有可能你是和别人合作开发的该功能,如果你刚更新过或者你是一个人在开发则可以省略此操作
    git checkout feature-login //切换到本地feature-login分支
    git pull --rebase  //拉取最新代码
    
    git checkout develop //切换到本地develop分支
    git pull --rebase //拉取最新的远程origin/develop分支代码,因为可能已经有人提交了代码
    git merge --no-ff feature-login //从本地feature-login分支合并代码,--no-ff为禁止fast-farward模式
    git push //推送到远程分支
    
    //代码已经合并完,可以删除本地特性分支和远程特性分支
    git branch -d feature-login //删除本地feature-login特性分支
    git branch -r -d origin/feature-login //删除远程origin/feature-login特性分支
    
    • 以上操作,如果没有代码冲突则直接Push代码,有冲突就merge代码后再Push,具体操作可以参考步骤7。

    • 除了直接在develop分支上进行代码的merge和提交,还可以采取Pull Request的方式来合并其他特性分支的代码。

    • 删除远程特性分支时一定要跟与你一起开发当前功能并且往同一个远程分支Push代码的同学确认他的代码是否已经全部提交和合并,否则不要随便删除远程特性分支。

  9. 现在,你的代码已经合并到远程origin/develop分支上了,并且与其他人的代码进行了merge。

  10. 此时就可以基于远程origin/develop分支进行打包或者部署进行测试了,当然这个阶段的测试只能算是版本开发中的迭代测试,因为只有你开发的功能,而当前版本的其他特性功能还没有合并到远程origin/develop分支上,此时等待其他人把各自功能合并到远程origin/develop分支,然后再进行所有功能的集成测试。

    其他预研功能或者下一个版本的功能的代码都不要合并到origin/develop分支上,只在各自的特性分支上开发即可。

  11. 如果你代码已经提交到远程origin/develop分支上,但是发现提交的代码有问题需要修改,则按照第4步的方法, 重新创建特性分支,比如登录功能有问题需要修改,则重新创建origin/feature-login分支,重复第4步-第8步的操作。

    当然,也有可能你在第8步时没有删除远程origin/feature-login分支,所以远程特性分子仍然存在,那是否可以直接在这个分支上开发呢?

    推荐最好不要,而是重新从远程origin/develop分支上拉取新的特性分支,因为远程origin/develop分支上的代码是merge完之后的最新代码,而之前的远程origin/feature-login分支的代码并没有与其他的特性分支进行合并,所以有可能你继续在之前的远程origin/feature-login分支开发,然后合并到远程origin/develop分支时需要再次merge,而每次代码merge都是有风险的。

    当然,如果你能确认当前没有其他人的特性分支合并到远程origin/develop分支上,则可以直接在之前的远程origin/feature-login分支上修改问题。

  12. 如果其他人也都完成了新版本的开发工作,而且合并到了远程origin/develop分支上,就可以进行集成测试了。这时候从origin/develop分支中拉出一个发布分支origin/release-1.2.0,然后基于origin/release-1.2.0分支进行打包或者部署、集成测试,方法与第4步相同:

    git checkout develop //切换本地分支到develop分支
    git pull //拉取远程Git仓库中的最新的develop分支的代码
    git checkout -b release-1.2.0 //创建本地发布分支
    git push -u origin release-1.2.0 //推送本地发布分支到远程Git仓库
    
  13. 创建完origin/release-1.2.0分支之后,下一版本的特性就可以随时合并到origin/develop分支上了,因为当前版本的代码已经都在origin/release-1.2.0分支上,在1.2.0版本正式发布上线之前发现的所有BUG和功能修改都在origin/release-1.2.0分支上进行,直到达到发布状态正式发布。

  14. 1.2.0版本正式发布时,需要把origin/release-1.2.0分支分别merge到origin/developorigin/master分支上,方法与步骤8相同,大概步骤如下:

    //合并到远程origin/develop分支上
    git checkout develop
    git pull -rebase
    git merge --no-ff release-1.2.0
    git push
    
    //合并到远程origin/master分支上
    git checkout master
    git pull -rebase
    git merge --no-ff release-1.2.0
    git push
    git tag -a 1.2.0 -m '版本说明'
    
    //代码已经合并完,可以删除本地发布分支和远程发布分支
    git branch -d release-1.2.0 //删除本地分支
    git branch -r -d origin/release-1.2.0 //删除远程分支
    

    有可能远程的develop和master不允许直接merge,这时可以创建Pull Request进行代码合并。

  15. 新版本正式发布之后,如果发现了严重BUG需要紧急修复时,则从origin/master分支中拉出一个本地hotfix分支hotfix-issue30,issue30表示你当前修复的问题ID:

    git checkout master
    git pull -rebase
    git checkout -b hotfix-issue30
    

    修改完BUG之后,必须将当前hotfix分支merge到origin/developorigin/master分支上,并打新的tag:

//合并到远程origin/develop分支上
git checkout develop
git pull -rebase
git merge --no-ff hotfix-issue30
git push

//合并到远程origin/master分支上
git checkout master
git pull -rebase
git merge --no-ff hotfix-issue30
git push
git tag -a 1.2.1-hotfix-issue30 -m '版本修复说明'

//代码已经合并完,可以删除本地分支
git branch -d hotfix-issue30 //删除本地分支    
    
    * 一般hotfix分支可以不用创建远程分支,因为某一个BUG一般都是你自己在修改,不存在多人协作,所以只在本地创建hotfix分支即可。当然如果这个问题真是多人一起修改,那就需要创建远程hotfix分支了。
    
    * 如果有几个BUG之间有关联,则可以创建一个hotfix分支进行修改,但是如果两个BUG之间没有任何关系,则最好拉取各自的hotfix分支进行开发。
    
    * 也可以直接以版本来创建hotfix分支,比如`hotfix-1.2.1`,则表示修复1.2.0版本的BUG,这个时候可能就需要创建远程分支`origin/hotfix-1.2.1`了,因为其他人也要参与这个版本的BUG修复工作。

16. 到此一个开发周期完成,重新回到develop分支开始下一个版本的开发。

UEUEO
上一篇 下一篇

猜你喜欢

热点阅读