Odoo14 原生标准模块介绍

odoo通过Apps和Connector扩展和集成数以万计的应用和服务,odoo目前有超过12500个Apps可选用。它囊括了项目管理,生产、财务、记账和销售管理,仓储管理,人力资源管理,等等项目。odoo是企业一体化管理系统,一套电商ERP和企业运营支撑系统,odoo伴随企业成长而不断发展。本次主要了解Odoo官方的几个主要标准模块。

一、网站应用

  1.网站生成器:简洁的 WYSIWYG 编辑器插入文本样式,通过拖放完全可定制的预制构建块,从头开始创建您的页面。

  2.电子商务:使用 Odoo 独特的“行内编辑”方法创建产品页面。无需代码,所见即所得。创建包含多种变量的产品 ,如尺寸、颜色或其他属性。添加变量以添加至产品选项,并在一种环境下创建多家商店。使用独特的设计,语言,货币和价目表启动和管理多个电子商务商店

  3.博文:通过拖放完全可定制的预制构建模块,从前端直接编辑更改内容,无需后端繁杂的操作。

  4.论坛:只需在论坛注册,即可发布问题并回答现有问题,无需重新搭建论坛站点,减轻运维工作量。

  5.幻灯片:可以分享您的文档、PDF、图片、视频等,到幻灯片,使您的文件人人可见。

  6.活动:在官网线上发布活动页面,轻松创建登陆页面、日程表、发言人简历、活动内容等等。用户可在线购买参会票。

  7.在线客服:可以在前端任意页面访问在线客服功能,使您的站点独立IM,适应多种不同语言。

  8.邀约:根据客户个人的时间安排,预约会议、见面等。

二、销售应用

  1.CRM客户关系管理:专门为销售人员设计的直观界面,更清晰的分析商机、线速的转化率,支持导入导出。

  2.POS:支持现金、信用卡支付、也可以自定义添加新的支付方式如支付宝、微信等。

  3.销售:与CRM集成,减少数据录入,避免出错概率,可直接创建报价单、报价单转化为销售订货单等。

  4.订阅:通过订阅功能,可以确认重复性产品报价,并创建含正确设置和产品的合同。

  5.租赁:通过界面视图,概述未来几天/几周内您租借的产品。密切注意您仍可以租用哪些产品以及何时租用等等。

三、财务应用

  1.会计:无需手动创建发票、打印并发送发票、登记银行对账单、跟踪付款,自动化程度越高,越节约时间。一键核对付款账单与多张发票。

  2.开具发票:与销售、库存集成、设置税收规则后、自动结算税收。

  3.开支:轻松提交费用请求,可提交附件,以便为审核人提供工单、账单等开支证明。便于生成报告。

四、运营应用

  1.库存管理:独特的 Odoo 复式录入库存管理可以实现从供应商到客户的完整追溯。一切无遗漏、支持条码出入库。

  2.工时单管理:选择在当天开始、工作中或工作完成后记录您的活动。通过设置默认项目和最短持续时间来加快工作速度。

  3.项目管理:自定义每个项目的流程,按照自己的活动重命名阶段和提醒,自动发送电子邮件,通过看板视图轻松拖放任务。按照阶段、职责、截止日期等对任务分组。便于生成各种维度的报表。

  4.采购管理:能够管理订单,定义销售价格、类型、条形码和参考信息,以轻松区分相同产品。与销售、库存、会计集成。

  5.帮助台:从多个渠道最大限度提升生产力,

  6.文档:可上传预览普遍格式图片、文档、视频第二个,设置文件权限。

  7.现场服务:现场服务已连接到许多其他Odoo应用程序,自动化更强,节省时间,多项目、有规划。

五、制造应用

  1.MRP:包含订单管理、安排计划生产、多级物料清单主数据

  2.PLM:跟踪产品和 ECO 的版本以及各自的文档。合并对应于相同 BoM 的不同 ECO。

  3.设备:根据 KPI 自动触发维护申请,直接从控制中心面板触发纠正性维护。

  4.质量:自动触发对制造部门的质量检查,利用质量警报的看板视图来组织工作。

