git工作流

1.Git flow    

        核心分支:master,dev
可能还会有:功能分支,bug修复分支,预发布分支 2.github flow:只一个长期分支,就是master
第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。 第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。 第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。 第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

参考资料:
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html
http://www.ruanyifeng.com/blog/2014/06/git_remote.html
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

git pull <远程主机名> <远程分支名>:<本地分支名>

这节介绍的Gitflow工作流借鉴自在nvieVincent Driessen

Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架。

Gitflow工作流没有用超出功能分支工作流的概念和命令,而是为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互。除了使用功能分支,在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处:Pull Requests、隔离实验性开发和更高效的协作。

工作方式

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样,开发者在本地工作并push分支到要中央仓库中。

历史分支

相对使用仅有的一个master分支,Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史,而develop分支作为功能的集成分支。这样也方便master分支上的所有提交分配一个版本号。

剩下要说明的问题围绕着这2个分支的区别展开。

功能分支

每个新功能位于一个自己的分支,这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出新分支,而是使用develop分支作为父分支。当新功能完成时,合并回develop分支。新功能提交应该从不直接与master分支交互。

注意,从各种含义和目的上来看,功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流没有在这里止步。

发布分支

一旦develop分支上有了做一次发布(或者说快到了既定的发布日)的足够功能,就从develop分支上fork一个发布分支。新建的分支用于开始发布循环,所以从这个时间点开始之后新的功能不能再加到这个分支上 —— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。另外,这些从新建发布分支以来的做的修改要合并回develop分支。

使用一个用于发布准备的专门分支,使得一个团队可以在完善当前的发布版本的同时,另一个团队可以继续开发下个版本的功能。
这也打造定义良好的开发阶段(比如,可以很轻松地说,『这周我们要做准备发布版本4.0』,并且在仓库的目录结构中可以实际看到)。

常用的分支约定:

用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*

维护分支

维护分支或说是热修复(hotfix)分支用于生成快速给产品发布版本(production releases)打补丁,这是唯一可以直接从master分支fork出来的分支。修复完成,修改应该马上合并回master分支和develop分支(当前的发布分支),master分支应该用新的版本号打好Tag

Bug修复使用专门分支,让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把维护分支想成是一个直接在master分支上处理的临时发布。

示例

下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。

创建开发分支

第一步为master分支配套一个develop分支。简单来做可以本地创建一个空的develop分支push到服务器上:

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史,而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库,建好develop分支的跟踪分支:

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

现在每个开发都有了这些历史分支的本地拷贝。

小红和小明开始开发新功能

这个示例中,小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支,而是应该基于develop分支

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上:编辑、暂存、提交:
git status
git add
git commit

小红完成功能开发

添加了提交后,小红觉得她的功能OK了。如果团队使用Pull Requests,这时候可以发起一个用于合并到develop分支。否则她可以直接合并到她本地的develop分支后push到中央仓库:

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意,功能决不应该直接合并到master分支。冲突解决方法和集中式工作流一样。

小红开始准备发布

这个时候小明正在实现他的功能,小红开始准备她的第一个项目正式发布。像功能开发一样,她用一个新的分支来做发布准备。这一步也确定了发布的版本号:

git checkout -b release-0.1 develop

这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方,像是一个专门用于改善发布的功能分支。

只要小红创建这个分支并push到中央仓库,这个发布就是功能冻结的。任何不在develop分支中的新功能都推到下个发布循环中。

小红完成发布

一旦准备好了对外发布,小红合并修改到master分支和develop分支上,删除发布分支。合并回develop分支很重要,因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。另外,如果小红的团队要求Code Review,这是一个发起Pull Request的理想时机。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支是作为功能开发(develop分支)和对外发布(master分支)间的缓冲。只要有合并到master分支,就应该打好Tag以方便跟踪。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各种勾子(hook),即仓库有事件发生时触发执行的脚本。可以配置一个勾子,在你push中央仓库的master分支时,自动构建好对外发布。

最终用户发现Bug

对外发布后,小红回去和小明一起做下个发布的新功能开发,直到有最终用户开了一个Ticket抱怨当前版本的一个Bug。为了处理Bug,小红(或小明)从master分支上拉出了一个维护分支,提交修改以解决问题,然后直接合并回master分支:
git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

就像发布分支,维护分支中新加这些重要修改需要包含到develop分支中,所以小红要执行一个合并操作。然后就可以安全地删除这个分支了:

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

下一站

到了这里,但愿你对集中式工作流功能分支工作流Gitflow工作流已经感觉很舒适了。你应该也牢固的掌握了本地仓库的潜能,push/pull模式和Git健壮的分支和合并模型。

记住,这里演示的工作流只是可能用法的例子,而不是在实际工作中使用Git不可违逆的条例。所以不要畏惧按自己需要对工作流的用法做取舍。不变的目标就是让Git为你所用。

