WIP
git branch model总结
刚到新公司的时候，发现大家的git分支和部署环境有点混乱，大家没有一个统一的标准，经常会因此分支混乱导致一些不必要的错误。因为之前工作中也用过各种各样的分支管理模型，但是一直没有好好梳理一下，所以就趁机稍微研究了一下，把调研的总结记录一下，并且最后写一下我们最终选择的方案是什么。
常见的git分支策略
GitHub Flow
GitHub Flow是最简单粗暴的flow。它只有一个核心的master分支和一堆其他分支。每次要加新feature或者要fix一个bug，那么就从master拉出一个新分支，然后经过commit，test，pull request，deploy，最后merge进master。GitHub Flow的优点是简单，缺点是太简单，如果有多套部署环境，或者有强的release版本的需求，它都不能支持。
Git Flow
Git Flow比GitHub Flow复杂很多，引入了几种新的类型的branch。
- develop 有点类似上面的master，所有经过充分测试和review的commit都会合到这个分支。
- master 像develop的精简版，每个commit都有tag，对应develop上面多个commit。通过master可以很方便的找到某个版本的全部代码。
- feature-* 字面意思，都从develop拉出，然后合回develop。
- hotfix-* 如果线上发现问题需要hotfix，需要用到hotfix分支，都从master拉出，然后合回master和develop。
- release-* 每次develop的commit合进master之前需要拉出一个release分支，然后做一些version bump之类的操作，然后合回master和develop。这个分支看起来比较鸡肋，但是其实用处很大，一个场景是如果develop上面有多个在测试的feature，但是这次release并不想把它们都发出去，就可以在release分支上面只抽取出想要的feature。
Git Flow还是很全面的，我们最终的方案也基本上参照了它的操作。不过它的复杂性也令很多项目望而却步。
GitLab Flow
GitLab Flow强调的是不那么复杂，但是又可以支持多种环境和记录release版本。它的主分支还是master分支，一般会部署在staging环境，如果要部到production环境的话，需要从master提到production的pr。如果还有其他环境，比如pp，那么会在master和production之间再添加一个pp分支。至于release分支的话是为了记录某一个版本的release，如果需要release一个版本，只要从master拉出一个分支就可以。
我们项目的选择
我们最终选择的方案大部分参照了git flow的实现，具体做法是
- master分支对应git flow的develop。因为一般项目默认的主分支是master，所以这样可以避免混淆。
- release分支对应git flow的master。在release分支上，每一个commit都有tag，对应一个发布版本。
- feature分支和hotfix分支和git flow一致。
- pre-release分支对应git flow的release分支。每次要release一个版本之前，都会从master拉出一个pre-release分支，然后在上面bump version，有时候也会有一些小的bug fix和配置改变。我们使用maven的release plugin来帮我们做version bump。
- environment分支。我们的环境除了staging和production以外，可能还会有pp、qa、load、simulation。为了应该各种环境，我们计划参照Gitlab Flow，每个环境分支对应那个环境实际部署的版本。但是在实际操作过程中，过多的分支会给开发人员带来很大的负担，最好能配合好用的git相关工具。所以我们暂时没有使用这些分支，而是还是主要使用master和feature分支。
目前来看，这个分支策略还有一些欠缺，比如hotfix和pre-release每次merge都得merge进release和master两个分支，一不小心就容易忘记。还有环境分支的使用上现在还没有找到合适的工具。之后随着我们的策略的更新，再来进一步更新吧。
参考资料
计算广告生态中的各种角色梳理
先来一张不太完整的图展现下各种角色之间的交互关系
角色介绍
Advertiser：广告的需求方，就是广告主或者广告代理。
Publisher：广告的供给方，指提供广告位的媒体。
ADN： Ad Network，从各个媒体采买流量，然后转卖给Advertiser。主要服务于一些体量比较小的媒体，或者一个大媒体的边角流量。
ADN的好处是可以替媒体和广告主牵线，帮助媒体流量变现。然后ADN的局限也很明显，一方面ADN的定价过程是个黑盒，媒体很难实现流量价值的最大化；
另一方面，广告主的获得的流量也很难保证质量，缺乏流量选择的自主性。
ADX： Ad Exchanger，由于ADN的限制，逐渐发展出一种叫RTB（RealTime Bidding）的模式，对于媒体的每一次曝光机会，
多个广告主可以根据自己定向的需求实时发起竞价，价高者或者展示机会。这样媒体可以获得更高的利益，广告主也可以更自由地选择。
DSP：Demand Side Platform。ADX的出现使得广告投放的逻辑变得非常复杂，并不是每个广告主都有足够的数据能力来做判断流量是否适合自己，
而越来越多的ADX使得这个复杂程度进一步加强。在这样的背景下DSP应运而生，它的出现就是为了Demand Side，也就是广告主服务的，
广告主只要将自己的预算、定向条件等高速DSP，然后由DSP来和各种ADX打交道，将广告主的钱最优化地投入到最合适的流量上。
通常广告主和DSP是按CPM签的合同，但是DSP和ADX又是按CPC计费，那么如果DSP的算法足够优秀，那么就可以为自己赚到更多的差价。
但是想要赚到这个钱是个技术活，DSP需要对有足够的数据能力来分析流量和用户数据，预估广告位价值，然后按照预估价值排序来决定投放。
所以无论是算法还是数据层面都需要很高的技术积累。
SSP: Supply Side Platform。顾名思义就是为需求方服务的，用于和各种ADX打交道。但是真正单独做SSP的很少，
很多ADX都会在自己这里简化同媒体的交互流程，从而方便和媒体的对接。
DMP：Data Management Platform。DMP和上面的角色不太一样，它不直接参与广告的流程，但是又是越来越复杂的广告系统中不可或缺的。
它通过自己强大的数据能力，为DSP提供数据支持。
市场上公司和角色的对应关系
放一张rtbchina上的2019年的中国程序化广告生态图