六、人力资源

  1.招聘:在网站上发布工作机会并在看板视图内跟踪管理申请过程,将招聘流程集成到网站。与员工模块集成

  2.员工:管理员工信息,如工时表、个人资料、合同等等。

  3.车队:管理车辆及维护、合同、燃料消耗等等。与人力、会计集成。

  4.休假:管理休假申请,统计报表信息

  5.评价:便于对员工的管理,按照员工、状态、截止日期、评价和计划名称对评估进行筛选和整理,以获得对评估的清晰概括。

  6.推荐:可以推荐优秀人才,推荐成功可获取相应奖励。

  7.审核:在线审批员工请求,管理更轻松

七、通讯

  1.讨论:相对独立的模块,方便各部门之间沟通。

  2.电子签呈:创建动态工作流程,提高生产力,随时随地可签署文件,达成交易。

  3.调研:与Odoo crm集成,调查提供的所有信息将自动分配到完全集成的数据库中的匹配条目。

八、营销应用

  1.营销:自动化营销,集成SMS、Email等, 通过打开率、弹出率、点击率和送达率等 KPI,查看您的营销活动的执行效果。

九、定制工具

  1.Odoo studio:友好的开发者模式,极速创建自定义应用程序,无需专业开发。

github免用户名密码管理代码

github免用户名密码管理代码

一、问题描述

git管理代码需要输入用户名密码,为避免重复操作,可设置保存用户名和密码。第一次输入后数据保存,后续管理代码不需再次输入。

用户名和密码明文保存会有安全隐患,对安全要求高的不建议采用。

二、操作步骤

1、git安装完成后,打开git bash,配置git全局保存用户名密码,输入如下命令:git config –global credential.helper store

git config –global credential.helper store

该步骤会在windows用户主目录:C:\Users\用户名下生成一个.gitconfig文件,内容为:

[credential]
helper = store

2、然后在git bash上clone或者pull代码,要求输入用户名密码。输入完成,会在windows用户主目录:C:\Users\用户名下生成一个.git-credentials文件,内容为保存的用户名和密码,明文保存有安全隐患。

3、后续clone、pull或者push等操作都不需要再输入用户名密码。

不能出众,那就出局—从一个人到900人的超长马拉松,Odoo CEO的实战心路

星光不问赶路人,时光不负有心人

Odoo科普:自2004年成立以来,Odoo一直采用开源商业模式为核心运营,除了在企业版提供的30个核心应用程序之外,Odoo在全球拥有2万名活跃成员的社区, 提供了超过1.7万个应用程序,满足了广泛的业务需求,已经成为最大商业应用库。

公司规模从2004年的一个人,到2020年九百人的持久马拉松,一路荆棘,一路成长,这一份企业领军人物对于危机管理的实战心路,相信你会有所启发!Odoo作为中小企业信息化的开源解决方案提供者,希望能为中小企业提供借鉴,在危机中找到活下去的突破口。下文将以Fabien Pinckaers第一人称进行讲述。

不论是08年金融危机,还是2020年的疫情打击,我有一个深刻的感受:企业面对的最大威胁往往不是来自于外部,而来自于内部的商业模式的探索和业务持续优化。基于此,提供以下几点企业经营管理的建议和思考,聊以与各位共度艰难时期。

1.聚焦长期效益。

当情况变量变得混乱的时候,这个时候营收下降是正常的,需要把公司有限的精力转移到具有长期效益的重点领域,比如实施团队的项目实施技巧培训,公司内部更好的运营架构,产品调研上新和开发等。放眼长期效益,而不是在项目获客上纠结停留。

2.危中有机,把握背后的机遇,落子无悔

疫情当下,全球范围内启动在家办公,我们也梳理过,odoo的历史机会是什么?答案是请人请人再请人,企业的根基是人才,在特殊的慢下来的时期,集中子弹广纳贤才。两年之前,招聘方面我们经历过阵痛,很难请到合资格的R&D程序员岗位。危机期间,我们加码了程序员的招聘投入,推出了价值10w的程序员入职奖金(写完这篇,小编就要去学python了…酸了酸了),旨在吸引高标准的人才加入odoo, 实现公司规模扩大,满足市场产品迭代的需求,到明年,Odoo员工会达到1400人。

