SaaS 的通用架构(兼回答我在做什么)

翻到以前画的几张图,拿来回答一下我最近在干什么(点击放大) ^_^  。

modules & overall structure

access flow & sys archit

做企业的业务逻辑,用 Web 的技术方式,这就是我们现在在干的事儿~。

“国产”“双核”浏览器是个好东西

Update: 新增了“世界之窗”浏览器的测试结果。

作为一名亲美不爱国人士、一名技术至上的 Geek,我大脑里的信息接收系统,向来对国产的 IT 产品自动选择性过滤。

不巧的是,这一年多来我不得不时常思考 Web 产品运营的问题,“因特网探险家6”像梦魇一样折磨着我……。当你瞅着 HTML5 激动不已的时候,IE6 会让你的汽泄得瘪瘪的。。。别以为 HTML5 只是 Flash 杀手,它有着许多许多现代 Web 开发不可或缺的特性,即使 IE8 也比它的六哥强太多了!

那么,我们怎么办?期待盗版 Windows XP 一夜之间消失,IE6 寿终正寝吗?恐怕只是一厢情愿吧。这个时候我想到,“国产”“双核”浏览器是唯一可能在短期内改变大局的“人物”!

所谓“双核”浏览器,就是在 IE 的 Trident 内核外,再集成一个 WebKit 内核。部分网站用 Trident 内核渲染,另外一部分用 WebKit 渲染。试想,如果这些浏览器默认使用 WebKit 内核,岂非是帮助在国内市场瞬间普及了 WebKit?这是何等激动人心呐!

据称,360 浏览器在国内的市场份额约达 20%。我想,新的 Web 产品已经不得不考虑对它的兼容性,也即考虑对 WebKit 的兼容性,也即使用标准技术。当新的网站大多按标准行事时,对 Trident 的需求将越来越少,越来越多的浏览器会默认使用 WebKit。这是一个正反馈。

以下是我这个勇敢的小白得出的测试数据(按市场份额排序):

浏览器名称 主流版本 双核版本 是否默认 WebKit
360 3.5 4.0
搜狗 2.2 2.2
QQ 4.8 5.0 beta3
遨游 2.5 3.0
世界之窗 3.3 4.0

目前的情形,各浏览器(除搜狗外)的双核版本都还处于怂恿、造势阶段,都还没有成为默认的主流版本。而搜狗,虽然已经默认双核版本了,但并没有默认 WebKit。

当各国产浏览器默认了双核版本,且双核版本默认了 WebKit 内核。“因特网探险家6”带给我的梦魇将有希望结束。当然,它结束的不只是我,而是这个时代 Web 开发者的痛苦。这是 360 们给自己树碑立传的机会,期待看到他们的作为。

“SNS”和“微博”——理念相克,试图揉合可能适得其反

SNS 和 Microblog 都已不是新鲜话题了,但有一个势头,SNS 想整合微博、微博想整合 SNS,我认为这不是好主意,可能会适得其反。

 

SNS 是什么?是关系,是加好友。七大姑八大姨、同学发小、客户伙伴……总之,你认识的人都得加上。毕竟,亲戚朋友多总是好事。

Microblog 是什么?是获取信息的途径。用来关注那些可能并不认识,但他们说的话使你感兴趣,能给你带来信息、思考或知识的人。

于是,冲突产生了:

  • SNS 应该鼓励实名化,微博随便匿名;
  • SNS 双向确认好友关系,微博应该单向关注;
  • SNS 鼓励多加好友、只要是认识的人;微博推荐物以类聚,不介意事先是否认识;
  • ……

 

拿 Twitter 这个显而易见的例子,如果我的某个发小在上面,我可能不会 fo 他。原因很简单,经过多年的各自发展,也许我们感情仍然很好,但隔行如隔山,我们可能很难有共同话题了。他发的他们那个行业很有意思的段子,可能我会觉得索然无味。上推是为了看一些有意思、对口味的信息,所以我不 fo 他。

那么,另外一个例子——豆瓣。它的社区应该是 Facebook 型的还是 Twitter 型的?设想一下,因为你在豆瓣把你的姑姑姨姨们加为了好友,某天你想买本 IT 书籍的时候,豆瓣会向你推荐某某菜谱;某天你想欣赏科幻电影的时候,它向你推荐xx韩剧;……是何感触?所以豆瓣的社区也应该是 Twitter 型的(大概一两年前,豆瓣有一个改版,似乎没经受住 Facebook 的诱惑,在原有的“关注”基础上,又增加了个加好友的功能。当时我相当讨厌,就离它远了点,后来的某个时刻,发现这个功能又被砍掉了,幸甚!)。

 

总结起来,凡是你想从所关注的人中获取有效信息的,或者系统根据所关注的人,通过算法自动向用户推荐有价值信息的,都应该是微博型的社区。而 SNS 适合生活化的东西,我觉得。

 

后记:刚发过一条推:

