技术,产品,创业,互联网,投资理财,生活感悟

第 4 页

7月31日,深圳前海微众银行股份有限公司、上海万向区块链股份公司、矩阵元技术(深圳)有限公司联合宣布重磅消息,将三方近一年来潜心开发、且已实践检验过的区块链底层平台BCOS(取BlockChain OpenSource涵义命名)完全开源。 缘起 在传统的中心化商业模式陷入“大而不能倒”(too big to fail)的窘境并引发金融危机之后,追求多方参与和对等合作的新型商业模式逐渐凸显价值。这种全新的模式我们称之为“分布式商业”,其特点在于多方平等参与、智能协同、专业分工、价值分享等,已经在不同的领域体现出一定的发展潜力。相对应地,为了实现分布式商业的共享与透明规则,以开源为主要特征的分布式技术也得以发挥优势,区块链技术、分布式账本技术等渐渐成为了前沿科技的核心代表。 在此背景下,微众银行、万向区块链、矩阵元在2016年成立了联合区块链实验室,并推进两大区块链联盟金链盟与Chinaledger达成战略合作,致力于共同进行区块链底层平台开发,推动区块链应用场景落地,促进区块链产业与区块链生态在中国的改革创新与蓬勃发展。历经几年的分别探索,以及近一年的整合磨砺,三方顺利完成BCOS平台并开源,以此吸引更多的开发者加入开发,拥抱区块链的开源时代。 探索 BCOS平台从中国的商业可行性与监管要求出发,进行了深度理解和定制,更加适合国内企业使用;另一方面,三家机构本身就具有大规模的商用业务需求,对生产环境里能达到的并发用户数、访问量、吞吐量、响应时间、可用性、安全性等要求更高,BCOS平台亦是力求满足这些内在需求。 新的技术终究要在应用场景尤其是具备海量用户的企业级应用场景中被充分验证并推广,才能评判其成熟度。在真实生产数据的检验下,BCOS平台保持零故障运行,印证了其安全可控、业务可行、健壮可用的优点,其功能、性能、容错性、可靠性、安全性、保密性、可追溯、模块化、可维护性、可移植性、互操作性、数据一致性等特性亦被验证可达到高标准。 价值 BCOS平台作为国内首个安全可控、可商用的开源区块链技术平台,通过集成身份认证、非对称加密算法、引入技术治理功能、支持全面监管审计功能等举措,可支持多个行业的应用需求,满足中国金融业务要求,填补了区块链领域的空白。 对于使用BCOS平台的开发者而言,既能够共享区块链的底层设施,包括共享云服务相关的技术、软件和代码,不需要每个开发成员重复投入,又能使用友好、简单、跨平台的应用开发API与图形化管理台及区块链浏览器等,加速开发流程,改善区块链产品的创建和管理体验。 作为商用的新一代数据交换基础设施,BCOS平台支持监管及商用应用的所有核心技术特性,满足使用者的需要: 提供全面的监管和审计支持模块,满足业务合规要求; 提供对全网商业机构节点的准入控制、CA身份认证、账户管理体系和安全监控功能,支持分布式商业运作的技术治理需求; 实现共识机制的插件化,可支持PBFT、RAFT等多类共识算法,便于匹配不同业务场景需求; 采用分布式数据存储架构,支持海量数据容量与弹性扩容能力,并提供高强度加密存储功能和配套密钥管理机制,提升数据存储安全; 支持对全网所有节点同时进行灵活的配置修改,配置数据保持高一致性; 提供基于密码学的隐私保护功能,支持分布式商业中的保密数据交换; 支持全方位的安全防护机制,兼顾物理安全、传输安全、存储安全、网络安全、密钥安全等。 BCOS平台的构建可有两种方式:开源代码和云服务,两种方式都提供了详细的用户手册,开发文档和样例代码。 理念 回归区块链技术的本质, 其最初的目的是通过一系列公开公正、透明可信的规则,让系统实现在无人干预和管理的情况下自主正常运行,因此大部分主流区块链技术平台皆以开源社区的形式存在。其价值核心是在开放的精神下,以源码为核心,建立起规范的、长久的自治理制度,促进开发者持续有序地对源代码进行改善。 因此,三方联手打造的BCOS平台遵循以下六大价值理念(DRIVES): 了解BCOS平台,访问Github社区:https://github.com/bcosorg/bcos 白皮书下载地址:https://raw.githubusercontent.com/bcosorg/bcos/master/doc/BCOS_Whitepaper.pdf 相关链接 BCOS 的详细介绍:点击查看 BCOS 的下载地址:点击下载