同时,建议大家不妨关注一下市场推广的机会。这个时候可以提高市场推广的预算,大的推广投资项目可以在这个时候下手。绝大多数人恰恰不会考虑市场推广,如果有好的方案和机会,不妨评估抄底,做好准备。

3.快没子弹的时候怎么办?

关于优先级
专注在核心任务上面,比如可以减少见客户。

关于裁员
到了不得不考虑裁员的地步,我建议频率要低,但是最好一次性裁到位。通知之前,要开诚布公地和员工沟通公司的处境和计划,避免糊弄员工。如果情况到了很糟糕的时候,作为管理者肯定是写在脸上的难看,员工是可以感受到的,透明化去沟通,低频裁员不会动摇军心,以维护多年来建立的信任。

关于减速
营收减速,新单和客户可以减少,长期受益的价值体系,绝对不可以忽视。每次危机,我们都会加大研发投入,短期很难见效,但正是长期坚持产品的打磨迭代,造就了今天Odoo的地位——世界最大的开源管理软件库。我们成长曲线也是波动的,高光时刻和低谷并存,过去13年来,每年的平均增长达到了71.47%。一定要把工作重心放在长期价值的建立上,提供的商业价值会不断强化公司的竞争力,成为强大的内生动力,推动企业步步为营,突出重围。企业经营是一场持久马拉松,眼光和战略足够长远,才能行稳致远。

4.活下去

每个高速成长的公司都经历过一地鸡毛的困难时期,在这一点上,没有例外。从现金流预警到破产,你有两年的时间。供应商的付款死线、员工薪酬都促使企业去找到增收的渠道,Odoo每次绝境都幸运地解决了问题,救公司于水火,回到正确的轨道上来。我解决问题的关键是从根本上解决问题,找到深层次问题所在,让业务进阶,撬动更多的打法和资源。所以企业主必须要深入了解业务和市场,找到疑难杂症的源头,对症下药。

每一次困难期的考验都会指引你走向成功。
成功和失败的公司区别在于,前者可以在情况变坏之前,活下来。

5.CEO之于企业

从模型可以看到,公司处于起步小规模的时候,CEO的角色是从上而下的,管理决策、为公司提供更多的指导、强化组织能力和公司文化的建立。公司规模扩大的时候,需要向自下而上的模式转换,下放更多的权利给员工,自下而上的创新和机制的建立,基层员工提供更多的内容。然而危机中,需要回到自上而下的角色模式,个体的创造力需要放到最低,需要强有力的领导力,集中力量攻坚。在此期间,专注是非常重要的,重要的话,要强调三次,敲黑板!

很多时候,优先级和业务重点经营者一定要有清楚的定位,必须清楚地知道你的产品方向在哪里,集中强将专攻少数项目。这个时候,放弃社交,放弃客户,放弃展会,集中在对公司业务优化和提高上,我很少参加商业展会,这是我一贯的原则。

在投资领域,有一个默契的原则,如果你在各种社交场合经常见到一个公司的创始人,那么这个公司不值得投。时间碎片化在无效的领域,这样的创始人,很难为公司带来核心价值,因为他本身不具价值。公司自然不会做出靓眼的成就,投资的真金白银,很有可能付之东流。

6.市场化产品

关于定价
定价是一个技术活,远比你想象的要复杂的多。产品价位的影响远超想象,一般而言,提价20%,你可能利润会增加40%-60%。在这方面,我是踩过坑的,公司规模很小的时候,总是倾向于低估自己服务的价值,日开发服务费设定为200欧,接下来的几年没日没夜地挣扎在为人民服务的苦线上。(此处CEO的苦笑省略一万字…)