前几年,我订阅了很多互联网大佬的博客,带着崇敬的心情探头阅读这个行业。最近,我了解了一下大佬们的动向,发现他们主导的产品都关门鸟~。互联网跟体育一样,评论员当不好运动员。我还当不了评论员,努力成为一名运动员ing,嗯~!
http://twitter.com/wcm/status/8904614644551680

唔,敲自己脑袋,不要评论,要运动! @_@

工作日志:我们不是一个人在战斗

按:
这是在公司内部社区写的。本意是为同事而写,但我想,它也正好记录了我自己的认识。所以,以后若有类似不涉及公司、产品及同事隐私的日志,也会将其记录在我的个人日志里。

月度总结会议提纲:

一、时机
1、v1.0 发布、v1.5 15 天时间、业务接踵而至;
2、团队磨合,有进步、还有陋习,不能就此停滞。

 

二、追求卓越,拒绝平庸
1、基础并不好,自知自省,努力;
2、更新换代,有机会超越;
3、再也不是单打独斗的年代,比得是团队凝聚力、战斗力。

 

三、We Are One
0:我们不是又一个混日子的团队

1:友好、尊重、相互着想
宽容、存大志,不要小心眼;
审视行为习惯,是否会无意中给他人造成伤害/误会。

2:主动性、全局观、责任感
整个系统都与我有关,贡献创意、发现问题;
参与、决策,not 螺丝钉;
视野 -> 思考 -> 积淀 -> 施展。

3:自我激励、团队价值
像大海一样清洁环境,不像污染源一样毒害团队。

 

四、We Could Be Better
1:技术
兴趣、执着、好奇心,不服输、成就感、自豪感……;
内驱力,积淀技术、锻炼能力、创造自我价值。需要被监督的人是可耻的!

2:效率
工作方式,自省、总结;
慵懒、分心的时候,告诉自己——时光正在无情地流逝。

3:产品 & 需求
技术不是玩具,它的目标是产品;
若搞错了方向,更快的速度只使南辕北辙得更远,认真对待需求;
为产品更优秀而激动,非为多一个工作任务而抵触。

 

五、男儿心胸,志在千里
1、卓越的技术、优秀的产品;
2、可能,创造新天地;
3、上层建筑,需要物质基础,我的职责我深知;
4、价值 -> 回报;not 回报 -> 价值。

价值的迷思

实在无法把下面完整的意思,压缩到 Twitter 140 字的限制内。于是,发到 Blog 来凑数吧,呵呵~。

一直想创建一个有价值的应用,而非利用用户的无聊浪费他们的时间。

比如,豆瓣的书影音,是我认可的应用之一。但我意识到,使用这样的应用,表明用户开始了价值积淀。虽不一定积淀得多丰厚,但至少已经开始了。然而,有更多更多更多的人还处于粗放阶段,积淀?完全没有意识。

潜在用户只有小部分能成为实际用户;
但对用户素质有要求的应用,更只有总体中的很小部分能成为潜在用户;
价值与市场容量两全,不是件易事。

工作日志:高筑墙、广积粮,练好内功最重要

按:
这是在公司内部社区写的。本意是为别人而写,但我想,它也正好记录了我自己的认识。所以,以后若有类似不涉及公司、产品及同事隐私的日志,也会将其记录在我的个人日志里。

Hello Everybody,

我一直在思考两个问题:
对于个人,我们的技术如何更快地成长?同样的技术能力,如何才能工作生活得更有效率?
对于团队,如何才能更有效地沟通、协作?如何形成舒适的工作氛围?如何达到能力互补,具备强大的整体战斗力?

每当观察到一个相关的现象,我都会把它记下来,待到下周一时与大家分享。可是,看到大家那么严肃的样子,我又反思自己是不是说得太过份了……。

我想,不如我换一种做法,把它写下来吧。恰巧现在是我们年中总结的时机,那么,就从这次开始。

下面是随机记录的一些事情,没有多大的逻辑关系,也不一定是正确的,只是我一时的想法,和大家共勉。:-)

————————————————————————————

珍惜时间:
并不是说大家不珍惜时间,相反,都很努力。我只是感叹时间真的太宝贵。在学校的时候,我们常说青春、青春易逝,那个时候只是在无病呻吟;如今,像是真的能看见时光在眼前流逝。一晃之间,一个星期就没了,一个月也没了,不小心就到了年底。好在我们还没有七老八十,还有一丝资本可供挣扎,我愿与大家共勉:不徒费了光阴,努力使它过得有点意义。倒不是说,要大家多加班,努力工作自然是好事,工作之外有意义的事情也是好的。譬如,钻研跟工作关系不大的技术,或是提高提高自己人文方面的修养。重要的是,我们是清醒的,并且是高效的!

