flow

对Git Flow做点微创新 (1)

不打扰是莪最后的温柔 提交于 2019-12-04 01:29:05
昨天写了Git Flow印象( http://www.jiangyouxin.net/2013/02/11/git_flow.html ),总体来说这是个不错的东西,与现在厂里的研发模型非常契合。所以打算稍稍做些修改,然后拿到厂里去推广。 今天做的修改(按老周的话,这叫“微创新”),是在git flow feature finish的时候,提供一个选项,可以将所有修改合并为一个commit提交到develop分支上;feature分支本身的提交历史不再保留。 为什么需要这样一个选项?首先当前的git flow在将feature分支向develop合并的时候,使用了--no-ff,强制生成了一个merge结点。见下图(左): 左图通过merge结点来确定feature之间的边界 —— 如果不使用--no-ff就会形成右图(类似SVN的线性提交历史),日子一久就分不清哪些提交属于同一个feature了。 这已经很好了,但仍不是最好。事实上,feature分支的原始提交历史,很多情况下是无用的。比如说在我厂推广git flow时,feature分支将伴随某个功能“开发 + 测试”的全过程,上面的提交历史体现的是开发和BUG FIX的节奏次序;等合并到develop时,功能基本稳定,只需要合并最终结果,以后也很少会关心这个feature的开发过程中发生了什么事情。 综上

Git Flow

我怕爱的太早我们不能终老 提交于 2019-12-04 01:28:52
Git的优点 Git的优点很多,但是这里只列出我认为非常突出的几点。 由于是分布式,所有本地库包含了远程库的所有内容。 优秀的分支模型,打分支以及合并分支,机器方便。 快速,在这个时间就是金钱的时代,Git由于代码都在本地,打分支和合并分支机器快速,使用个SVN的能深刻体会到这种优势。 感兴趣的,可以去看一下Git本身的设计,内在的架构体现了很多的优势,不愧是出资天才程序员Linus (Linux之父) 之手 版本管理的挑战 虽然有这么优秀的版本管理工具,但是我们面对版本管理的时候,依然有非常大得挑战,我们都知道大家工作在同一个仓库上,那么彼此的代码协作必然带来很多问题和挑战,如下: 如何开始一个Feature的开发,而不影响别的Feature? 由于很容易创建新分支,分支多了如何管理,时间久了,如何知道每个分支是干什么的? 哪些分支已经合并回了主干? 如何进行Release的管理?开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候,开发人员可以继续开发新的功能? 线上代码出Bug了,如何快速修复?而且修复的代码要包含到开发人员的分支以及下一个Release? 大部分开发人员现在使用Git就只是用三个甚至两个分支,一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑

NSCollectionViewFlowLayout - left alignment

大兔子大兔子 提交于 2019-12-03 20:21:33
NSCollectionViewFlowLayout produces a layout with items justified on the right margin or, if the container is only wide enough for one item, centres items. I was expecting an alignment option, e.g. on the delegate, but am not finding anything in the docs. Does it require subclassing NSCollectionViewFlowLayout to achieve this? Obliquely Here is a subclass that produces a left justified flow layout: class LeftFlowLayout: NSCollectionViewFlowLayout { override func layoutAttributesForElementsInRect(rect: CGRect) -> [NSCollectionViewLayoutAttributes] { let defaultAttributes = super

P4014 分配问题 网络流

烂漫一生 提交于 2019-12-03 15:07:40
P4014 分配问题 1 #include <bits/stdc++.h> 2 using namespace std; 3 const int maxn = 305, inf = 0x3f3f3f3f; 4 struct Edge { 5 int from, to, cap, flow, cost; 6 }; 7 8 struct MCMF { 9 int n, m, s, t; 10 vector<Edge> edges; 11 vector<int> G[maxn]; 12 int inq[maxn]; 13 int d[maxn]; 14 int p[maxn]; 15 int a[maxn]; 16 17 void init(int n) { 18 this->n = n; 19 for (int i = 1; i <= n; ++i) G[i].clear(); 20 edges.clear(); 21 } 22 23 void AddEdge(int from, int to, int cap, int cost) { 24 edges.push_back((Edge){from, to, cap, 0, cost}); 25 edges.push_back((Edge){to, from, 0, 0, -cost}); 26 m = edges.size(); 27

P4016 负载平衡问题 网络流

别等时光非礼了梦想. 提交于 2019-12-03 15:04:58
P4016 负载平衡问题 1 #include <bits/stdc++.h> 2 using namespace std; 3 const int maxn = 1005, inf = 0x3f3f3f3f; 4 struct Edge { 5 int from, to, cap, flow, cost; 6 }; 7 8 struct MCMF { 9 int n, m, s, t; 10 vector<Edge> edges; 11 vector<int> G[maxn]; 12 int inq[maxn]; 13 int d[maxn]; 14 int p[maxn]; 15 int a[maxn]; 16 17 void init(int n) { 18 this->n = n; 19 for (int i = 1; i <= n; ++i) G[i].clear(); 20 edges.clear(); 21 } 22 23 void AddEdge(int from, int to, int cap, int cost) { 24 edges.push_back((Edge){from, to, cap, 0, cost}); 25 edges.push_back((Edge){to, from, 0, 0, -cost}); 26 m = edges.size();

P1251 餐巾计划问题 网络流

南楼画角 提交于 2019-12-03 14:45:42
P1251 餐巾计划问题 1 #include <bits/stdc++.h> 2 using namespace std; 3 typedef long long ll; 4 const int maxn = 5005, inf = 0x3f3f3f3f; 5 struct Edge { 6 int from, to; 7 ll cap, flow, cost; 8 }; 9 10 struct MCMF { 11 int n, m, s, t; 12 vector<Edge> edges; 13 vector<int> G[maxn]; 14 int inq[maxn]; 15 ll d[maxn]; 16 int p[maxn]; 17 ll a[maxn]; 18 19 void init(int n) { 20 this->n = n; 21 for (int i = 1; i <= n; ++i) G[i].clear(); 22 edges.clear(); 23 } 24 25 void AddEdge(int from, int to, ll cap, ll cost) { 26 edges.push_back((Edge){from, to, cap, 0, cost}); 27 edges.push_back((Edge){to, from, 0, 0,

二分图的最大匹配(模板)

旧街凉风 提交于 2019-12-03 14:35:48
传送门: https://www.luogu.org/problem/P3386 已经加入极其简单的当前弧优化 1 #include<bits/stdc++.h> 2 using namespace std; 3 int n,m,bian,s,t; 4 int vis; 5 int dep[6000001]; 6 int inque[6000001]; 7 int cur[6000001]; 8 int maxflow=0; 9 struct edge{ 10 int to,nxt,flow; 11 }e[6000001];int tot=-1; 12 int first[6000001]; 13 const int inf=0x3f3f3f3f; 14 inline int kd() 15 { 16 int x=0,f=1;char ch=getchar(); 17 while(ch<'0'||ch>'9'){if(ch=='-')f=-1;ch=getchar();} 18 while(ch>='0'&&ch<='9'){x=x*10+(ch^48);ch=getchar();} 19 return x*f; 20 } 21 inline void add_edge(int a,int b,int c) 22 { 23 e[++tot].to=b; 24 e[tot].flow

Testing sub-flows in Mule

前提是你 提交于 2019-12-03 14:28:34
I have started writing test cases to my Mule project. I have written the functional test case for my Main Flows as follows. public void testMainFlow_1() throws Exception{ MuleClient client = muleContext.getClient(); MuleMessage result = client.send(helloServiceAddress, fileAsString("SamplePayloads/input_Request.xml"), properties); assertNotNull("Null Result", result); assertEquals(result.getPayloadAsString(), fileAsString("SampleResponses/sampleResponse.xml")); } But how can I test my sub-flows. They don't have any end-points. So how can I pass payload to them and test it. Given below is my

How to run a flow once, automatically when starting mule?

醉酒当歌 提交于 2019-12-03 13:28:48
I have a java class that creates a clean MongoDB database with seeded collections. It automatically identifies if the database is missing and creates it. I would like to run this when I start MuleEsb. This way I don't need to remember to invoke it before I start mule. I was hoping to put it inside a flow and run that flow once, automatically when mule starts up. Is there a way to do this one-time operation when mule starts? --- Update --- As per the conversation below I added the following to my mule config and the flow is automatically triggered. <quartz:connector name="Quartz"

Git Flow-基于git的源代码管理模型

邮差的信 提交于 2019-12-03 10:52:32
Git Flow 是什么 Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。 2010年5月,在一篇名为“ 一种成功的Git分支模型 ”的博文中,@nvie介绍了一种在Git之上的软件开发模型。通过利用Git创建和管理分支的能力,为每个分支设定具有特定的含义名称,并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。这种软件开发的活动模型被nwie称为“Git Flow”。 一般而言,软件开发模型有常见的瀑布模型、迭代开发模型、以及最近出现的敏捷开发模型等不同的模型。每种模型有各自应用场景。Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。因此,Git flow可以很好的于各种现有开发模型相结合使用。 在开始研究Git Flow的具体内容前,下面这张图可以看到模型的全貌(引自nvie的 博文 ): Git Flow中的分支 Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动;辅助分支组织为了解决特定的问题而进行的各种开发活动。 主分支 主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中