关于商业模式
商业模式可以说是最关键的。我花了十年的时间,探索到正确的商业模式。我们有标准化的企业版和社区版,公司变得可以盈利,能够增加两倍的研发投入,进而持续地提供odoo的商业价值。我们和全球2576个优秀的伙伴合作,伙伴为客户提供技术维护服务。这是一个可持续的商业模式,客户在升级系统或遇到问题的时候,都可以得到迅速的反馈。对于任何规模的服务型的公司都是一样, 在销售或者运营服务方面做一些尝试和改变,实现规模升级。

关于差异化价值
不能出众 那就出局。商业模式的要义在于提供差异化价值,你要做的是提供不可替代的商业价值,而不是优化。Odoo能够迅速扩张的原因不是因为我们比Oracle或者SAP好,大厂比我们市场运营能力强大,在垂直领域和不同行业有很好的解决方案,然而我们品牌定位独到,性价比方面优胜,产品极致追求用户友好,具有很高的灵活性和定制化的可能性。像甲骨文这样的大厂,强大之处也正是弱点所在。Odoo差异性的价值定位,为我们开辟了一条独特的赛道。产品方面,在自己的优势领域,不断投入研发,同时加强对竞品的分析,确保开发的性能是更加优化的。头部巨头不断加强影响力的情况下,中小企业必须要致力跻身于少数的几个可以提供差异化价值的玩家,才能找到长久发展的原生引擎。

Gitolite权限配置

基本含义:

C 代表创建,仅在通配符版本库授权是使用,用于指定谁可以创建与通配符匹配的版本库
R RW RW+ R为只读,RW为读写权限,RW+代表除了拥有读写权限,还可以强制执行推送
RWC RW+C
RWD RW+D D代表允许删除和正则匹配的引用
RWCD RW+CD

传统模式的引用授权
传统模式的引用授权指的是在授权指令中只采用R、RW和RW+的传统授权关键字,而不包括后面介绍的扩展授权指令。传统的授权指令没有把分支的创建和分支删除权限细分,而是和写操作及强制推送操作混杂在一起。

1 @administrators = jiangxin admin
2 @dev = dev1 dev2 badboy
3 @test = test1 test2
4
5 repo test/repo1
6 RW+ = @administrators
7 RW master refs/heads/feature/ = @dev
8 R = @test

关于授权的说明:
– 第6行,对于版本库test/repo1,管理员组用户jiangxin和admin可以读写任意分支、强制推送,以及创建和删除引用。
– 第7行,用户组@dev除了对master和refs/heads/feature/开头的引用具有读写权限外,实际上可以读取所有引用。这是因为读取操作授权阶段无法获知引用。
– 第8行,用户组@test对版本库拥有只读授权。

扩展模式的引用授权
扩展模式的引用授权,指的是该版本库的授权指令出现了下列授权关键字中的一个或多个:RWC、RWD、RWCD、RW+C、RW+D、RW+CD,将分支的创建权限和删除权限从读写权限中分离出来,从而可对分支进行更为精细的权限控制。
– 非快进式推送必须拥有上述关键字中的+方可授权。
– 创建引用必须拥有上述关键字中的C方可授权。
– 删除引用必须拥有上述关键字中的D方可授权。
即引用的创建和删除使用了单独的授权关键字,和写权限和强制推送权限分开。

1 repo test/repo2
2 RW+C = @administrators
3 RW+ = @dev
4 RW = @test
5
6 repo test/repo3
7 RW+CD = @administrators
8 RW+C = @dev
9 RW = @test
通过上面的配置文件,对于版本

库test/repo2.git具有如下的授权:
第2行,用户组@administrators中的用户,具有创建和删除引用的权限,并且能强制推送。
其中创建引用来自授权关键字中的C,删除引用来自授权关键中的+,因为该版本库授权指令中没有出现D,因而删除应用授权沿用传统授权关键字。
第3行,用户组@dev中的用户,不能创建引用,但可以删除引用,并且可以强制推送。
因为第2行授权关键字中字符C的出现,使得创建引用采用扩展授权关键字,因而用户组@dev不具有创建引用的权限。
第4行,用户组@test中的用户,拥有读写权限,但是不能创建引用,不能删除引用,也不能强制推送。
通过上面的配置文件,对于版本库test/repo3.git具有如下的授权:
第7行,用户组@administrators中的用户,具有创建和删除引用的权限,并且能强制推送。
其中创建引用来自授权关键字中的C,删除引用来自授权关键中的D。 –
第8行,用户组@dev中的用户,可以创建引用,并能够强制推送,但不能删除引用。
因为第7行授权关键字中字符C和D的出现,使得创建和删除引用都采用扩展授权关键字,因而用户组@dev不具有删除引用的权限。
第9行,用户组@test中的用户,可以推送到任何引用,但是不能创建引用,不能删除引用,也不能强制推送。
对路径的写授权