对自己的作品负责:
实话说,这是我对大家不太满意的地方,特别是两位新同事。你们已经转正了,我希望你们在学校或者别的地方养成的敷衍的习惯,能够到此终止。
一件事情交给我们,我们就要对它负全责。首先思考,应该采用什么方法,有多少种可能,它们的优缺点是什么,怎么选择。考虑了,拿不定主意,那只是经验的欠缺;但如果什么都不想,就等着别人来给我们画好条条框框,那就太没有追求了。
特别是,做完的东西,自己要把好关。这个作品,它代表了你的态度品味、技术水平,你自己是否满意?举个明显的例子:代码评论那个,难道开发完了,不会自己试一下的!?要知道,我是真心地相信它完成了,实实在在地在使用,并不是来做边界测试挑刺的,结果第一次用就出了问题。类似这样,我拿到手里随便看一下就发现无数问题的例子太多了……。
我们是一个靠谱的团队,这是得到公司其他部门认可的。我希望,靠谱的人不要做出不靠谱的事来;更希望,这个靠谱,不是经过我加工出来的。每个人,他的作品直接拿出去,都应该是自豪的、经得起推敲的。

细节的讲究:
我看到很多重复的、无意义的 commit log,有人可以解释一下你为什么这么懒吗?我看到有文件名是 js.js、css.css,请问,取个有意义的名字真的这么难吗!?不光如此,也包括目录名、类名、方法名,以及很多其它的细节。将各种细节问题揭示给大家,确是我的职责,但我更希望大家自己能有发现这些细节的眼光。

学习借鉴、拓展视角:
有时候,我们做的东西在公司内部或者市场上已经有可借鉴的案例。大家不妨多参考一下。当然,并不是说看得越多越好,重要的是我们看的时候要有思考。先要有自己的构思,在构思的过程中,就可能会对产品的概念、特点、设计、实现技术、实现形式等等产生疑问。带着我们的疑问去看案例,才能“内行看门道”,否则只是流于浮表,看了也白看。对于案例中与我们想法不一致的地方,应该思考它为什么这样设计/实现,哪种方式更优。以及案例整体的逻辑结构、用户体验等等,是否合理,是否有改进的余地。
另外,有的产品会在宣传中声称“遵循国际xxx标准,实现国内yyy规范”。我想,应该有这个敏锐,第一步就是去搜这所谓的标准、规范到底是个什么东西(如果还不知道的话),它针对的是什么行业、试图解决什么问题、大概概念是什么、有什么启发、是否适合我们、是否要具体跟进……。这对拓 宽我们的视角是很有帮助的。

抽象能力、把握全局:
作为一名程序员,如果搞不懂某项具体的技术,自然是很不爽。但我们也很容易陷入技术的细节当中,以致只见树木不见森林。抽象能力,是我们应该自我训练的重要能力。除了基本的对事物的抽象,还有对复杂系统提纲挈领的理解。了解一个软件产品,我们首先需要了解它对用户意味着什么、具备什么功能;然后,从技术架构上,大体上分为几个部分。有了大的概念之后,再进一步深入技术细节。这样,系统总体上是什么样子、我们当前处于哪一步,在脑海中就有一个清晰的印象。

主动反馈:
有的同事,好像从来不曾主动向我反馈过他的工作状态。你现在在做什么?有什么进展?遇到了什么问题?……。我已经在工作流程和其它地方强调过多次了,我的职责要求我知道整个团队现在处于什么状态。告诉我一下工作进展,没那么难吧?你不说,我只好去问了。其实我不想问的,我不想给大家太大压力。下回,当你觉得我老逼问你,很讨厌的时候,请反思一下,你是不是太久没让我知道你的进展了。我觉得 leask 同志有时候做得很好,吃饭的时候简单交流两句,即交流了工作,又有了闲聊的谈资。工作中有数不清的细节,如果靠一个人,一个个去检查,会累死人。希望大家在自己的工作责任范围内,做到主动反馈,给我留点时间做别的事情。

积极讨论,踊跃发言:
头脑风暴的时候,就是要随便说,想到什么说什么,大家不用那么严肃。。。平时多思考、多积累,当你有了自认为很好的想法的时候,就会自信很多。有时候就算是不太合适的方法,说不定也能启发别人的思路呢。我的经验,我经常会在讨论中蹦出不错的想法,这些想法并不是讨论之前准备的,而是在讨论中受了别人的启发。

不是搞定一项技术,而是解决一个问题:
解决方案,用来满足用户需求的一个方案,说白了,就是解决一个问题的方法。技术,都是试图用来解决具体问题的,当我们面对技术迷雾的时候,不妨问自己一句:我要解决什么问题?这并不一定是纯业务的,技术上也一样。
比如我们前段日子搞 NBGit,其实 NBGit 并非我们的目标,我们真正的需求,是建立一套规范合理、简单好用的 Git 工作流程。有了这个概念以后就知道,我们不能简单地宣布 NBGit 不好用,放弃之,我们必须得寻找到一个好用的方案。NBGit 的作者若遇到问题,需要跟它死磕到底,直至觉得无法解决,放弃项目,终止;寻找 Git 工作流程解决之道的人,只要发现有更好的办法,马上可以放弃 NBGit,放弃之后也并非像前者一样,是任务的终止,他需要确定新的方法。
我知道,搞技术的人,对所谓的业务、解决方案都很头疼,觉得拐弯抹角,不直截了当。这是另外一种看问题的角度,习惯之后,我们就能从另外一个角度看到另外一种风景。也会发现,跟非技术人员交流,变得简单了很多~。

