眼看就要到春节假期了，公司E-HR平台上我的账户下还有一项待处理的工作：填写一份"领导力发展回顾与提升计划"表格。表格很简单，5分钟就能填完，不过其中有一项我自己很难填写："您了解或感知同事/或下属对您的期望"。虽说可以自我感知，不过我更想听到我的同事真实的声音。 于是乎我就在产品线内发出了一封Mail，希望能够得到大家真实的想法。

小半天，我就收到同事的十几封反馈Mail，多数Mail中大家都提出了对我的期望以及对研发线的期望；另外在很多同事的Mail中还包括了对我个人以及工作的肯定，这让我十分感动，我相信大家的反馈是发自内心的。

将同事们的期望总结一下，大致有以下几点：
1、继续在研发线内引入和推广业内的优秀实践，扩大团队视野，提升团队能力；
2、将已经采用的实践继续扎实的做下去，做深做精；
3、分配工作时尽量兼顾同事们的个人期望；
4、产品线内各项目间平衡投入；
5、给予下属同事更多关于高效工作方法和提高解决问题能力上的指导；
6、提供更多的同事间相互交流的渠道或者平台；
7、多多组织业余团队活动，这是很多同事共同的期望。

两天前曾与我的直接领导面谈了一次，谈了很多，包括新职位要求、部门对我的期望、改善团队关系等等，后来又开始发散，说到个人性格、适宜的职涯发展路线等。其实这两年随着年龄的增大，经验阅历的丰富，我也逐渐开始了认真地自我认知（以前有些随波逐流），渐渐地知道了自己需要什么、想要得到什么、反感什么以及不愿去做什么。做事开始有了倾向性，好恶分明，做喜欢做的事儿，而对那些不喜欢的事情不屑一顾。

我从来都不认为自己是一个外向的人，不过在我喜欢事情上我却是外向的、健谈的甚至是热烈奔放的，说起话来是滔滔不绝的；另外我个人做事比较低调內敛，属于实干型，估计大多技术出身的人都具有同样品质；这几年的历练让我逐渐培养起了大局观，处事冷静沉稳，思路清晰；另外做任何事情都追求高标准，不仅要有好的结果，还要有好的过程。自认为是一个完美主义者，甚至有些偏执；擅于思考，追求高效；强烈的自我驱动；追求简单的人与人之间的关系。

当将近而立之年时，多数人会进入一个人的认知动荡期，他会重新思考自己的人生观、价值观和世界观，思考人生，找出好恶，做出一些改变，做出一些选择，甚至是主动做出一些放弃。也许通过了这个阶段，你的人生之路就会变得更加笔直和清晰。

有了孩子后，我更多的是挤出时间来做自己工作之外想做的事情，辛苦，却有意义，有成就感。不是有那么一句话么：风烛残年时，当你回忆起往事，让你后悔的不是那些你曾做过的事情，而多数是那些你当时没敢于去做的事情。

要敢于去做，并把事情做好！

2011年，我将继续在技术的深度和广度上齐头并进。而在做人方面，多些包容，少些苛刻。

部门一直使用Subversion作为源码版本的管理工具。说实话，Subversion比较适合目前部门的绝大多数项目：没有异地团队开发，代码中心化管理；基本上都在trunk上开发，较少使用分支，基本上没有在各个branch间切换的成本。但对于我来说，有些情况下Subversion并不能满足我的需求。

问题主要集中在本地代码的备份和版本管理上。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说，存在着被误删除和版本更新无法回退两大杯具情形。而对于这些情况，Subversion工具是无能为力的。

这时我们就需要借助其它工具来帮我们解决问题。Git就是这样一款很给力的工具，它是一款分布式版本管理工具，由linux的缔造者Linus Torvalds设计并实现，具体关于Git的介绍和使用方法可参见其官方站。这里要说的是Git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。

支持去中心化，是Git与生俱来的特性，它在本地保留了从中心服务器clone出来的源码库的全部信息，这样，你在本地修改完代码后便可以直接提交到本地的代码版本库中。本地代码的备份和版本管理的问题就这样被Git轻而一举的就解决了。而本地源码库与SVN中心源码库的同步操作则是由Git提供的git-svn工具来完成的。

git-svn默认包含在Git的安装包中，不过在Ubuntu中，git-svn是作为一个独立的Package需要额外安装的(sudo apt-get install git-svn)。安装后你就可以使用git svn xxx命令来操作中心SVN代码库了。当然如果你要使用与git svn等价的git-svn命令的话，你还需要将/usr/lib/git-core配置到你的PATH环境变量中，否则Shell会提示你无法找到git-svn这个命令。

* 检出一个已存在svn repository(类似于svn checkout)
我们可以通过git-svn clone命令完成这个操作： git-svn clone your_svn_repository_url

* 从中心服务器的svn repository获取最新更新
这个操作可以通过"git-svn rebase"完成。注意这里用的是rebase，而不是update。update命令对于通过git-svn检出的svn repostory的git版本库是不可用的。

* 查看提交历史日志
这个简单，使用"git-svn log"，加上-v选项，还可以提供每次commit操作涉及的相关文件的详细信息。

* 将本地代码同步到Svn服务器
完成这一操作需要通过"git-svn dcommit"命令。这个命令会将你在本地使用git commit提交到本地代码库的所有更改逐一提交到svn库中。加上-n选项，则该命令不会真正执行commit到svn的操作，而是会显示会有哪些本地变动将被commit到svn服务器。git-svn dcommit似乎不能单独提交某个本地版本的修改，而是一次批量提交所有与svn中心版本库的差异。

下面是一个git-svn的一般使用流程：
1、git-svn clone your_svn_repository；
2、修改本地代码，使用git add/commit将修改提交到本地git库；
3、定期使用git-svn rebase获取中心svn repository的更新；
4、使用git-svn dcommit命令将本地git库的修改同步到中心svn库。

使用git-svn处理代码冲突的步骤有些繁琐，不过瑕不掩瑜吧。这里用一个小例子来说明一下。

假设某svn中心库上的某个项目foo中只有一个源码文件foo.c：
* 我在使用git-svn clone检出版本时，foo.c当时只有一个commit版本信息："svn v1"；
* clone出来后，我在本地git库中修改foo.c，并通过git commit提交到本地git库中，版本为"git v1"；
* 不过与此同时另外一个同事也在修改foo.c这个文件，并已经将他的修改提交到了svn库中，版本为"svn v2"；
* 此时我使用git-svn dcommit尝试提交我的改动，git-svn提示我：
  Committing to svn://10.10.1.1:80/foo …
  M foo.c
  事务过时: 过期: ”foo/foo.c“在事务“260-1” at /usr/lib/git-core/git-svn line 570
* 使用git-svn rebase获取svn服务器上的最新foo.c，导致与foo.c冲突，不过此时svn版本信息已经添加到本地git库中(通过git log可以查看)，git-svn rebase提示你在解决foo.c的冲突后，运行git rebase –continue完成rebase操作；
* 打开foo.c，修改代码，解决冲突；
* 执行git rebase –continue，git提示我：
    You must edit all merge conflicts and then
    mark them as resolved using git add
* 执行git add foo.c，告知git已完成冲突解决；
* 再次执行git rebase –continue，提示"Applying: git v1"，此时"git v1"版本又一次成功加入本地版本库，你可通过git log查看；
* 执行git-svn dcommit将foo.c的改动同步到svn中心库，到此算是完成一次冲突解决。