在授权文件中,如果一个版本库的授权指令中的正则引用字段出现了以NAME/开头的引用,则表明该授权指令是针对路径进行的写授权,并且该版本库要进行基于路径的写授权判断。

1 repo foo
2 RW = @junior_devs @senior_devs
3
4 RW NAME/ = @senior_devs
5 – NAME/Makefile = @junior_devs
6 RW NAME/ = @junior_devs

关于授权的说明:
– 第2行,初级程序员@junior_devs和高级程序员@senior_devs可以对版本库foo进行读写操作。
– 第4行,设定高级程序员@senior_devs对所有文件(NAME/)进行写操作。
– 第5行和第6行,设定初级程序员@junior_devs对除了根目录的Makefile文件外的其他文件具有写权限。

开发时关于git分支控制的一些心得

开发时关于git分支控制的一些心得(master-hotfix-develop-release)

项目代码正在重构,原来为了个人开发方便,都是从master分支(或一个中间分支)上建立一个自己的分支用于开发,开发完毕后将自己的分支merge到master分支(或一个中间分支),结束自己的分支。

在大量的提交后,会导致一些问题:

并没有版本上的控制,看起来就像一个版本一直在开发一样,不存在一个稳定的版本分支(或者master分支落后很多)。
个人的分支没有得到很好的测试,合并到master分支上可能有一些隐藏bug,导致master分支一直都处于不稳定的状态,出现棘手的问题时无法回退到一个稳定版本。
每个人的开发进度不一样,在merge到master分支时导致很多冲突。
在排查错误时,由于merge参数不统一导致master分支上有超级多的commit,只能在master分支上一点一点的回退版本,执行起来很麻烦。
个人的分支上传到GitHub上,导致远程仓库的分支杂乱无章。
参考了一个成功的git分支模型,对现在的git分支管理进行一些调整,便于规范开发。以本人目前开发的项目为例,项目名是visom-server。

一共有五种分支:master、hotfix、develop、release、self分支。master分支是一个主分支,主要提供一个稳定的版本,时刻都是稳定的保证随时可以上线应用。develop分支是一个和master分支并行的分支,用于主开发的分支。hotfix分支是热修复分支,主要用于修复master分支出现的意料之外的bug,属于临时分支,命名以”hotfix-xxx”为准。release分支是发布版本分支,在develop开发完成后做一些版本信息的或细节调整的分支,也属于临时分支,命名以”release-xxx”为准,xxx表示版本号。self分支是个人开发用的分支,命名无特殊要求。
master、develop分支是核心分支,是并行的一直存在在远程仓库的分支,分别提供稳定版本和主开发的作用。下面说一下完整的开发流程。整个流程相对于上面的参考博客比较,关于版本号的自动创建、规范以及其他版本相关的内容还没有完全吃透,所以对这部分和不适合本人公司开发情况的会有些删减,大家可以多提供意见,谢谢。(本人是使用vscode开发的,有些命令可以用vscode功能代替,比如创建、切换分支等)
master、develop分支
首先基于master分支建立一个develop分支,并将develop分支push到远程仓库里,做为开发的核心分支。
>git checkout -b develop master
>git push