不要未加工的资料:
有时候,我需要大家帮忙调查、对比一些技术/工具,可是结果有时有点无语,是原生生地从 Google 抄下来的资料。我自己不会搜么?优秀的做法,是认真去看这些资料,看明白咯,搞懂咯,写出你的理解。它们各自有什么优势、劣势,建议采取哪个方案,为什么,它的优点有多大的意义,缺点应该怎么避免……?

理清逻辑,找到问题的根源:
同事之间多讨论是好事情,更好的,是我们在讨论之前先把问题想明白。有时候,我们把同事叫过来,却又说不清楚自己的问题。最好,在讨论之前,先自己跟自己对话,或者假设桌上的笔筒是你的小听众。把问题的逻辑搞清楚,我要做什么?做了什么?怎么做的?遇到了什么问题?有什么可行的方法?怎么选择?……若是问题太多、脑子太乱,就拿出纸笔把它写下来。
我想,我这些字大家很可能轻轻地一看而过。但是如果你没试过,我强烈地建议你试一试。我的感受,这个方法简单却很管用。很多时候自己跟自己一对话,逻辑清楚了,问题就随之解决了;有时候脑子里想不明白的问题,在纸上简单地写一下,结果就很明了。

总结 而非 汇报:
总结是为自己而做,沉下心来,安静地思考自己的成长。
有些同事,贴一段代码就算完成任务。代码,版本库里不是有么?重要的,是要解释清楚。假设你面前是一个完全没听过这个概念的人,整理好你的思路、说辞,要尽量让不懂的人看后觉得清晰明了。这样,我们写的东西对团队其他成员才有帮助。更重要的,是在这个过程中,理清楚自己的思路、加深对技术的认识。这对我们的逻辑概括能力、总结表达能力也都是很好的自我训练。

把工作安排得井然有序:
有时候,我给大家说的是一些比较大的任务,实际上可以细分成更具体的内容;或者,你自己在开发过程中又想到了很多的问题。光靠大脑是不够的,太多太乱太疲惫、丢这忘那。我建议大家在项目管理系统中记录下来,建一个任务,分派给自己。这样,有多少事情、状态怎么样,一目了然。当然,是记在 issue tracker 里,还是记在本子上,要看个人喜好,但是没有记录肯定是很容易出问题的。我个人,是把所有想到的事情记在 issue tracker 里(大家可以去围观),但把当前最重要的两三件事情记在本子上,摊在面前。

提问题、证实自己的想法:
老总说的听说读写几个方面,我觉得都很实在、很有道理。其它几个属于个人素养,需要自己慢慢悟。我觉得听这方面,提问题的方法,尤其有现实意义。我们已经出现过几次这种情况:我说的时候对方表示很好,做完了却发现不是我想要的。当你不太有把握的时候,不妨多问几个问题。是不是我理解的这样?几个问题下来,我们就能达到理解的一致,或者发现存在的误差。

注重积累,Wiki 是不断改进的:
我们的 Wiki 现在已经有了不少内容,但请不要觉得 Wiki 写完了就完成任务了,若是发现有可改进之处请毫不犹豫地更新!特别是在我们工作的过程中,重复处理 or 重复回答的问题,记在 Wiki 里沉淀下来也许是个不错的方法~。

愉快的心情、健康的身体:
我是个爱运动的人,可是安排得不太好,实际上运动很少,肩膀和腰都经常不舒服。大家好像比我更少运动,时间久了也会不舒服的。我有时候去游泳,完了之后觉得浑身通畅,像是小说里说的打通了任督二脉。建议大家,根据自己的爱好,做个规律的运动计划。共勉!:-)

记录的主要的内容终于写完了……,个别具体的事项再当面讨论。

stay hungry, stay foolish!

————————————————————————————

既然说是年中总结,我也总结一下自己半年来的主要工作

团队建设:
从人员的招聘到相互的了解,团队的风格,以及思考各个成员及团队整体的能力塑造。我的指导原则,是要以个人鲜明的影响力保证团队在一条正确的道路上快速前进;同时做到中庸与无为,即,在具体的工作中淡化个人的作用,给团队其他成员发挥能力的空间。

工作机制与工作流程:
我们工作的各个环节,基本上都形成了适当的机制。除了开发,其它像招聘时的面试、笔试、评价这样的行政工作,我也都总结出了通行合理的做法。使得第一遍做过的事,以后在此成果与经验基础之上,用少得多的时间即可完成。努力的目标,就是使我们的工作流程,在“最优的机制+最优的工具“的帮助之下,达到“优雅、高效、智能、惬意“。

需求理解与技术设计:
这指我们已有的三个产品。

