最近在给考拉山后台添砖加瓦的过程中，发现了两个问题：
这种混乱的场景已经快让我不能忍了，于是乎决定把这个大仓库中的所有business和model的代码独立到一个submodule中，这样接下来就可以进一步的拆分各个view让它们都引用这个submodule。
还好之前的代码结构还算比较好，所有business和model的代码都在一个名为coloshine的目录中，所以接下来只要解决如何把一个子目录独立成一个submodule并且保存分支和提交历史这个问题就好了。
继续阅读 »
1.我们在服务器上直接git clone项目的版本库的时候报401错误！
错误如下：error: The requested URL returned error: 401 Unauthorized while accessing
原因：git 版本过低
2.git –version 查看一下当前的git版本
因为centos yum 安装的git是 1.7.1
所以我们要升级git的版本
3.如何升级git
更新yum: sudo yum update
安装依赖包：sudo yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker
下载git:wget https://github.com/git/git/archive/v2.3.0.zip
解压然后进入到目录下
安装：make prefix=/usr/local/git all
sudo make prefix=/usr/local/git install
4.再执行下git –version看git版本是否升级
如果还是1.7.1 需要修改环境变量
sudo vim /etc/profile
在文件的最后加入：export PATH=/usr/local/git/bin:$PATH
source /etc/profile：应用修改
git –version 切换到了2.3.0
这样git的命令就可以正常使用了！
Pull Requests是Bitbucket上方便开发者之间协作的功能。提供了一个用户友好的Web界面，在集成提交的变更到正式项目前可以对变更进行讨论。
继续阅读 »
Forking工作流和前面讨论的几种工作流有根本的不同。这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有2个Git仓库而不是1个：一个本地私有的，另一个服务端公开的。
继续阅读 »
工作流其实不是一个初级主题，背后的本质问题其实是有效的项目流程管理和高效的开发协同约定，不仅是Git或SVN等SCM工具的使用。
这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点，循序渐进地演进到其它高效的分布式工作流，还介绍了如何配合使用便利的Pull Request功能，体系地讲解了各种工作流的应用。
行文中实践原则和操作示例并重，对于Git的资深玩家可以梳理思考提升，而新接触的同学，也可以跟着step-by-step操作来操练学习并在实际工作中上手使用。
关于Git工作流主题，网上体系的中文资料不多，主要是零散的操作说明，希望这篇文章能让你更深入理解并在工作中灵活有效地使用起来。
继续阅读 »
之前写了篇文章介绍使用脚本生成SVN、GIT版本号的SVN、GIT生成版本号，获取SVN版本号的方法有些不恰当，在不同版本的SVN上会出现问题。这里再对此进行完善。
之前的脚本是通过下面的命令获取当前的SVN的提交版本号：
|
1 |
LOCALVER=`svn info | cat -n | awk '{if($1==5)print $3}'` |
示例可以参考前面写的文章，意思是获取第5行第3列的数字，这个数字就是提交代码的SVN号。关键的问题是，不同版本的SVN是不是都是第5行是版本号？非也。不同版本是不同的。所以上面的命令就有局限性。我尝试搜索相关资料，但没找到好的方法。于是只好继续沿用上面的方法。但多了对不同的SVN版本作判断。
下面给出结合了SVN、GIT两种版本号生成脚本。脚本中会判断是否存在.git或.svn目录，如果都存在，则将两个版本号写到一起，如只存在其中一个，则生成对应的版本号。
继续阅读 »
近期评论