自己自从使用上Git就对开源项目产生了兴趣，并在Git上尝试提交了2个傻瓜即patch。在提交patch的时候感受到了强烈的不足，一方面是不能用英语和人做深入交流，一个patch要提交几次来说明问题；另一方面也很难有能力系统对整个项目代码进行学习，只能寻找类似于编译警告、显示大小这样的皮毛。 成熟的开源项目的背后都是有“专注”的人在支持，而我这样的情况是奔于生计很难做的专注。“不专注”，主要是两个方面，一是不能有足够的时间进行相应的思考和尝试，二是心境也不能够排除其他事情的干扰，比如家庭琐事。“不专注”会让自己不能够集中精力处理问题，而在经受困难是或繁琐的尝试面前，难免心存懈怠。 参与比较困难，结论是什么呢？没有结论，只有选项。一个选项就是，持续提升自身的英语与编程能力来让“不专注”的范围变小，来使自身通过这些活动能够有所提升。 什么是开源项目？现在的看法就是：一个能够成为自身提升的平台。

软件开发的初期，主要的问题在于需要变化的东西太多了；以至于提交的时候有时就是为了“阶段备份”而并没有什么实质的完成。在这种情况下，对于怎样写commit信息的问题让我比较疑惑，因为有的提交并不是完整修改；经过尝试我还是找出了一种简单的方法。 方法的过程如下： 1）只添加一个.gitignore文件的来做第一次提交，commit log可以是“Initialize repository”。 2）创建一个开发分支devel来在上面进行开发，随意提交commit log可以类似”r0″、“r1”这样的简单序号。 3）当devel完成一定功能时，可以使用reset到主分支的节点，完成一次带完整commit log的提交，并合并到master分支。 4）未完成项目，则重复第2）步。 如果devel分支需要提交到远程库上，就在devel分支下直接push好了（会在远程库上同样创建devel分支）。 Git操作样例: 1) 创建库 mkdir softdev && cd softdev git init touch .gitignore git add . git commit -a -m “Initialize repository” 2)进行开发 git checkout -b devel …..开发…. git add . (根据需要编辑.gitignore来过滤不需要的文件爱你) git commit -a -m “r0″ …..开发到 r9 时完成基本框架….. git reset master git add [...]

1.使用msysgit msysgit是通过MingGW编译的git版本（http://code.google.com/p/msysgit/），包含基本的类Linux环境，比如bash、vi、tar、gzip、msmtp。此外其提供的gitk、git-gui两个图像化工具使使用更加方便，根据实际需要还包含了git-svn来迎合SVN的支持者。 虽然其版本更新并没有紧随git-scm.com中的版本，但其可用性也是非常高。msysgit不包含git-daemon,git- cvsserver等作为代码仓库的功能，所以在两个coder之间传输代码会比较麻烦，比如用U盘拷贝。 2.使用TortoiseGit TortoiseGit是使用TortoiseSVN源代码进行改写的Git图形化工具，适合不习惯命令行的用户使用。其上的菜单完成了绝大部分git常用功能，但我个人感觉其使用上不如“命令行+gitk+git-gui”使用起来方便。 3.VS、Eclipse插件 这是一个哲学问题了，如果使用TortoiseGit就没有必要使用适合开发工具的插件，而TortoiseGit又不如直接使用msysgit方便，那么使用插件就没有意义了^_^。 实际上只要设置好“.gitignore”文件，就可以方便过滤掉开发工具所产生出的临时文件，比如*.obj,*.class，而插件最大的功能就在于此；此外由于开发工具自身的限制也会让插件失去msysgit部分特征，得不偿失。 4.管理大型项目 这里的大型项目，并不是Linux Kernel这样的单工程项目，而是指包含多工程构成的项目。这里有两种方式，第一种是项目使用一个库（包含所有工程），第二种是每个项目一个库。 第一种方式，适合所有代码都是公开的不存在代码保密性的项目。这样tag与branch都是应用在整个项目上的，是Git推荐的方式。 第二种方式，适合需要部分代码进行保密（比如分用户权限）的项目。这样会有一些额外的工作要做，比如tag与branch是每个工程独立控制的，同时为了构建“可开发”环境需要手工构建出一个支持环境（比如，其他项目生成的库、DLL的存放）。 以上两种方式都有比较好的特征，第一种“完整”、第二种“灵活”。 5.迎合SVN的支持者 许多公司的代码都从CVS转入SVN进行管理，并且他们对于这种可以随意设定权限、代码集中存储方式已经很是熟悉，并且对SVN的问题也能够继续忍受下去了。在这样的情况，一个Git的支持者就可以很好的使用git-svn来享受Git的方便。 git-svn内置了svn的运行库，只需要设置git环境就可以有效使用，除了通过”git svn rebase”、”git svn dcommit”两个命令与SVN库同步外，根本就感觉不到SVN的存在。Git有效的避免了SVN在使用中的不便，而git-svn又兼顾了SVN的已有环境，对于SVN支持者来说，我感觉这是一种非常完美的搭配。