广泛涉猎:
作为职责,我可以不进行具体的开发,但如果我对产品与相关技术没有整体的把握,则是失职。涉猎的内容,有的是与产品技术直接相关的,有的则是更底层的基础技术,或是大一点的概念如企业IT建设的方方面面,都是我关注的内容。技术之外,像需求、规范、设计等等也是涉猎的内容。视角的广度与深度,决定了决策的优劣。作为个人目标,我希望自己能做到:一手拿RFC、一手拿国家发展计划纲要;脑袋里构思出一套解决方案,一半想的是纲要里的战略需要、一半想的是RFC 里的技术实现。。。

总的来说,这半年来,虽然细节上做得还不尽完美,但实质上没有遇到大的挑战。所需的种种能力,都是自己多年来努力培养的目标。

————————————————————————————

我对自己不满意的地方,是整体的工作效率不够高,自己寻找原因

客观原因:
如身体、距离、设备等,不细述。

并发而琐碎的工作事项:
相对来说,以前主要还是搞技术,具体的技术,一沉进去就是数个小时。现在,更多的是一些小块的工作事项。频繁地在任务之间切换,一会是技术问题、一会是业务问题,以及一会思考团队、一会执行行政任务,适应起来还是有点问题,有时候把自己搞晕了,不知道在做什么。

偏重逻辑的思维方式:
有时候需要参考一些文章,类似企业IT战略、产品的介绍资料之类的。这样的文章往往写得十分的概念化,几年前初看这种文章时,我会感到非常气愤,觉得全是废话,直接说用到了什么技术、什么标准、什么工具不就得了吗?!现在好多了,能够平心静气地看下去,试图从中挖掘出一些有价值的观点、策略或技术。但有时候还是会头大。

行政工作:
行政工作耗费了我比想象中多很多的时间。除了必要或者不必要的往复交涉,以 Word 为核心的工作流也是一个原因。大部分同事交上来的资料,或者管理部发过来的模板,格式都不够好,而我又不希望从我手里出去的东西有太大的瑕疵。我以前不太用 MS Word 的,因为以上原因,不得不在页眉、行距、表格属性……以及各种疑难杂症上耗费了不少时间。希望我们的工作流产品完成之后,能先在自己公司成功部署。Web 化是我的目标,它不仅仅简化了表面的格式设置,也为数据的收集、搜索、统计等再利用提供了方便。

————————————————————————————

完了。感谢阅读(滚动到最后…)!

Git 系列之四:Git 进阶功能

【TIP】在我们的《Windows 下 Git 配置与使用指南》 中,有介绍大家使用 $ git go 命令。其实,这并非 Git 的原生命令,它是我们自定义的一个 alias(别名),由 $git add、$git commit、$git push 和 $git pull 四个命令组合而成。待熟悉之后,你可以直接使用这些原生命令,或者自定义更适合自己的 alias。

add

添加新文件到 Git 代码仓库的索引中

$ git add filename

mv

移动或重命名文件

$ git mv old-filename new-filename

rm

从工作目录和 Git 代码索引中删除文件

$ git rm filename

status

查看目前工作目录的代码状态,自上次提交以来的添加、修改和删除等

$ git status

diff

查看自上次提交以来,本地代码改动的具体情况

$ git diff

commit

提交修改的代码(只是提交到本地的代码库,不会推送到服务器)

$ git commit -am '修改说明'

如果觉得刚提交的“修改说明”写得不够好,可输入以下命令调整

$ git commit --amend

push

将自上次 push 以来的,本地历次 commit,推送到服务器

结合我们的实际,应该这样写:

$ git push origin master:your-id

其中,master 是本地的分支名;your-id 填你在服务器上的 id,服务器的版本库里会有以你的 id 为名称的分支。

pull

将别人推送到服务器的代码,拉到你的机器里

$ git pull

log

查看修改记录,含作者、时间、修改说明等

$ git log

show

显示具体的代码改动情况

显示最后一次 commit 修改的内容:

$ git show

显示指定 commit 修改的内容:

【TIP】git log 命令中,每条 commit 会有一长长的字符串,此即 commid id,取其前面五六位即可。

$ git show commit-id

branch

分支管理

列出所有分支(当前所在分支前会有“*”号):

$ git branch

新建分支:

$ git branch 新分支名

删除分支:

$ git branch -d 欲删除的分支名

【注意!】不要把 ‘-d’ 写成了 ‘-D’,危险!

  • -d:要求:被删除分支的所有修改,已经合并到当前分支;
  • -D:直接删除,未合并的代码,将被丢弃!

checkout

恢复某个已修改的文件(撤销未提交的修改):

$ git checkout file-name

切换到另外的分支,进行开发:

$ git checkout branch-name

【注意!】该命令可能伴随大量的文件增删/修改。Windows 下,改动已被占用的文件可能会被拒绝,导致版本库出现严重问题。如果确实要这样做,安全起见,最好先注销一次。

merge

合并指定分支到当前分支:

$ git merge branch-name

revert

还原已提交的修改(已经提交过的修改,可以反悔~)