基于develop分支建立自己的分支,做一些开发改动,完成后merge到develop分支而不是master分支。develop分支上有每一次改动提交的记录,所以注意merge时的参数。
>git checkout -b zhengsy develop // 基于develop分支创建并切换到zhengsy分支(自己开发的分支)
>git commit -a -m ‘修复project.index传参bug’ //开发代码后,将所有改动储存到本地并加以描述(分多次提交)
>git checkout develop // 切换到develop分支
>git merge –no-ff zhengsy //将zhengsy分支毫无保留的融合到develop分支
>git branch -d zhengsy // 删除zhengsy分支
// 整个过程中自己的分支并没有推送到远程仓库只存在与自己的本地。
// 如果有问题需要协助请推送到远程仓库,最后完成开发任务时请删除远程分支。

hotfix分支
master分支遇到紧急修复的bug时,请使用hotfix分支。hotfix分支也不会出现在远程仓库,只是一个本地的临时分支,融合时请保留提交记录。具体流程如下:

>git checkout -b hotfix-indexbug master // 基于master分支建立一个hotfix-indexbug分支,用于紧急修复
>git commit -a -m ‘修复index传参bug’ // 修复后,将所有改动储存到本地并加以描述(因为master分支是稳定的出现bug,也改动不大,一次性提交即可)
>
>更新master分支!!!!
>git checkout master // 切换到master分支(版本是v1.0.0)
>git merge –no-ff hotfix-indexbug // 将hotfix-indexbug分支融合到master分支
>git tag -a v1.0.1 -m ‘修复index的bug’ // 在本地有打一个版本的标签。(作用不是很明显)
>
>更新develop分支!!!!
>git check develop // 切换到develop分支
>git merge –no-ff hotfix-indexbug // 将hotfix-indexbug分支融合到develop分支
>
>删除hotfix分支
>git branch -d hotfix-indexbug

release分支(暂时作用不明显)
develop分支完成了版本升级任务,即可以给master分支提供下一个稳定版本时,请使用release分支。可能因为develop分支已经完成了该版本开发任务,可以执行下一个开发版本任务了,但为了使开发人员和版本维护人员可以并行,即开发人员继续使用develop分支开发下一个版本,版本维护人员使用release分支撰写该版本的一些信息和应付一些意料不到的小问题,所以使用release分支作为中转。使用release分支和hotfix分支类似,就不再重复命令了,注意分支命名规范。

有一点需要特殊说明的是,release分支融合到master分支时,请使用–squash参数;release分支融合到develop分支时,请使用–no-ff参数。即:

>// 将release-xxx分支融合到master分支
>git checkout master
>git merge –squash release-xxx
>
>// 将release-xxx分支融合到develop分支
>git checkout develop
>git merge –no-ff release-xxx

以上就是本人的一点心得,仍有不完善的地方比如版本说明方面的说明等,感觉版本方面还是使用GitHub上那种的比较好,即完成一个版本就在GitHub上生成一个版本,自己的本地tag更多的是自己方便一些。欢迎大家多提意见。以后有更完善的方案再来补充。

head,master,origin区别

HEAD: the current commit your repo is on. Most of the time HEAD points to the latest commit in your branch, but that doesn’t have to be the case. HEAD really just means “what is my repo currently pointing at”. Thanks svick for the heads up on this one (no pun intended)

In the event that the commit HEAD refers to is not the tip of any branch, this is called a “detached head”.

master: The name of the default branch that git creates for you when first creating a repo. In most cases, “master” means “the main branch”. Most shops have everyone pushing to master, and master is considered the definitive view of the repo. But it’s also common for release branches to be made off of master for releasing. Your local repo has its own master branch, that almost always follows the master of a remote repo.

origin: The default name that git gives to your main remote repo. Your box has its own repo, and you most likely push out to some remote repo that you and all your coworkers push to. That remote repo is almost always called origin, but it doesn’t have to be.

HEAD is an official notion in git, HEAD always has a well defined meaning. master and origin are common names usually used in git but they don’t have to be.

Git rebase的作用

多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的童鞋不得不先pull,在本地合并,然后才能push成功。

每次合并再push后,分支变成了这样:

$ git log –graph –pretty=oneline –abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
* e5e69f1 Merge branch ‘dev’
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/
* | 12a631b merged bug fix 101
|\ \
| * | 4c805e2 fix bug 101
|/ /
* | e1e9c68 merge with no-ff
|\ \
| |/
| * f52c633 add merge
|/
* cf810e4 conflict fixed
总之看上去很乱,有强迫症的童鞋会问:为什么Git的提交历史不能是一条干净的直线?

