1.源代码管理工具的作用
无法后悔:做错了一个操作后,没有后悔药可以吃
版本备份:费空间、费时间
版本混乱:因版本备份过多造成混乱,难于找回正确的想要的版本
代码冲突:多人操作同一个文件(团队开发中的常见问题)
权限控制:无法对源代码进行精确的权限控制
追究责任:出现了严重的BUG,无法得知是谁干的,容易耍赖
… …
源代码管理工具就是为了解决上述问题而生的!
源代码管理工具的作用:
能追踪一个项目从诞生一直到定案的过程
记录一个项目的所有内容变化
方便地查阅特定版本的修订情况
… …
2.常见的源代码管理工具
CVS
开启版本控制之门
1990年诞生,“远古时代”的主流源代码管理工具
开源、免费的集中式版本控制工具
自身设计有问题,会造成提交文件不完整,版本库莫名其妙损坏的情况
SVN Subversion
集中式版本控制之王者
是CVS的接班人,速度比CVS快,功能比CVS多且强大,修正了CVS的一些稳定性问题
在国内软件企业中使用最为普遍(70%~90%)
ClearCase
收费的集中式版本控制工具,安装比Windows还大,运行比蜗牛还慢
能用ClearCase的一般是世界500强,他们有个共同的特点是财大气粗或者人傻钱多
GIT
分布式源代码管理工具
目前被越来越多的开源项目使用
不过在国内企业尚未大范围普及
3.集中式&分布式版本控制
分布式和集中式的最大区别在于:
在分布式下1.开发者可以本地提交2.每个开发者机器上都有一个服务器的数据库3.拥有一个本地的代码仓库
4.GIT
一款开源的分布式版本控制工具
在世界上所有的分布式版本控制工具中,git是最快、最简单、最流行的
作者是Linux之父:Linus Benedict Torvalds
当初开发git仅仅是为了辅助Linux内核的开发(管理源代码)
在国外已经非常普及,国内并未普及(在慢慢普及)
越来越多的开源项目已经转移到git
4.1Mac上git工具
在Mac上,比较好用的git图形界面客户端有
SourceTree http://www.sourcetreeapp.com/download/
GitHub https://mac.github.com
不过它是专门为GitHub网站而设计的
Xcode
4.2git常用指令
git help : git指令帮助手册
git help : 其他指令 查看其他指令的做法
git config : git的配置信息相关(修改的是.git/config文件)
git config "user.name" 用户名 :(用于跟踪修改记录)配置用户名
git config "user.email" 邮箱 :(用于多人开发间的沟通)配置邮箱
git config –l : 查看配置信息
git config –e :(用vim编辑,:wq是退出vim编辑器)编辑配置信息
git config alias.别名 原指令名称 : 设置指令的别名
git config alias.别名 "原指令名称 参数" : 设置带参数指令的别名
git config ––gloabal : 将此设置应用到整个系统中
git status 文件名 : 查看某个文件的状态
git status : 查看当前路径所有文件的状态
git log 文件名 : 查看某个文件的修改日志
git log : 查看当前路径所有文件的修改日志
git log --pretty=oneline : 用一行的方式查看简单的日志信息
git log –N(N是一个整数): 查看最近的N次修改
git diff 文件名 : 查看某个文件的最新改动的地方
git diff : 查看当前路径所有文件最新改动的地方
git init : 在当前路径初始化仓库,初始化一个空的本地仓库,生成一个.git目录,用于维护版本信息
git init 仓库路径 : 在其他路径初始化仓库
git add : 将工作区的文件保存到暂缓区
git add 文件名 : 保存某个文件到暂缓区
git add . : 保存当前路径的所有文件到暂缓区 (注意,最后是一个点 . )
git commit -m "注释" 文件名 : 提交某个文件到分支
git commit -m "注释" : 保存当前路径的所有文件到分支
git reset : 版本回退(建议加上––hard参数,git支持无限次后悔)
git reset ––hard HEAD^ : 回退到上一个版本
git reset ––hard HEAD^^ : 回退到上上一个版本
git reset ––hard HEAD~N : 回退到上N个版本(N是一个整数)
git reset ––hard 版本号 : 回退到任意一个版本(版本号用7位即可)
git reflog : 查看指令使用记录(能够查看所有的版本号)
git rm : 删除文件(删完之后要进行commit操作,才能同步到版本库)
git clone 仓库的URL : 下载远程仓库到本地当前路径
git clone 仓库的URL 存放仓库的路径 : 下载远程仓库到本地特定路径
git pull : 下载远程仓库的最新信息到本地仓库
git push : 将本地的仓库信息推送到远程仓库
4.3git工作原理
核心概念:
工作区(Working Directory)
:仓库文件夹里除.git目录以外的内容
版本库(Repository)
:.git目录,用于存储记录版本信息
暂缓区(stage)
分支(master)
:git自动创建的第一个分支
HEAD指针
:用于指向当前分支
git add
:把文件修改添加到暂存区
git commit
:把暂存区的所有内容提交到当前分支
4.4远程仓库
搭建远程仓库的途径
自己搭建一个git服务器:费时费力
在GitHub
上托管项目:公开项目免费、私有项目收费,很多第三方开源项目
在oschina
上托管项目:完全免费,在国内访问速度快(推荐使用)
5.SVN
.svn这个隐藏目录记录着非常关键的信息
千万不要手工修改或删除这个 .svn隐藏目录和里面的文件!
否则将会导致本地的工作副本被破坏,无法再进行操作
要想利用SVN管理源代码,必须得有2套环境
服务器
用于存储客户端上传的源代码
大部分情况下,公司的开发人员不必亲自搭建SVN服务器
客户端
上传本地的源代码到服务器,或者更新服务器的代码到本地,保持同步
可以在Mac上使用命令行、Versions、Cornerstone、Xcode
开发人员就属于客户端这个角色
SVN客户端命令
svn checkout :下载服务器的代码到本地 (简写svn co)
svn commit :将改动的文件提交到服务器(简写svn ci)
svn update :更新服务器的代码到本地 (简写svn up)
svn add :向本地的版本控制库中添加新文件
svn delete、svn remove :从本地的版本控制库中删除文件(简写svn del、svn rm)
svn move :移动文件或者目录或文件更名
svn mkdir :创建纳入版本控制下的新目录
svn revert :撤销之前的一切修改
svn merge :将两个版本之间的差异合并到当前文件
svn info :查看文件的详细信息
svn diff :查看不同版本的区别
svn log :查看日志信息
svn list :列出版本库下的文件和目录列表
svn status :查看文件状态(简写svn st)
svn help :获取帮助信息(比如svn help ci)
svn lock :加锁
svn unlock :解锁
svn checkout URL [PATH] : 将项目检出(下载) 至本地
svn co URL [PATH] : 这里的中括号[ ]代表可选(可以省略)
svn checkout https://192.168.1.106/svn/Weibo/ /Users/Documents/workspace
//代码仓库的远程地址 --> 将代码下载到本地的哪个路径如果省略路径,就下载到命令行当前所在的路径
svn commit -m "注释" [PATH] : 将改动过的文件提交至服务器
svn ci -m "注释" [PATH] : 一定要养成写注释的良好习惯
svn commit -m "修改了User.m文件" /Users/Desktop/workspace/Weibo/branches/User.m
//提交哪个文件到服务器,如果省略路径就将命令行所在路径中所有改动过的文件提交到服务器
提交一个新建的文件到服务器,需要2个步骤
svn add : 添加新建的文件到本地的版本控制库中
svn commit : 提交刚才的添加操作到服务器
svn add PATH : 向本地的版本控制库中添加一个新文件
svn add /Users/Desktop/workspace/Weibo/branches/User.m
//添加哪个文件到版本控制库中
//如果直接提交一个没有添加到本地版本控制库中的文件,会报下面的错误
is not a working copy
删除服务器上的某个文件,需要做2个步骤
svn delete 、svn remove : 将文件从本地的版本控制库中移除
svn commit : 提交刚才的删除操作到服务器
svn delete PATH : 将文件从本地的版本控制库中移除
svn delete /Users/Desktop/workspace/Weibo/branches/User.m
//将哪个文件从版本控制库中移除
svn update [PATH] : 将服务器的最新代码更新到本地
svn update /Users/solozyx/Desktop/workspace/Weibo/branches/User.m
// 更新哪个文件的内容,如果省略路径就更新命令行所在路径的所有内容
svn update -r 版本号 [PATH] : 将文件恢复至某个版本
svn checkout : 下载项目代码到电脑上
svn commit : 修改了某个早已存在的旧文件,然后提交到服务器
svn add --> svn commit : 提交一个自己新建的文件到服务器
svn delete --> svn commit : 删除一个早已存在的旧文件,然后同步到服务器上
svn update : 将其他同事提交的新代码更新到自己电脑上
svn revert : 不小心写错了很多东西,想撤销所写的东西(还未把修改提交到服务器)
svn revert : 不小心删错了文件,想把文件恢复回来(还未把删除提交到服务器)
svn update -r 版本号 : 不小心写错了很多东西,想撤销所写的东西(已经把修改提交到服务器)
svn update -r 版本号 : 不小心删错了文件,想把文件恢复回来(已经把删除提交到服务器)
正规项目的SVN目录结构一般有3个文件夹
trunk
:主干,当前开发项目的主目录
branches
:分支目录,添加非主线功能时使用,开发测试之后,可以合并到主干项目中
tags
:标记目录,通常作为重大版本的备份
某团队计划开发一款”XXX”项目
此项目初期已经有部分基础代码
研发团队在此基础代码上经过3个月的努力,开发了一个功能相对完备的V1.0版本上线推广,并取得了良好的效果(备份到Tags)
由于市场反馈良好,团队开始着手V2.0版本的开发工作
就在V2.0版本开发进行中,发现V1.0版本中有一个严重的BUG,如果不及时修改,将造成严重的后果
研发团队收到BUG报告后,立刻安排人员对V1.0版本进行修复,但其他研发人员则继续开发V2.0版本的新功能
修复BUG的人员很快就找到问题原因并对问题进行了修复,并且发布了V1.1版本供用户升级,因此没有造成重大损失
BUG修复后,研发人员将修复后的代码整合到研发主线中来,这样就可以保证今后发布的后续版本中不会再出现此问题
就这样,整个团队在大家的共同努力下,有条不紊地进行着……
使用SVN我们应该:
经常更新:降低冲突的可能性
提交前需在本机测试通过:降低将问题代码传到版本库
提交时一定写备注(注释):方便其他员工查看和自己以后回顾
对于不需要提交的文件不要提交到版本库
提示:
每次修改之前最好先更新
每天下班前提交当天运行通过的代码
每天上班第一件事情更新前一天的代码