还原最近一次提交的修改:

$ git revert HEAD

还原指定版本的修改:

$ git revert commit-id

stash

先将未提交的修改暂存起来,接着清除所有改动,使之与没修改时一样。

若你正在开发功能 A,又需立即去开发功能 B。A 的代码正改到一半,未认真整理,你不想立即提交。此时……请呼叫 stash ~。

它会使你所有未提交的修改瞬间不见了:

$ git stash

它会使刚刚不见了的修改,瞬间又回来了:

$ git stash pop

【TIP】以上命令皆有更多参数,另有一些 Git 命令我们此处没有介绍。但是,这已足令你使用 Git 时游刃有余,你会觉得,Git 简直是一件神器!:-)

【TIP】’$ git help’ 与 ‘$ git help 命令名’ 会在你需要的时候,无私地帮助你。:-)

附:git push 失败的解决办法

假设执行操作:

1. 修改代码
2. git commit
3. git push

此时 push 失败(错误提示:! [rejected] master -> master (non-fast-forward) )

解决办法:

$ git pull

若成功,则:

$ git push origin master:your-id

完事。

若失败(提示:CONFLICT (content): Merge conflict in 文件名),则:

冲突的文件会有类似下面的代码块:

<<<<HEAD
你修改的代码
============
其他人修改的代码
>>>>>commit id of others'

考虑你和他人对代码的修改,更新成合适的内容,并删除 <<<、===、>>> 3行标记符号,保存文件。

$ git commit -am "resolve conflict"
$ git push origin master:your-id

更详细的说明,可以阅读 $git push –help 该文档的 NOTE ABOUT FAST-FORWARDS 一节。

Git 系列之三:Windows 下 Git 配置与使用指南

一、安装

默认安装:msysGit

二、配置

1、C:\Program Files\Git\etc\gitconfig 添加:
【注意!】请将第二行最后的 “your-id” 修改成你在服务器上的实际 id,默认是姓名拼音。

[alias]
    go = "! bash -c \"git pull && git add .; if [ \\\"$*\\\" == \\\"\\\" ]; then git commit -a; else git commit -am \\\"$*\\\"; fi; git push origin master:your-id;\""
[core]
    autocrlf = false
[gui]
    encoding = utf-8
[i18n]
    commitencoding = GB2312
[user]
    email = xxx@gmail.com
    name = 某某某

2、C:\Program Files\Git\etc\inputrc 修改两行为:

set output-meta on
set convert-meta off

3、C:\Program Files\Git\etc\git-completion.bash 末尾增加:

alias ls='ls --show-control-chars --color=auto'

4、C:\Program Files\Git\etc\profile 末尾增加:

export LESSCHARSET=utf-8

【TIP】以上文件最好使用支持 unix 格式的编辑器修改(如 Notepad++、NetBeans),最次也用“写字板”而非“记事本”。

【TIP】若想了解为什么这样设置,请参见:Windows 下 Git 客户端的选择,及 msysGit 各种中文问题的解决

三、生成密钥

安装完后,需要生成一对 Key(这里指密钥),然后才能通过加密的方式和服务器的代码库取得同步。

到开始菜单,找到“Git Bash”,运行之,并执行以下命令:

$ ssh-keygen -t rsa

程序会提示您输入密钥的文件名,直接按回车即可。
然后会要求你输入一个密码,将来在使用密钥的时候需要提供这个密码。可以输入,也可以不输入直接回车(无论输入还是不输入,都会要求你确认一次)。
确认完毕后,程序将生成一对密钥存放在以下文件夹:

C:\Users\Administrator[这里替换成你的用户名]\.ssh

密钥分成两个文件,一个私钥(id_rsa)、一个公钥(id_rsa.pub)。
私钥保存在您的电脑上,公钥交项目负责人添加到服务器上。用户必须拥有与服务器公钥所配对的私钥,才能访问服务器上的代码库。

【注意!】为了项目代码的安全,请妥善保管你的私钥!因为一旦私钥外泄,将可能导致服务器上的代码被泄漏!

四、使用

1、克隆代码库

使用 Windows 资源管理器,打开你打算存放项目代码的文件夹,点右键选择 Git Bash。

在我们的项目管理系统中,每个项目的首页,都有写明代码克隆的地址,比如我们用于测试目的的沙盒项目:

$ git clone your-name@testing.aysaas.com:/var/projects/sandbox

在 Git Bash 中运行这条命令就能将沙盒项目中的所有代码(其实只是几个随便测试的文件)克隆到本地。

接着您就可以打开习惯的 IDE(如 NetBeans),投入到项目的开发中啦~!

【TIP】上面命令中的 your-name 要改成你在服务器上实际的用户名。

2、查看修改差异

开发过程中,如果你想了解修改了哪些代码,总览所有代码的改动情况,可以在 Git Bash 中输入此命令:

$ git diff

【TIP】Git Bash diff 的时候有两个缺点:一、窗口太窄,可能显示不下整行的代码;二、如果代码中有中文,会乱码。如果你碰到这两个问题,可以在项目文件夹下点右键,选择 Git Gui。