其实是可以做到的!

Git有一种称为rebase的操作,有人把它翻译成“变基”。

rebase

我们从实际问题出发,看看怎么把分叉的提交变成直线。

在和远程分支同步后,我们对hello.py这个文件做了两次提交。用git log命令看看:

$ git log –graph –pretty=oneline –abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch ‘dev’
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env

注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello,本地分支比远程分支快两个提交。

现在我们尝试推送本地分支:

$ git push origin master
To github.com:michaelliao/learngit.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to ‘git@github.com:michaelliao/learngit.git’
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
很不幸,失败了,这说明有人先于我们推送了远程分支。按照经验,先pull一下:

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
d1be385..f005ed4 master -> origin/master
* [new tag] v1.0 -> v1.0
Auto-merging hello.py
Merge made by the ‘recursive’ strategy.
hello.py | 1 +
1 file changed, 1 insertion(+)
再用git status看看状态:

$ git status
On branch master
Your branch is ahead of ‘origin/master’ by 3 commits.
(use “git push” to publish your local commits)

nothing to commit, working tree clean
加上刚才合并的提交,现在我们本地分支比远程分支超前3个提交。

用git log看看:

$ git log –graph –pretty=oneline –abbrev-commit
* e0ea545 (HEAD -> master) Merge branch ‘master’ of github.com:michaelliao/learngit
|\
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/
* d1be385 init hello

对强迫症童鞋来说,现在事情有点不对头,提交历史分叉了。如果现在把本地分支push到远程,有没有问题?

有!

什么问题?

不好看!

有没有解决方法?

有!

这个时候,rebase就派上了用场。我们输入命令git rebase试试:

$ git rebase
First, rewinding head to replay your work on top of it…
Applying: add comment
Using index info to reconstruct a base tree…
M hello.py
Falling back to patching base and 3-way merge…
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree…
M hello.py
Falling back to patching base and 3-way merge…
Auto-merging hello.py
输出了一大堆操作,到底是啥效果?再用git log看看:

$ git log –graph –pretty=oneline –abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello

原本分叉的提交现在变成一条直线了!这种神奇的操作是怎么实现的?其实原理非常简单。我们注意观察,发现Git把我们本地的提交“挪动”了位置,放到了f005ed4 (origin/master) set exit=1之后,这样,整个提交历史就成了一条直线。rebase操作前后,最终的提交内容是一致的,但是,我们本地的commit修改内容已经变化了,它们的修改不再基于d1be385 init hello,而是基于f005ed4 (origin/master) set exit=1,但最后的提交7e61ed4内容是一致的。

这就是rebase操作的特点:把分叉的提交历史“整理”成一条直线,看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后,通过push操作把本地分支推送到远程:

Mac:~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
f005ed4..7e61ed4 master -> master
再用git log看看效果:

$ git log –graph –pretty=oneline –abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello

远程分支的提交历史也是一条直线。

odoo worker 异常Exception(“bus.Bus unavailable”)

odoo worker 异常Exception(“bus.Bus unavailable”)

odoo 在配置workers后会有如下错误

Traceback (most recent call last):

File “/opt/odoo/openerp/http.py”, line 530, in _handle_exception

return super(JsonRequest, self)._handle_exception(exception)

File “/opt/odoo/openerp/http.py”, line 567, in dispatch

result = self._call_function(**self.params)

File “/opt/odoo/openerp/http.py”, line 303, in _call_function

return checked_call(self.db, *args, **kwargs)

File “/opt/odoo/openerp/service/model.py”, line 113, in wrapper

return f(dbname, *args, **kwargs)

File “/opt/odoo/openerp/http.py”, line 300, in checked_call

return self.endpoint(*a, **kw)

File “/opt/odoo/openerp/http.py”, line 796, in __call__

return self.method(*args, **kw)

File “/opt/odoo/openerp/http.py”, line 396, in response_wrap