最近国内各大网盘纷纷关停,好多同学都被迫迁移文件。但问题是,国内的网盘服务都是说停就停,根本没有哪个能真正让人放心,那么怎么办才好呢? 现在比较靠谱的方案除了番·羽·土·啬转移文件到国外大牌的如 Dropbox 或 Google Drive,或者购买 Office 365 用 OneDrive 之外,最稳妥的办法还是购买 NAS 或 VPS 服务器来「建立属于自己私有的云存储网盘」了!之前我们推荐过 Seafile 可以轻松搭建自己的跨平台私有云同步盘。其实,国外也有做得相当不错的同类的产品 ownCloud……

spring boot因为内嵌tomcat容器,所以可以通过打包为jar包的方法将项目发布,但是如何将spring boot项目打包成可发布到tomcat中的war包项目呢? 1. 既然需要打包成war包项目,首先需要在pom.xml文件中修改打包类型,将spring boot默认的<packaging>jar</packaging>修改为<packaging>war</packaging>形式; 2. 其次spring boot的web项目中内嵌tomcat服务器,所以如果我们想要发布war包到tomcat项目,要讲spring boot中内嵌的tomcat包依赖排除,不然产生冲突,打开下面代码中的注释即可。 1 2 3 4 5 6 7 8 9 10 11 12 <dependency>     <groupId>org.springframework.boot</groupId>     <artifactId>spring-boot-starter-web</artifactId>     <!–     <exclusions>         <exclusion>             <groupId>org.springframework.boot</groupId>             <artifactId>spring-boot-starter-tomcat</artifactId>         </exclusion>     </exclusions>     –> </dependency>            有一点想说的是,如果本地开发的时候依然想要使用spring boot内嵌tomcat进行调试,添加如下依赖即可; 1 2 3 4 5 <dependency>     <groupId>org.springframework.boot</groupId>     <artifactId>spring-boot-starter-tomcat</artifactId>     <scope>provided</scope> </dependency> 3. spring boot发布jar包web程序的入口是main函数所在的类,使用@SpringBootApplication注解。但是如果war包发布至tomcat,需要增加 SpringBootServletInitializer 子类,并覆盖它的 configure 方法,或者直接将main函数所在的类继承 SpringBootServletInitializer 子类,并覆盖它的 configure 方法。代码举例如下, 1 2 3 4 5 6 7 8 9 10 11 12 13 14 @SpringBootApplication public class DemoApplication extends SpringBootServletInitializer {          @Override     protected SpringApplicationBuilder configure(             SpringApplicationBuilder application) {         return application.sources(DemoApplication.class);     }          public static void main(String[] args) {         SpringApplication.run(DemoApplication.class, args);     } } 以上就完成了spring boot项目打包war包的所有步骤,可以发布至tomcat7及其以上版本。 但是以上流程改造完spring boot打包war包发布至tomcat6版本之后,浏览器访问项目地址会给出404的错误?为什么呢,一头雾水,经过我一番查阅资料以及实验,得出以下结论, 首先spring boot支持的servlet容器如下,可以看出spring boot最低支持的servlet版本是3.0,但是tomcat6的servlet版本是2.5,这样的话上面的流程是无法支持tomcat6发布spring boot项目的, 但是又google了一番,发现已经有人在解决这个问题了,https://github.com/dsyer/spring-boot-legacy, 标题就表明了它是为了让spring boot支持servlet2.5,刚好解决我们的痛点,使用步骤如下: 1. pom.xml中添加spring-boot-legacy的依赖, 1 2 3 4 5 <dependency>     <groupId>org.springframework.boot</groupId>     <artifactId>spring-boot-legacy</artifactId>     <version>1.1.0.RELEASE</version> </dependency> 2.手动替换web.xml文件。但是在发布war包中发现metricFilter提示空指针异常,我就简单粗暴的将filter过滤了,注释如下。 所要替换的web.xml文件的未知如下 : {工程目录}/src/main/webapp/WEB-INF/web.xml 1 2 3 4 5 6 7 8 9 10 11 …

