前一篇介绍了 git相关的概念，我们可以查看文件的状态，在各个状态之间进行切换，可以创建和合并分支，通过rebase还可以整理自己的提交历史。通过这些命令和操作，就可完成工作流规范规定的操作流程了。
VV采用标准的Git flow，下面将从工作流图与抽象模型两个方面，来描述与规范 Git flow。
紧急修复分支跟 release 分支类似，都是为发布版本准备的。当线上生成环境有重大的 bug 需要紧急修复，而此时 develop 分支还不稳定，无法发布，我们在 master 分支基础上创建一个 hotfix 分支， 修复 bug 后合并到 master ，再发布到生成环境。
如非特殊说明，所有产品的版本号将遵循 主版本.次版本.BuildNumber 的规则。
来源：https://www.cnblogs.com/fangsmile/p/11535302.html
许多公司的开发团队都采用 Git 来做代码版本控制。如何有效地协同开发人员在开发、测试、上线各个环节的工作，可能都有各自的流程与规范。本文就分享作者一直沿用的团队项目 Git 分支管理规范，希望给有缘阅读的人加以参考，如果有更好的实践，也欢迎探讨、交流，谢谢！
无规矩不成方圆，但是规矩太多了，则感觉到束缚。我们一个人工作的时候喜欢无拘无束，想怎么干就怎么干，没有人评判，没有人检验。时间久了就会盲目自大，以为增删改查熟悉业务就能够搞定一些。但是当项目逐渐扩大，原来的灵活逐渐变成了混乱，原来的快速迭代因为过于随意的代码，而开发进度迟迟不前。掌握一种规范，便在处理类似问题的时候有章可循，也能够快速的融入一个团队。另外所谓规范，可以说是比较好的实践，按照规范来，项目也能稳健的发展。
在工作中使用Git已有5年多的时间了，Git分布式的工作机制以及强大的分支功能使得在团队中推广使用没有受到什么阻碍。一直以来都是采用的分支管理模式，我把项目的开发分为三个阶段：开发、测试和上线。
安装操作：https://www.cnblogs.com/ximiaomiao/p/7140456.html
高效的持续交付体系，必定需要一个合适的代码分支策略。采用不同的代码分支策略，意味着实施不同的代码集成与发布流程，这会影响整个研发团队每日的协作方式，因此研发团队通常需要很认真地选择自己的策略。
因此，在本文中，我们就从「[版本控制简史」出发，揭开「基于 Git 的版本控制工作流」的神秘面纱。
博主说：本文借鉴了很多「 DRPrincess」博主的文章内容，在此对其表示感谢。
转载自：https://github.com/GDJiaMi/frontend-standards/blob/master/development.md
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
目前项目已逐步从svn移步到git开发模式，其中也针对git统一协议了适合git的开发规范， 最重要一点就是分支模型的，为了规范开发，不直接在主干上修改代码，一切代码都提交至分支dev，然后再由分支合并到主干master。 首先保证每个仓库下有以下两个常驻分支（永远不删除的分支）： master：主干分支，始终保持跟外网服务器一致，只用于外网发布，这样就可以保证文件不会带出去的风险； dev：基于master创建，用于开发新功能和新需求的分支。
本地的 master 和远程分支 origin/master 是关联起来的，origin/master 就对应着远程仓库的 master分支
对于Git与其他集中式代码管理工具相比的优缺点的全面讨论，请参见这里。这样的争论总是喋喋不休。作为一个开发者，与现今的其他开发工具相比较，我更喜欢Git。Git真得改变了开发者对于合并和分支的思考。我曾经使用经典的CVS/Subversion，然而每次的合并/分支和其他行为总让人担惊受怕（“小心合并里的冲突，简直要命！”）。但是对于Git来说，这些行为非常简单和搞笑，它们被认为是日常工作中的核心部分。例如，在很多CVS/Subversion书里，分支与合并总是在后面的章节中被讨论（对于高级用户使用），然而在每个Git书中，在第3章就已经完全涵盖了（作为基础）。简单和重复的特性带来的结果是：分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。关于工具，不再多说，让我们直接看开发模型吧。这个模型并不是如下模型：在管理软件开发进度方面，面对每个开发过程，每个队员必须按一定次序开发。
命名: master、develop、feature以feature/功能名、release以release/功能名、hotfix以hotfix/bug名
如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。
最近，团队新入职了一些小伙伴，在开发过程中，他们问我 Git 分支是如何管理的，以及应该怎么提交代码？
当下最流行的版本管理系统应该是非Git莫属。相比同类软件，Git有很多优点，其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。但是，太方便了也会产生副作用。如果不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。Vincent Driessen提出了一个分支管理的策略，非常值得借鉴！它可以使得版本库的
项目开发完一个版本后，需要进行项目的合并与发布 项目合并与发布，需要项目经理和组员一起来完成，每个人将开发的分支逐个合并到dev分支，如果有冲突则解决冲突，在dev上的代码经过测试没有问题后，则由经理合并到master分支，完成发布 实现发布主要遵守如下步骤： 每个人逐个合并分支到dev 经理合并dev到master并发布 每个人获取最新的dev分支、master分支 逐个合并 这一步是每个人将自己分支上开发的代码，合并到dev分支上，每个人逐个执行1-6步 前题：已经完成了自己分支代码的开发并完成
很多初学者都是从写 Python 脚本开始的，从一个人写脚本，逐渐的和团队一起写工程。
Git Flow定义了一个项目发布的分支模型，为管理具有预定发布周期的大型项目提供了一个健壮的框架。
代码库应该有一个、且仅有一个主分支：master。所有提供给用户使用的正式版本，都在这个主分支上发布。
git 流程模式有两种：一种是Git flow工作流，一种是Github flow工作流。
发现文件和文件夹的颜色都是红色 ,当出现这种情况的时候, 说明这些文件还没有添加到git仓库当中
Git作为现在主流的版本控制工具，但是如何在软件开发过程中进行合理的分支管理是一个见仁见智的问题。
关于Git Flow 工作流，我想已经是老生常谈的话题了，但是今天我不得不来重温一下 Git Flow 工作流。当我看的代码厂库的时候，我已经开始怀疑人生。乱七八糟的分支，五花八门的提交信息，各种各样的分支名称，没有 Develop 分支，没有 Release，也没有 Hotfix。因此我想我应该好好温习一遍 Git Flow 工作流，来改善一下厂库现状。
想要深入了解Git和中心化代码版本管理系统的优缺点比较，可以在网上自行查询，这个话题一直争论不休。作为一个开发者，我更倾向于使用Git。Git确实改变了开发者对代码合并和分支管理的认识。作为一个使用过传统的CVS工具的人，合并/开分支是一个比较恐怖的行为，迫不得已才执行一次。
如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。 眼下最流行的"版本管理系统"，非Git莫属。 相比同类软件，Git有很多优点。其中很显著的一点，就是
相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。
文章转自：http://www.ruanyifeng.com/blog/2015/08/git-use-process.html。感谢作者辛苦撰写 眼下最流行的"版本管理系统"，非Git莫属。 相比同
上一篇文章中我们提到了在一个周维度或者月维度发布产品的小型协作项目中，会遇到各类协作上的问题，随着发布的越来越紧凑，问题也就越来越突出。本文主要对上一篇文章中提到的问题解决方案做细化，让大家可以清楚的知道如何通过合理的 git 工作流来解决这些问题，让原来发布时的手忙脚乱不再出现。通过 git flow 我们可以对项目做一个分支模型管理：
在Git的分支合并过程中支持方式，一种是在本地将source branch 合并到 target branch，然后再切换到target branch后将target branch push到远端target branch。另外一种是将本地的source branch push到远端的source branch，然后在gitlab上提交一个将source branch 合并到 target branch的merge request。那么为了能够到达我们强制的CodeReview卡点，我们将master branch（也就是生产发布分支）、release branch（也就是提测分支）进行保护，不能接受直接的push request，只能通过提交merge request，并有架构师或者技术负责人进行CodeReview通过后，完成Merge。那么如何完成Git的分支保护呢？
今天我们谈一下开发团队代码质量如何做到管控与提升，我相信很多公司都会面临这样的问题，开发团队大人员技术水平参差不齐，代码写的不够规范，代码扫描问题修改太过滞后，代码库管理每个团队都不一致，偶尔还会合并丢失一些代码，code review费人费时效率不高，开发任务的管理以及任务与代码的可追溯问题，等等之类的问题，我们能否制定一套从设计到开发再到交付一整套的管控方案来帮助开发团队管控代码的质量？下来我就针对这些问题展开来谈谈我的想法。
在基于 Git 的开发过程中，我们很容易遇到合并代码的情况，例如我们从 master 分支拉取了一个 feature 分支，当我们开发到一段时间之后，可能需要将 master 的代码合并到我们当前的 feature 分支之中。
关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支
学习大佬的iOS开发进阶-06 | 代码管理：如何使用 Git 与 GitHub 统一代码管理流程？，与自己的Git分支管理对比。
本文翻译自Vincent Driessen的：A successful Git branching model
在开发中，遇到这样的情况怎么办？ 网站已有支付宝在线支付功能，要添加"微信支付"，修改了两个文件，wechat.php、pay.php。 刚做到一半，突然有个紧急bug：支付宝支付后不能修改订单状态。你需要立即马上修改这个bug，需要修改的文件是，ali.php、pay.php。 问题是，pay.php文件，已经被你修改了过，而且尚未完成，直接在此基础上改，肯定有问题。把pay.php倒回去？那我之前的工作白费了。 此时你肯定会想：在做"微信支付"时，能否把仓库复制一份，不影响原仓库的内容，修改完毕后，再把副本上的修改合并过去。 好的，这时你已经有了分支的思想。 前面见过的master，即是代码的主干分支。 事实上，在实际的开发中，往往不会直接修改和提交到master分支上，而是创建一个dev分支，在dev分支上，修改测试，再把dev分支合并到master上。 如果有了分支，刚才的难题就好解决了。 在做"微信支付"时，我们创建一个wechat分支，把wechat分支commit，此时，master分支内容不会改变，因为分支不同。 当遇到紧急bug时，创建一个AliBug分支，修复bug后，把AliBug分支合并到master分支上。 再次从容切换到wechat分支上，接着开发"微信支付"功能，开发完毕后，把wechat分支合并到master分支上。
为什么会说这两个呢，是因为我觉得这两个命令有一些共同点，而且git merge 常用，git rebase 不常用，放在一起说的时候，可以更方便了解记忆git rebase。
在这个模型中，master和develop都具有象征意义。master分支上的代码总是稳定的（stable build），随时可以发布出去。develop上的代码总是从feature上合并过来的，可以进行Nightly Builds，但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时，可以创建release分支。
注释：用-r参数删除目录, git rm --cached a.txt 删除的是本地仓库中的文件，且本地工作区的文件会保留且不再与远程仓库发生跟踪关系，如果本地仓库中的文件也要删除则用git rm a.txt
几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离
QA维护了自己的分支 QAtujiabnb ，当有多个项目同时进行，且不断需要合并到QAtujiabnb分支时，手动合并效率太低，急需一个合并的脚本支撑高频率的合并。
Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