3、提交修改

每当完成一个阶段的代码,就需要提交代码以记录进展,方便日后查找问题以及团队协作。

$ git go aaa 修改说明(改动了什么?为什么这样改?)

【TIP】别忘了 go 后面的 aaa,关于 ‘git go’ 命令的详细说明,请参见 Windows 下 Git 客户端的选择,及 msysGit 各种中文问题的解决

【TIP】请尽量养成勤提交的好习惯。当代码不幸出现问题时,比较容易找出从什么时刻开始出现问题,并回退到该时刻进行调试,最大限度保护已完成的阶段性工作。

【TIP】以上命令,都需要在项目目录下运行。Git Bash 在命令提示符前,会显示当前所在的目录。如果当前不在项目目录之下,需要用 cd 命令切换到项目所在目录。
简单的办法,就是先在资源管理器里打开项目文件夹,再点右键,选择 Git Bash。

五、总结

至此,从获取代码、查看差异、到提交代码,整个流程都熟悉了。Git 还有比较高级的技巧,大家可以参考 Git 进阶功能 或在线找进一步的资料学习。

Git 系列之二:Windows 下 Git 客户端的选择,及 msysGit 各种中文问题的解决

在 Windows 下用 NetBeans 做 PHP 开发,首先想到的是 NetBeans 的插件:NBGit。
评价:能用;若需没有的功能,可以自定义菜单调用自定义 bat 脚本;开发不活跃,使用没有信心。

第二个则是:TortoiseGit,SVN 小乌龟的 Git 版本。
评价:该有的功能基本都有了,还是不错的。

另外,TortoiseGit 只是 GUI 工具,使用它需要先安装 msysGit,这是正宗的 Git 之 Windows 版本。msysGit 有个简单的 GUI 工具,及简单的 Explorer 集成;但它自带的 Bash 非常好用,深得 Linux 的真传。

选择:msysGit。
理由:
NBGit 不用说,功能都不完善,还需要自己定制 bat 脚本(若此,则它同样要依赖 msysGit);开发不活跃,很可能 NetBeans 下个版本更新就不能用了;况且,我们还有别的项目,不使用 NetBeans。

TortoiseGit 从功能上说是完善的,但它只是功能的堆砌而已,使用时完全体会不到 GUI 带来的便利。相反,它让人感觉很繁琐,一个劲地点鼠标,点来点去全是跟菜单打交道,远离了 Git 命令、远离了 Git 输出提示、远离了真相。

msysGit 的 Bash 非常好用;加上 Git 强大的 alias 功能,我们完全可以自定义一个 $ git go,使得 90% 的情况下只需要这一个命令,即使是不熟悉命令行的 Windows 用户也会觉得很好玩;因为 NBGit、TortoiseGit 都需要 msysGit 做底层,我们直接用底层工具也避免了上层 GUI 带来的额外的 bug。

需要的配置:

1、C:\Program Files\Git\etc\git-completion.bash:

alias ls='ls --show-control-chars --color=auto'

说明:使得在 Git Bash 中输入 ls 命令,可以正常显示中文文件名

2、C:\Program Files\Git\etc\inputrc:

set output-meta on
set convert-meta off

说明:使得在 Git Bash 中可以正常输入中文,比如中文的 commit log。

3、C:\Program Files\Git\etc\profile:

export LESSCHARSET=utf-8

说明:$ git log 命令不像其它 vcs 一样,n 条 log 从头滚到底,它会恰当地停在第一页,按 space 键再往后翻页。这是通过将 log 送给 less 处理实现的。以上即是设置 less 的字符编码,使得 $ git log 可以正常显示中文。其实,它的值不一定要设置为 utf-8,比如 latin1 也可以……。还有个办法是 $ git –no-pager log,在选项里禁止分页,则无需设置上面的选项。

4、C:\Program Files\Git\etc\gitconfig:
[alias]
go =
“! bash -c \”git pull && git add .; if [ \\\”$*\\\” == \\\”\\\” ]; then git commit -a; else git commit -am \\\”$*\\\”; fi; git push origin master:your-id;\””

说明:强大的 alias,有了这个,我们 90% 的情况下只需要输入 $ git go 这一个命令,免去了先拉后提交再推的繁琐步骤。

两种用法:
$ git go

$ git go aaa 修订说明

命令后带修订说明时,会直接提交。需要注意的是,在“修订说明”之前,有还个“aaa”,这是个 bug,参数中的第一个会被忽略,所以随便写一个凑数的……。

若命令行里没有提供修订说明,则会自动弹出一个编辑器,等待输入。默认的编辑器是 Vim。Vim 的使用是很简单的,首先要明白它有两个模式,一个是命令模式、一个是输入模式。Vim 启动的时候默认的是命令模式,需要先按’i’键,进入输入模式;然后就正常编辑;编辑完成之后,将输入法切换回英文状态,按 Esc 重新进入命令模式;此时按 ‘(Shift):wq‘ 并回车,w 表示写入保存、q 表示退出。完毕!