Git工作流指南:Gitflow工作流的更多相关文章

  1. Git基本命令和GitFlow工作流

    本篇博客讲解了git的一些基本的团队协作命令,和GitFlow工作流指南 git 团队协作的一些命令 1.开分支 git branch 新分支名 例如,在master分支下,新开一个开发分支: git ...

  2. Git工作流指南:Pull Request工作流

    参考地址:http://blog.jobbole.com/76854/ Pull Requests是Bitbucket上方便开发者之间协作的功能.提供了一个用户友好的Web界面,在集成提交的变更到正式 ...

  3. GitFlow 工作流

    1.概述 GitFlow 工作流定义了一个围绕项目发布的严格分支模型.虽然比功能分支工作流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架. GitFlow 工作流没有用超出功能分支工作流的概念 ...

  4. Gitflow 工作流简介

    Gitflow工作流简介 Gitflow工作流通过为功能开发.发布准备和项目维护分配独立的分支,让发布迭代过程更流畅. Gitflow工作流定义了一个围绕项目发布的严格分支模型,它会相对复杂一点,但提 ...

  5. Git工作流指南:功能分支工作流(转)

    一旦你玩转了集中式工作流,在开发过程中可以很简单地加上功能分支,用来鼓励开发者之间协作和简化交流. 功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支,而不是在master分支上.这个隔 ...

  6. Git 工作流之 GitFlow

    GitFlow学习: 先学习这篇:点击打开链接 Gitflow工作流是经典模型,体现了工作流的经验和精髓.随着项目过程复杂化,会感受到这个工作流中深思熟虑和威力. ////////////////// ...

  7. Git工作流指南:集中式工作流

    转载:http://blog.jobbole.com/76847/ 本文由 伯乐在线 - 李鼎 翻译.未经许可,禁止转载!英文出处:atlassian.欢迎加入翻译组. 转到分布式版本控制系统看起来像 ...

  8. Gitflow工作流

    什么是Gitflow工作流 Gitflow工作流定义了一个围绕项目发布的严格分支模型.虽然比功能分支工作流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架. Gitflow工作流没有用超出功能分 ...

  9. gitflow工作流简介

    gitflow工作流是一种依赖于Git版本管理工具,按特定规范对项目开发.测试.上线流程进行管理的工作方式.它是一种为实现规范化管理的约定,它明确了各个分支的意义,使整个团队的分工协作更加和谐明晰. ...

随机推荐

  1. [LeetCode]25. Reverse Nodes in k-Group k个一组翻转链表

    Given a linked list, reverse the nodes of a linked list k at a time and return its modified list. k ...

  2. CPU调度

    概念 1.控制,协调进程对CPU的竞争,按一定的调度算法从就绪队列中选择一个进程把CPU的使用权交给被选中的进程, 如果没有就绪进程,系统会安排一个系统空闲进程或idle进程 cpu调度要解决的三个问 ...

  3. 基于CSS3的3D旋转效果

    自从有了html5和css3,好多以前只能想想的华丽效果都可以上手实现了.3D 转换(个人认为3D变换更贴切^)就是其中之一.关于3D转换,可以阅读CSS3 3D transform变换,不过如此,文 ...

  4. Lucene 初识

    因为业务需要,虽然自己不是专门写搜索的,但是需要自己拼一些搜索条件去调用搜索的接口,而之前看的JVM crash里也涉及到了Lucene,所以大概了解一下. 参考文档: http://www.itey ...

  5. Drupal theme_hook

    模板语言和主题引擎 用Drupal的行话来说,主题就是一组负责你站点外观的文件.你可以从http://drupal.org/project/Themes下载第 3方主题,或者你可以自己动手创建一个主题 ...

  6. 使用Android Studio搭建Android开发环境

    一.Android Studio简单介绍 2013年GoogleI/O大会首次发布了Android Studio IDE(Android平台集成开发环境).它基于Intellij IDEA开发环境,旨 ...

  7. 吐槽中小民营IT企业管理七宗罪

    傲慢.妒忌.暴怒.懒惰.贪婪.贪食及色欲,电影<七宗罪>中借七个典型的命案告诉我们,人性中最丑陋的七大恶行.在实际的工作中自己对企业的经营和日常管理有了一些更深刻的认识,偏偏自己又是一个很 ...

  8. 【转】dB的计算方法

    原文地址:https://www.espressif.com/zh-hans/media/blog/%E5%A2%9E%E7%9B%8A%E6%AF%94%E5%80%BC-db-%E4%BB%A5% ...

  9. 设计模式之适配器模式(Adapter)

    1. 概述 将一个类的接口转换成客户希望的另外一个接口.Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作. 2. 解决的问题 即Adapter模式使得原本由于接口不兼容而不 ...

  10. 2.LVS配置过程

    请查看我的有道云笔记: http://note.youdao.com/noteshare?id=866edb5736418d29c86d68b5198c5c1c&sub=66F88F0A24D ...