为什么要在J2EE项目中谈异常处理呢?可能许多java初学者都想说:“异常处理不就是try….catch…finally吗?这谁都会啊!”。笔者在初学java时也是这样认为的。如何在一个多层的j2ee项目中定义相应的异常类?在项目中的每一层如何进行异常处理?异常何时被抛出?异常何时被记录?异常该怎么记录?何时需要把checked Exception转化成unchecked Exception ,何时需要把unChecked Exception转化成checked Exception?异常是否应该呈现到前端页面?如何设计一个异常框架?本文将就这些问题进行探讨。 1. JAVA异常处理 在面向过程式的编程语言中,我们可以通过返回值来确定方法是否正常执行。比如在一个c语言编写的程序中,如果方法正确的执行则返回1.错误则返回0。在vb或delphi开发的应用程序中,出现错误时,我们就弹出一个消息框给用户。 通过方法的返回值我们并不能获得错误的详细信息。可能因为方法由不同的程序员编写,当同一类错误在不同的方法出现时,返回的结果和错误信息并不一致。 所以java语言采取了一个统一的异常处理机制。 什么是异常?运行时发生的可被捕获和处理的错误。 在java语言中,Exception是所有异常的父类。任何异常都扩展于Exception类。Exception就相当于一个错误类型。如果要定义一个新的错误类型就扩展一个新的Exception子类。采用异常的好处还在于可以精确的定位到导致程序出错的源代码位置,并获得详细的错误信息。 Java异常处理通过五个关键字来实现,try,catch,throw ,throws, finally。具体的异常处理结构由try….catch….finally块来实现。try块存放可能出现异常的java语句,catch用来捕获发生的异常,并对异常进行处理。Finally块用来清除程序中未释放的资源。不管理try块的代码如何返回,finally块都总是被执行。 一个典型的异常处理代码 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 public String getPassword(String userId)throws DataAccessException{ String sql = “select password from userinfo where userid=’”+userId +”’”; String password = null; Connection con = null; Statement s = null; ResultSet rs = null; try{ con = getConnection();//获得数据连接 s = con.createStatement(); rs = s.executeQuery(sql); while(rs.next()){ password = rs.getString(1); } rs.close(); s.close(); } Catch(SqlException ex){ throw new DataAccessException(ex); } finally{ try{ if(con != null){ con.close(); } } Catch(SQLException sqlEx){ throw new DataAccessException(“关闭连接失败!”,sqlEx); } } return …

尼采说:“人类怎样才能被提升到其显赫状况和权力的顶峰呢?”思考这一问题的人首先须得明白,他本人一定要置身于自身的狭隘之外,用超脱的眼光去看待。但这似乎又超脱了人们追求显赫与权利的范畴。因此,就本质看来移动应用的统计分析平台,必须建立在移动开发者的这种期待之上,而它本身又要用开源的姿态来抵制这种不客观的期待。 Countly项目旨在提供移动应用程序的分析工具。我们最近有机会与该项目的主要开发人员, Onur Alp Soner进行讨论。以下是对话内容。 编辑:Countly是个不错的开源移动分析平台。请您谈谈它能为移动应用程序开发者提供什么? Onur Alp Soner:Countly提供了一个移动分析平台。它是首个开源的移动分析的解决方案,任何人都可以将Countly客户端部署在自己的服务器并将开发工具包整合到他们的应用程序中,从而开始使用。在Ubuntu服务器和本地部署整个Countly仅需要20分钟,很简单!并且将保证服务器数据安全。Countly真正做到了实时分析,快速,可扩展,目前领先其他同类程序。  图:Countly统计后台 编辑:你们是为了解决自己在移动开发中的问题而开发了Countly么? Onur Alp Soner:Countly项目组中有人专门做移动应用框架开发,其他的成员也都从事移动开发和设计工作,大家是从无到有,逐渐完善地搭建Countly的。 Countly很好的帮助我们解决了多年的业务问题,但我们仍旧决定将它开源,以便集思广益,与众多的移动应用开发者共享Countly的未来。 编辑:Countly上架以来受欢迎吗?  Onur Alp Soner:5月起,Countly已被下载超过2000次。很多用户都评价它简单有效,集成控制平台效果出众。例如,UX设计公司InnovationBox就使用 Countly跟踪分析测试了6款移动平台应用。我们正在与InnovationBox共同测试事件系统,所有的测试都在平行进行,以确保顺利推出下一个版本。而托管服务提供商Ontek,则凭借自家的图形的绘图应用程序“Gitsin CIZ”刚刚打入iTunes市场,该软件使用了Countly的iOS SDK来进行跟踪分析。  图:Countly统计后台 编辑:最新的12.07版本有什么内容? Onur Alp Soner:12.07主要是更多的考虑了用户的需求。现已支持跟踪应用程序版本,平台和平台版本。支持通过改写API时间戳来添加过去的数据,并在仪表盘上做了一些改进,使它可以清除所有应用程序的存储数据(主要是用于测试目的),并加入了一些视觉效果。 编辑:那么接下来的版本将带来怎样的惊喜呢?是什么给你们研发灵感? Onur Alp Soner:即将发布的12.08版本将包括用户最期待的功能,自定义事件。开发者将能够自定义跟踪指标。目前预定义的指标还仅仅在仪表板上,如会话数,用户数,国家,设备等,但是从下个版本开始,开发者将能够跟踪到自己的应用程序特定的度量。例如,将能够跟踪查询应用程序购买数量和金额,所有这些自定义指标,仅仅需要具体添加一行代码。 说到灵感,我们有非常活跃的社区。社区会员的需求和建议引领我们构思下一代产品。在5月我们发布首个版本(12.05)两星期后,我们收到了一位会员发来的Hearko版本Countly服务器端口和Appcelerator Titanium SDK 。另一位社区成员建立了Windows SDK并于近期完成了测试。几个星期前,我们决定进行本地化Countly,用时一星期使Countly仪表盘全面支持7种语言,另有4种语言正在尽快制作中。12.08版本将有望提供11种语言支持。 我们非常感激从社区会员那里得到的支持和帮助,这些也成为了我们发展的核心动力。我们热情欢迎每个人加入这个项目,在我们的博客分享他们的想法,给我们反馈信息,或者帮助我们撰文宣传。 编辑:Countly的底层技术和框架是什么?想要参与项目的人要具备哪些基础?  图:Countly统计后台 Onur Alp Soner:Countly是由两部分组成,软件开发工具包和服务器。前者将嵌入到应用程序的SDK中作为通信渠道,收集数据进行可视化操作并上传Countly服务器。现在,我们有Android和iOS软件开发工具包,这是用Java和Objective-C编写的。Blackberry和Windows的软件开发工具包也即将发布。 而服务器是建立在Node.js 和 MongoDB之上的 。它也由两部分组成,一是API,这是一个普通的Node.js的服务器,监听读取和写入请求,而另一部分则是仪表板,采用Express.js结构。由于比重较大的客户端工具如backbone , underscore , handlebars 和 jQuery,都建立在javascript中,因此,对有意愿参与Countly项目发展的开发者来说,必须了解JavaScript。而如果已经有一定的Node.js和MongoDB的使用基础则再好不过。  

奔四了,职业发展方面不是很亮丽,也不是很好。 对于现在的迷茫的几个点, 1.之前是上市公司,现在是要进入创业团队 2.之前强度小,现在工作强度加度 3.之前是技术经理,现在转技术序列   未来纯技术路线还能走多久? 现在走的路,到时是否符合自己的职业发展? 现在是不是已经是温水煮青蛙? 自己是不是在走下坡路? 自己的2年计划,5年计划到底是什么样子??   是狗急跳墙,还是病急乱投医, 时间是宝贵的,现在做的事情是否还有意义???      

非常高兴回答你的这个问题并和知友们分享这个话题: 人力资本时代的股权架构设计 。事实上,我在考虑分享这个话题的时候。也大概回顾了一下一年多以来自己深度服务的几十家初创企业,从而总结了自己的一些心得体会。 从宏观层面上 ,创业公司早期最为核心的四类人:创始人、合伙人、核心员工、投资人。他们都是属于公司也是 早期风险的承担者 和 价值贡献输出者 ,在人力资本 / 互联网轻资产驱动的初创公司,早期做股权架构设计的时候基本上都是围绕着基于 人力资本价值输出 的高度认可。 在我看来,科学的股权架构基本上是要满足早期这核心四类人的诉求: 创始人维度来看 ,本质上的诉求是 控制权 ,创始人的诉求是掌握公司的发展方向,所以在早期做股权架构设计的时候必须考虑到创始人控制权,有一个相对较大的股权(一般建议是合伙人平均持股比例的 2-4 倍) 合伙人维度来看 ,合伙人 / 联合创始人作为创始人的追随者,基于合伙理念价值观必须是高度一致。合伙人作为公司的所有者之一,希望在公司有一定的 参与权 和 话语权 。所以,早期必须拿出一部分股权来均分(这部分股权基本上占到 8%-15%) 核心员工维度来看 ,他们的诉求是 分红权 ,核心员工在公司高速发展阶段起到至关重要的作用,在早期做股权架构设计的时候需要把这部分股权预留出来,等公司处于快速发展阶段的期权就能真正意义派上用场(通常建议初次分配完之后同比例稀释预留 10%-25%) 投资人维度来看 ,投资人追求高净值回报,对于优质项目他们的诉求是快速进入和快速退出,所以在一定程度上说,投资人要求的 优先清算权 和 优先认购权 是非常合理的诉求,创始团队在面临这些诉求的时候,一定程度上还是需要理解。 从微观层面上 ,股权是多种股东权利的集合体(投票权、分红权、知情权、经营决策权、选举权、优先受让权、优先认购权、转让权等),其中,表现最为重要的是 投票权 和 分红权 。当我们在早期真正做股权架构设计的时候可能需要考虑更多的是这四个宏观维度背后具体的细节分析。而题主的问题仅是创始人宏观维度背后股权分配中的 股权比例确认 (股权怎么分)的问题,事实上,在人力资本驱动的创业时代,我们要思考的不仅仅是股权比例的问题!而是围绕着股权做体系化设计。 创始人层面:主要关注的是控制权。 一、 股东会 :为了严谨我得先约定股权生命线的前提是 【同股同权】 1/ 67% 绝对控制权(有权修改公司的章程、增资扩股) 2/ 51% 相对控制权(对重大决策进行表决控制) 3/ 34% 否决权(股东会的决策可以直接否决) 4/ 20% 界定同业竞争权力(上市公司可以合并你的报表,你就上不了市了) 5/ 10% 有权申请公司解散(超过公司 10%的股东有权召开临时股东大会) 6/ 5% 股东变动会影响上市(超过 5%的股权所有权就要举牌) 7/ 3% 拥有提案权(持有超过 3%的股东有权向股东大会提交临时提案) * 注释:这里就再简单讲一下 【同股不同权】 的情况,一般采用 投票权委托协议 和 一致行动人协议 来约定从而实现同股不同权的效果,如果你想做 AB 股 / 双层股权架构设计,或者三层股权架构设计,就要考虑在海外上市了,不然就不用想了(具体都是什么意思,这里就不展开讲了) 二、 董事会 :董事会的决策机制区别于股东会,按照 【一人一票制】 *注释:董事会成员是由股东会选举产生,董事会对股东会负责。 1/ 三分之二以上,依据董事会议事规则执行。 2/ 半数以上,董事长和副董事长由董事会以全体董事的过半数选举产生。 3/ 三分之一以上 董事或者监事会,可以提议召开董事会临时会议。董事长应当自接到提议后十日内,召集和主持董事会会议。 4/ 特殊约定除外(例如: 一票否决权 )【依据董事会议事规则执行】 以上描述的这些都是控制权要点,而创始人层面要思考的是如何绊随着融资节奏一步步稀释,整体防止控制权的丢失,这里就不展开讲,涉及的内容是从公司层面整体出发的,操作起来非常复杂,基本上都是个性化设计的! 三、 股权分配 :主要是量化分配【 量化 】和分期兑现【 动态 】 【量化】在早期股权分配的时候,通常情况下,我们只用考虑到创始团队成员之间的股权分配的问题,那么股权怎么分比较合理呢?在这里我们要区分的是 人力资本驱动 的互联网轻资产行业和 财务资本驱动 的重资产行业,我的以下观点是基于人力资本驱动的互联网轻资产行业考虑的: * 注释:我们把这个股权比作一个蛋糕,先切成四块。然后每个人在每个维度根据个人实际现状进行量化分配,最后加起来就是你们的股权分配结果。 1、 创始人股 :为保障创始人 控制权 ,通常情况下会有一部分蛋糕是创始人独占的,我建议是 20%-30%(具体根据发起人人数确定) 2、 身份 / 发起人股 :为保障联合创始人 话语权 ,这个维度上的蛋糕是大家一起均分的,我建议是 8%-15%之间(具体根据发起人人数确定) 3、 风险 / 资金股 :回到最开始讲的 早期风险的承担者 和 价值贡献输出者 ,在这个维度上就是早期的风险承担部分,这个维度上的蛋糕是依据实际出资来确定,我建议是 10%-25%(具体根据实际出资总额和工作年薪与现行工资差额来确定) 4、 贡献股 :围绕着基于 人力资本价值输出 的高度认可,这部分蛋糕我的建议是 30%-62%,大致分为基础贡献股(公司背景和工作年限)和岗位价值贡献股(基于行业属性判断的岗位价值权重)。 【动态】大多数轻资产的互联网公司都是基于人的价值输出带动公司的快速发展,但是由于人力资本的不确定性太强,特别是一些核心关键岗位的 leader(通常就是合伙人 / 联合创始人)一旦发生人力价值输出终止通常给公司带来的伤害也是毁灭性的。这样不仅让公司无法正常运营,同时也带走其名下的股权。给后期的发展埋下深深的隐患(这里就不详述了,太多的案例)。所以,基于此我建议股权是动态的: 成熟期:3-5 年 成熟机制:以 4 年成熟期为例 1+1/36 1+1+1+1 2+2 3+1 1+2+1 成熟原则:创始团队成熟机制尽量保持一致 立刻成熟份额:基于合伙时间确定(3 个月 5% / 6 个月 10%) 联合创始人层面:主要关注的是话语权 一、 持股比例 :原则上来讲,联合创始人持股比例最好是 10%-25%之间(上线浮动 2%)。创始人持股比例应该是合伙人人均持股比例的 2-4 倍(联合创始人早期最好控制在 2-5 人,后面加入的便是合伙人)。 二、 持股模式 有三种:直接持有、创始人代持、持股平台 直接持有:表示要进行工商登记的部分是各自持有的全部股权,直接登记部分的股权是指各自(已经成熟的股权 + 未成熟的股权) 创始人代持:表示该部分股权不显名,该部分是指未成熟部分股权。创始人工商登记的股权(未成熟的全部股份【包括自己 + 其他联合创始人】+ 自己已经成熟股份) 持股平台:设立一个有限合伙(基本上就是一个壳),创始人做为有限合伙的 GP,被激励对象作为 LP,基于有限合伙的特殊性,GP 是法定的绝对控制人。这种方式比较稳定,也是大多数做股权激励时采用的方式。 三、 进入机制 即成熟机制参见 【动态】 四、 退出机制 :主要分过错退出和无过错退出;过错退出处理方式是采用法律允许的最低价格(零对价 /1 元人名币)回购其所有股权(不论成熟与否);无过错(成熟股权)退出一般有两种补偿模式,其一,按照净资产的 1.5-2.5 倍之间结算;其二,则是按照对应估值的 10%-20%。无过错(未成熟部分股权)按照获得时对应股权的出资额返回 / 对应出资额按照银行利率的一个倍数进行补偿(控制在 3 倍以内)。 核心员工层面:预留合适的期权池 一、 期权池比例的确定 :一般有种 三个方式 :其一,投资人要求的比例确定;其二,根据创始团队的情况确定,其二,基于已有的方向 / 商业模式设计确定。 二、 期权池的来源 :通常情况下建议是创始团队之间确定好股权比例后, 同比例稀释 一个(前面三种方式确定的比例)期权池,然后把期权池设计成 10,000,000 股(自由约定,以方便计算和统计为主)。有的创始团队早期期权池预留特别大(一般是指在 …

工欲善其事,必先利其器。 作为一名开发人员,你不可能不知道git,无论你是开发自己的开源项目还是和团队一起进行大规模产品的开发,git都已经是源代码管理工具的首选。当然,那些hardcore developer会说,command line才是最好的工具,但并不是所有的时候command line都是高效的(不服?在command line里面做个compare试试你就知道了)。小编日常用的最多的也是command line,但是总还是会把几个好用的GUI Git客户端放在手边备着。 独立客户端工具 GitHub for Desktop 全球开发人员交友俱乐部提供的强大工具,功能完善,使用方便。对于使用GitHub的开发人员来说是非常便捷的工具。界面干净,用起来非常顺手,上面的这条timeline非常漂亮,也可以直接提交PR。 唯一让我失望的是GitHub for Desktop不带三方合并工具,你必须自己手动解决冲突才可以。 – 免费 – 同时支持 Windows 和 Mac:对于需要经常在不同的操作系统间切换的开发人员来说非常方便。 – 漂亮的界面:作为每天盯着看的工具,颜值是非常重要的 – 支持Pull Request:直接从客户端提交PR,很方便 – Timeline 支持:直接在时间线上显示每次提交的时间点和大小 – 支持git LFS:存储大文件更加节省空间和高效 – 不支持三方合并:需要借助第三方工具才行 Source Tree SourceTree是老牌的Git GUI管理工具了,也号称是最好用的Git GUI工具。我的体验是确实强大,功能丰富,基本操作和高级操作都设计得非常流畅,适合初学者上手。 这个工具很有特色的一个功能就是支持Git Flow,你可以一键创建Git Flow的工作流。Git Flow是非常高效的团队协作模型和流程,Git的一大特色就是灵活轻量的分支,但如何在自己的团队中用好这个功能来匹配自己的研发流程是个问题。内置Git Flow让那些不太熟悉的开发人员也可以很快上手,并且将研发的业务流程固化在工具中,可以说是非常贴心的设计。 在 Windows 环境下,SourceTree是多语言的,但是不知道为什么我的Mac版总是显示英文。 – 免费 – 功能强大:无论你是新手还是重度用户,SourceTree 都会让你觉得很顺手。对于非常重度用户,Source Tree还支持自定义脚本的执行。 – 同时支持 Windows 和 Mac 操作系统 – 同时支持 Git 和 Mercurial 两种 VCS – 内置GitHub, BitBucket 和 Stash 的支持:直接绑定帐号即可操作远程repo TortoiseGit 对这只小乌龟估计没有开发人员会不认识,SVN的超广泛使用也使得这个超好用的Svn客户端成了几乎每个开发人员的桌面必备软件。小乌龟只提供Windows版本,提供中文版支持的,对于中国的开发者来说者绝对是福音。 小乌龟的文件管理器右键菜单的操作方式对于新手来说非常的容易上手,而且容易理解。 – 免费 – 只支持Windows操作系统:与文件管理器的良好集成 – 中文界面 – 与TortoiseSVN一脉相承的操作体验 IDE集成的Git客户端 对于使用IDE进行开发的程序员来说,可以不离开常用的IDE就直接操作源代码管理系统是最好的选择,以下是我对几个常见的IDE集成的git客户端的一点体验。 Xcode 苹果的移动端应用体验没得说,但是桌面软件的体验就只能呵呵了。对于XCode里面的Git客户端来说,我只能说:够用! 这个history的列表也是够简单的了。 Eclipse – Egit 作为Java集成开发环境的代表,Eclipse内置了egit这个插件来提供git的集成支持。实话实说,这个插件的功能非常丰富,无论是普通的clone, commit, pull/push操作;还是复杂一些的git flow都有支持。除了颜值差点,其它都还好。 Visual Studio – Git Integration & GitHub Extension Visual Studio 作为全宇宙最强IDE的名声已经在外,自从2013版本以来一直在针对Git的支持进行改进。如果配合社区版使用的话,也是完全免费的。对于使用Windows作为开发环境的程序员来说,VS里面的Git支持已经相当的完善。 直接克隆github上的repo 分支和历史记录视图 CodeLens 集成,可以直接在方法级别上查看git历史 Visual Studio Code 严格来说,Vscode不能算是IDE,只能算上代码编辑器而已,但是随着vscode上面插件的增加以及对于debugging的良好支持,vscode已经狠接近IDE的使用体验了。另外,vscode可以支持Windows, Mac和Linux操作系统,所以对于不同环境的开发人员来说都非常实用。 总的来说,我最喜欢的是Source Tree 和 …