若实在不习惯 Vim,也可以设置为其它编辑器:

$ git config --global core.editor "notepad"

其中 notepad 可以替换为更好用的 wordpad、notepad++ 等(不过它们在命令行里无法直接访问,得先设置 PATH 变量)。

以上 alias 是为 Windows 定制的,Linux 下可以写得更优雅,不过鉴于使用上没分别,就保持一致吧~。

[gui]
encoding = utf-8

说明:我们的代码库是统一用的 utf-8,这样设置可以在 git gui 中正常显示代码中的中文。

[i18n]
commitencoding = GB2312

说明:如果没有这一条,虽然我们在本地用 $ git log 看自己的中文修订没问题,但,一、我们的 log 推到服务器后会变成乱码;二、别人在 Linux 下推的中文 log 我们 pull 过来之后看起来也是乱码。这是因为,我们的 commit log 会被先存放在项目的 .git/COMMIT_EDITMSG 文件中;在中文 Windows 里,新建文件用的是 GB2312 的编码;但是 Git 不知道,当成默认的 utf-8 的送出去了,所以就乱码了。有了这条之后,Git 会先将其转换成 utf-8,再发出去,于是就没问题了。

以上,给 Windows 下的同事在 Git Bash 里推代码就比较完美了。不过仍然有 3 个问题:

1、上面的 alias $ git go 有 bug,代码修订说明之前要输入一串字符凑数;

2、$ git diff,如果代码里有中文,会显示乱码;

3、$ git checkout 有时候需要修改/增删很多文件,如果某些文件被占用,会被 Windows 拒绝,导致失败,甚至可能造成版本库出现无法修复的问题。

这 3 个都是可承受的问题,前两个应该有办法解决;第 3 个归功于文件系统,只能尽量避免 checkout,实在需要的时候先注销一次,就不会有问题了。

【TIP】该文只是解释说明,具体操作请按《Windows 下 git 配置与使用指南》Wiki 执行。

Git 系列之一:版本控制的概念、分布式、Git 简介及其工作流程

UPDATE:这里记录的“Git 工作流程”比较适合于团队大部分人没有使用过 Git 的情况,能够简单无障碍入门;以及,适合于系统比较大,不同的人工作于不同的部分,彼此进度不一的情况。日志写作时,我们正好符合这两个情况,所以采用了所述的流程。随着时间的推移,团队成员使用 Git 已经比较熟练,而我们系统的开发也逐渐成熟,现已转用了另一种流程。大体而言,跟这个思路比较接近:http://nvie.com/posts/a-successful-git-branching-model/ 。

——

注:

Git 的强大、灵活、好用,毋庸置疑。

但也正是 Git 的灵活性,在公司推行时,如何执行统一的流程成为一个问题。我想了不少时间才制订出一个办法。

目的是规范、统一。还有就是,Windows 下的同事,特别是不熟悉命令行的同事,怎样才能使他们好理解,并且觉得简单(之前大家觉得概念太多,难以理解;步骤多,记不住,不小心就搞错,冲突频发)。

说到 Windows,Git 在 Windows 下不如 Linux 下好使,这也是一个需要考虑的问题。

同样是在公司 Wiki 上写的,再次拿到 Blog 来凑数呵呵~。

版本控制

——————
简单地说,就是将在本地开发的代码,定时推送到服务器。每一次修改,记录下它的作者、时间及修改说明等。

相对的,我们也可以从服务器下拉其他人推送的代码,并了解它的作者、时间、修改说明及其具体的修改内容。

这样,版本控制给团队协作开发提供了极大的方便。即使是一个人开发,因为它记录下了我们整个的开发历史,也是极有帮助和价值的。

比如,如果某次修改甚至整个系统出现问题,它也能帮助找回我们珍贵的代码。

分布式版本控制

——————————–
更进一步,分布式版本控制工具使得我们在本机上即拥有完整的功能,不依赖于服务器,使用更为方便。它们往往也提供其它更好用或更强大的功能,比如灵活的分支管理。

Git

——–
Git 是 Linux 之父 Linus Trovalds,为管理 Linux 内核代码而建立的,被认为是分布式版本控制工具中的顶级水准。智能、友好、强健、高效。

Git 工作流程

—————————-
1、使用中央服务器辅助协作;

2、每人在服务器拥有一个以自己 id 为名称的分支;

3、各人只许推送更新到自己的分支,不允许推送到别人的分支或者 master;

4、master 由专人管理,在合适时 merge 其它分支(开发初期每日自动 merge 各人分支,生产化后则由人工 merge 经过 review 的分支);

5、代码修改 merge 到 master 后,将同步到所有终端。

【TIP】:熟悉之后,你可以创建类似 myId_branchName 的其它分支。

【TIP】:以上只是概念介绍,至于具体的操作,请参考:《Windows 下 Git 配置与使用指南》《Git 进阶功能》