response = f(*args, **kw)

File “/opt/odoo/addons/bus/bus.py”, line 188, in poll

raise Exception(“bus.Bus unavailable”)

原因:

工人> 0会有很多线程在端口8069上。

你也会有几个cron线程8069(max-cron-threads)。

一个gevent线程在端口8072上(longpolling-port)。

这里的问题就在8072上,web会用8069请求longpolling。所以http出错。

解决方法:

安装返向代理,用http://host:80代理 http://localhost:8069/ 和 http://localhost:8072/longpolling即可

如nginx配置

Conf代码 收藏代码
location / {
proxy_pass http://localhost:8069/;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /longpolling/ {
proxy_pass http://localhost:8072/longpolling/;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

git核心分支

git的分支是十分的轻量级,git的新建分支,合并分支等操作几乎是瞬间完成。
1、Git 创建一个新的分支仅仅是创建一个新的分支指针。如:git branch testing 创建一个testing分支;会commit 对象上新建一个分支指针并指向当前commit
2、Git 是如何知道当前在哪个分支上工作的呢?有一个名为HEAD 的特别指针,运行git branch 命令,仅仅是建立了一个新的分支,但不会自动切换到这个分支中,所以当前我们仍然在master分支。
3、要切换到其他分支,执行git checkout 命令。我们现在转换到新建的testing 分支:git checkout testing,git仅仅是将HEAD指针指向了testing,几乎瞬间完成。
4、如果这时我们再次修改了文件,并提交(git commit ),仅仅是testing分支指向了最新commit ,而master仍指向在原来的commit
5、使用git checkout master切换回master分支。git做了两件事它把HEAD 指针移回到master 分支,并把工作目录中的文件换成了master 分支所指向的快照内容。
注意:在git中新的commit对象中的parent是指向着上一个commit。
6、在master分支我们修改文件再进行提交,这时项目提交历史产生了分叉。
Git 中的分支实际上仅是一个包含所指对象校验和(40 个字符长度SHA-1 字串)的文件,所以创建和销毁一个分支就变得非常廉价。新建一个分支就是向一个文件写入41 个字节(外加一个换行符)。
如果我们有需要我们可以完全再次checkout到testing分支去开发新的功能。我们可以在分支间随意切换,并且都是瞬间切换完成。这和之前大多数版本控制系统形成了鲜明对比,它们管理分支大多采取备份所有项目文件到特定目录的方式,所以根据项目文件数量和大小不同,可能花费的时间也会有相当大的差别,快则几秒,慢则数分钟。而Git 的实现与项目复杂度无关,它永远可以在几毫秒的时间内完成分支的创建和切换。每次提交时都记录了祖先信息(译注:即parent 对象),所以以后要合并分支时,寻找恰当的合并基础(译注:即共同祖先)的工作其实已经完成了一大半。

Git 中commit、tree、blob三个对象之间的关系

在现有的项目中查看Commit、tree、blob


进入到有git管理的项目所在的磁盘目录下:
执行git log查看版本提交历史:
每个commit都对应唯一的编号
来看上边执行到最后的冒号:这时该怎么退出再次进入书写git命令呢,  直接输一个 q 就可以了
查看就近commit具体的内容:
git cat-file -p 82cfe8
看到了这个commit中有个tree
接着看下这个tree的具体内容:
git cat-file -p 56c3567

对应磁盘中:
没显示的都是被忽略的文件
tree中又包括tree和blob
查看blob的具体内容,也就是上图中 .gitignore的内容
对应磁盘目录下该文件的内容是一模一样的
至此commit、tree、和blob三者之间的关系也就一目了然了。
1.commit存储一次提交的信息,包括所在的tree,parent是谁,以及提交的作者是谁等信息。
2.tag:标签,给重要的commit的一个别名。
3.tree:代表的是目录结构,或者简单理解为代表一个目录
4.blob:用来存储文件内容,或者说表示一个文件

总结
每一次commit对应一个tree,这个tree又记录了整个文档的目录结构,文件的每一次修改又会生成一个blob,blob信息记录在tree下面。