mercurail和git是一个很自由的版本管理软件,我们随时可以在自己的机器上任意一个目录启用版本管理,不需要任何服务器.但是,当我们需要跟别人协作的时候,应该怎么处理呢.我们可以N个人之间互相乱pull来push去,但是这样的网状结构并不方便管理,非常容易混乱,一般来说,我们会指定一个中央源,大家都把代码push到中央源.我认为它们的远程模式有如下几种:
1.U盘
最常见的情况就是我在家和公司都要使用同一份源代码,于是我就会把中央源定在U盘上,而家里和公司的电脑各有一份本地副本,代码提交到本地,然后push 到U盘上.例如我会在U盘上建立一个sparkle_repo的目录,放少量代码和一些文档用git管理.也有不少人是这样用SVN的,不过经常会遇到盘符变化的问题.
优点是完全不需要网络,缺点也很明显,如果要跟朋友协作的话将会相当麻烦
2.网上邻居共享文件夹
很简单,在本地网络随便找一台机器共享一个完全读写的文件夹,然后把中央源放在上面,适合公司内部的简单使用.
优点是简单,缺点是,别人都能完全读写文件夹,干什么事情都可以了,包括删除整个目录.你当然可以进行权限认证,但是认证通过之后,一样可以做任何事情
3.ssh
功能丰富的ssh对于传送文件当然不在话下(我工作的时候都是用ssh而不是ftp传送文件),最适合有个人ssh主机的情况,例如拥有一个 dreamhost的空间,你只要在ssh帐户下随便开一个目录就能作为中央源,但是如果你要跟朋友协作的话,你还是得告诉他你的ssh帐号,又或者你对机器有足够的控制权可以让两个ssh帐号访问到同一个目录.另外,ssh比网络邻居要好的地方是你可以控制能够通过ssh的指令,这样可以只允许 mercurial/git的指令通过,防止有意或无意的删除目录.
以上三种模式其实原理是一样的,就是通过一个大家都可以读写的目录进行协作.
4.私有协议
mercurial&git都可以启动一个daemon server进行使用,mercurial启动的port是8000,其实是使用http协议的,而经常见到的git://xxxxx就是git的私有协议.由于要启动额外的daemon,你必须对机器有一定的控制权才行,例如你不能在dreamhost这样使用.
5.http模式
git只能通过http进行查看和pull,不能进行push操作,有点像viewcvs那样.这点来说,mercurial就比较厉害了,官方包里面提供了一个hgweb.cgi文件,通过配置这个cgi文件,我们可以在一个apache环境中提供push功能,也就是说我们可以在dreamhost上这样使用mercurial,非常棒(下一篇文章我将介绍怎么在dreamhost使用mercurial)
6.Don’t push to me, I will pull from you
是不是有点像IOC(Don’t call me, I will call you).我阅读到相关资料的时候,看见这样一种模式,简直有如脑袋哐当一声.我们太以中央式版本管理的思路来想分布式版本管理了,认为一定要有一个中央源,然后大家都push数据到中央,而且还要认证什么的.git提出的这种模式,就是没有中央源,但是有中央人,并不是大家push到中央,而是中央从大家那里pull,其他人只要用某种形式,例如共享文件夹,或者http等方法公开你的副本,然后发email什么的通知中央人到你的副本中pull.
例如我sparkle负责整个项目,然后我只从各个模块的主管的源那里pull数据,而各个模块的主管从他的手下coder pull数据(事实上使用git的大型项目都是分成多个级别的),我熟悉模块主管,所以我知道他们是可信的,至于他们的数据从哪里来的我不关心,而他们也对他们的手下coder信任,从他们那里pull数据,如此一级一级下去.这种处理模式,一来不需要认证的部分,二来中央的数据是可控的,就是我负责,而不是多个人push的模式那样,并不一定能确定是否正确,第三点,可以分级.
分享到:
相关推荐
- **分布式版本控制系统**:如`Git`、`Mercurial`(Hg)、`Bazaar`或`Darcs`等,每个开发者的工作站上都是一个完整的版本库,包括完整的历史记录。这种模式非常适合需要频繁交换代码的团队,同时具有更好的安全性。 ...
`git-remote-hg`是一个Python实现的Git远程助手,它使得Git能够与Mercurial(Hg)仓库进行通信。通过这个库,你可以将Git仓库作为Mercurial的远程仓库,反之亦然,实现了Git和Mercurial之间的无缝集成。这对于那些在...
远程仓库则用于在团队间共享代码,GitHub就是最常见的Git远程托管平台。 使用Git,开发者可以执行以下操作: 1. 初始化仓库:`git init`命令用于在本地创建一个新的Git仓库。 2. 克隆仓库:`git clone`用于从远程...
- **分布式(Git、Mercurial)**:分布式版本控制系统如Git和Mercurial允许每个开发者的本地机器上都有完整的版本库副本,这样即使服务器宕机也不会影响开发进度,同时也极大地增强了系统的健壮性和灵活性。...
分布式版本控制工具如Git、Mercurial、Bazaar和Darcs等,它们没有中央服务器的概念,每个开发者都有一个完整的本地代码库。这意味着大多数操作,如查看历史记录、比较不同版本等,都是在本地进行的,不需要联网,...
- **分布式版本控制系统**(DVCS):如Git、Mercurial等,不仅在服务器端保存所有文件的版本库,每个用户的机器上几乎都有一个完整的版本库副本。这意味着即使中央服务器完全崩溃,也可以用任意一个克隆的版本库恢复...
本文将深入探讨Git的用途、工作模式、常用版本管理软件以及Git的基本操作,帮助你掌握Git的日常工作模式。 ### 版本管理的作用 版本管理是软件开发中的重要工具,它能够: 1. **历史追踪**:记录文件和项目的所有...
- 分布式版本控制系统如Git、Mercurial等的兴起。 - **Git的由来**: - Git是由Linus Torvalds于2005年发起的一个开源项目,最初是为了更有效地管理Linux内核源代码。 - Git的设计目标是速度、数据完整性以及支持...
在DVCS中,开发者可以在没有网络连接的情况下进行工作,然后在需要时将更改推送到远程仓库或从远程仓库拉取更新。这种模式极大地提高了开发效率,特别是在网络不稳定或速度较慢的环境中。 Mercurial 2.1.1 版本是一...
Git的强大之处在于其速度、数据完整性以及非线性的开发模式。 **Git基本概念:** 1. **仓库(Repository)**:存储所有版本信息的地方。 2. **提交(Commit)**:保存代码更改的一个快照,附带描述信息。 3. **分支...
相对的,分布式版本控制系统(如Git、Mercurial等)则允许每个用户本地复制整个代码库,每个用户的本地库都是完整的。即使网络断开,开发者依然可以在本地进行代码的提交(commit),待网络恢复后再将代码变更推送...
- **追踪远程分支**:使用`git branch --set-upstream-to=<remote>/<branch>`命令设置本地分支追踪远程分支。 ##### 4.6 变基 变基(Rebase)是一种将一系列提交应用到另一个提交之上的操作。它能够使分支的提交...
- **分布式版本控制系统**:如Git、Mercurial (HG)。 #### 二、本地版本控制系统 1. **特点**: - 简单易用,许多操作系统内建支持。 - 适用于文本类型的文件管理,如系统配置文件。 - 缺乏远程操作能力,不...
- **分布式版本控制系统**:这类系统是目前的主流选择,代表性的有`Git`、`Mercurial`、`Bazaar`等。这些系统的特点在于,每个开发者的工作站上都完整地保存了一份版本库的副本,这不仅增强了系统的鲁棒性,还大大...