常見版本管理工具

http://blog.csdn.net/zhourui1982/article/details/4871896
http://wenku.baidu.com/view/054ae81afad6195f312ba6c6.html


一、VSS

VSS 的全稱爲 Visual Source Safe 。作爲 Microsoft Visual Studio 的一名成員,它主要任務就是負責項目文件的管理,幾乎可以適用任何軟件項目。

Windows平臺下使用VSS開發的典型環境是基於C/S架構的,即開發小組的每個開發者在各自的Windows平臺下利用開發工具(比如VC)開發項目中的各個模塊,而配有專門的服務器集中控制開發過程中的文檔和代碼。服務器和開發人員的客戶機分別裝有VSS的服務器和客戶端程序。

VSS是微軟的產品,是配置管理的一種很好的入門級的工具。VSS最初的名字叫Source Safe,是一家小公司的產品,92年曾經獲了最佳小型管理工具獎,然後立即被微軟收購。但是微軟收購的只是source safe的Windows版本,在美國還有另外兩家公司分別獲得了繼續開發和銷售source safe的Mac版本和Unix版本的許可,在MS買進vss之後,基本上沒有對vss進行任何的研發,MS內部自身也不用vss。

VSS 沒有采用對許可證進行收費的方式,只要安裝了 VSS ,對用戶的數目是沒有限制的。因此使用 VSS 的費用是較低的。它屬於“買大件送小件”的角色。如果你合法地得到Visual Studio,你就得到了免費的SourceSafe。

注:VSS只有Windows環境。


二、CVS

CVS是一個C/S系統,多個開發人員通過一箇中心版本控制系統來記錄文件版本,從而達到保證文件同步的目的。CVS版本控制系統是一種GNU軟件包,主要用於在多人開發環境下的源碼的維護。

2009年,絕大多數CVS服務已經改用SVN。CVS已經停止維護。


三、SVN

SVN是一個安全虛擬網絡系統,它將系統整體的信息安全功能均衡合理地分佈在不同的子系統中,使各子系統的功能得到最大限度的發揮,子系統之間互相補充,系統整體性能大於各子系統功能之和,用均衡互補的原則解決了"木桶原理"的問題。
SVN能在跨接Internet, Intranet, Extranet間的網絡所有端點實現全面的安全,而且還能提供基於企業策略的信息管理機制以充分有效地利用有限的帶寬。SVN可以滿足各種企業VPN的要求,通過爲公司內部網絡、遠程和移動用戶、分支機構和合作伙伴提供基於Internet的安全連接。所以,我們可以將SVN看成是VPN、防火牆、基於企業策略的信息管理軟件集成在一起的Internet安全的綜合解決方案。在這樣一個網絡系統中,所有互聯網服務器端和客戶端都是安全的,並有一個信息管理機制以不斷地通過這個外部網絡環境動態地分析及滿足客戶的特定帶寬需求。

注:SVN客戶端有Windows環境和linux環境。


四、GIT

Git --- The stupid content tracker, 傻瓜內容跟蹤器。Linux 是這樣給我們介紹 Git 的。
Git 是用於 Linux 內核開發的版本控制工具。與常用的版本控制工具 CVS, Subversion 等不同,它採用了分佈式版本庫的方式,不必服務器端軟件支持(wingeddevil注:這得分是用什麼樣的服務端,使用http協議或者git協議等不太一樣。並且在push和pull的時候和服務器端還是有交互的。),使源代碼的發佈和交流極其方便。 Git 的速度很快,這對於諸如 Linux kernel 這樣的大項目來說自然很重要。 Git 最爲出色的是它的合併跟蹤(merge tracing)能力。


1. git命令行:

[python] view plain copy
  1. usage: git [--version] [--help] [-c name=value]  
  2.            [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]  
  3.            [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]  
  4.            [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]  
  5.            <command> [<args>]  
  6.   
  7. 簡單而言,用法: git <command> [command參數]  
  8. command參數可以使用該命令查看: git help <command>  
  9.   
  10. 最常用command如下:  
  11.    add        不但是用來添加不在版本控制中的新文件,也用於添加已在版本控制中但是剛修改過的文件; 在這兩種情況下, Git都會獲得當前文件的快照並且把內容暫存(stage)到索引中,爲下一次commit做好準備。  
  12.                   git add <fileName>  增加文件/目錄到當前分支;  
  13.    bisect     Find by binary search the change that introduced a bug  
  14.    branch     顯示、新建或者刪除一個分支;  
  15.                   git branch  不加參數會得到當前倉庫中存在的所有分支列表,星號(“*”)標識了你當工作在哪個分支下。  
  16.                   git branch <branchName>  新建一個分支  
  17.    checkout   CheckOut一個分支並切換到該分支,從而改變了當前分支爲此分支   
  18.                   git checkout <branchName> 切換到該分支  
  19.                   git checkout .  放棄本地所有已經編輯,但未commit/push的更改,還原爲和遠端一樣的版本  
  20.    clone      下載一個遠端倉庫到本地  
  21.                   git clone 'http(s)://[userName@]host:port/xxx/yyy/zzz.git' [dir] 使用http(s)方式從遠端倉庫進行clone,默認clone到本地的zzz目錄,添加dir參數後則clone到dir目錄內。如果添加用戶名,會提示輸入密碼,否則使用無驗證方式進行clone  
  22.                   git clone 'git@gitRepository:xxx/yyy/zzz.git' [dir] 使用ssh方式從遠端倉庫進行clone,該方式支持大文件的push和pull,需要先配置密鑰,後面進行詳述。  
  23.    commit     提交變更到本地倉庫;  
  24.                   git commit -a -m '<comment>' -m參數指定註釋,-a參數自動添加所有並更到本次的commit中  
  25.    diff       不加參數,顯示未提交的本地更改內容;  
  26.               加一個分支名作爲參數,則將本地分支和參數指定的分支進行diff;  
  27.               加2個分支名作爲參數,則對這兩個分支進行diff(注:這2個分支必須已經co到本地);  
  28.               加參數--stat則只給出統計信息  
  29.    fetch      從遠端倉庫更新當前分支   
  30.    grep       Print lines matching a pattern init Create an empty Git repository or reinitialize an existing one  
  31.    log        倒序展示commit日誌  
  32.                   git log [--stat] 倒序展示所有的commit日誌,--stat參數會顯示變更的內容統計  
  33.    merge      將一個分支merge到當前分支  
  34.                   git merge [branchName] 將該分支合併到當前分支  
  35.    mv         在當前分支中移動文件/目錄  
  36.    pull       從遠端倉庫更新當前分支並智能合併  
  37.    push       提交本地的所有commit到遠端倉庫  
  38.    rebase     Forward-port local commits to the updated upstream head  
  39.    revert     撤銷 某次操作,此次操作之前和之後的commit和history都會保留,並且把這次撤銷 作爲一次最新的提交  
  40.                   git revert HEAD 撤銷最近一次的commit  
  41.    reset      Reset current HEAD to the specified state  
  42.    rm         在當前分支中刪除文件/目錄  
  43.    show       Show various types of objects  
  44.    status     展示當前分支的狀態(是否commit,是否push)  
  45.    tag        Create, list, delete or verify a tag object signed with GPG  
  46.    remote     展示當前git目錄對應的遠端的情況,加-v展示詳細信息,例如遠端的git路徑  
  47.                   git remote set-url origin <git root url>   將git root設定爲其他地址  

2. git設置

1) 爲git設置縮寫命令

修改.gitconfig文件,linux下該文件位於~/.gitconfig,在文件的末尾添加如下代碼:

[python] view plain copy
  1. [alias]  
  2.     co = checkout  
  3.     ci = commit  
  4.     st = status  
  5.     pl = pull  
  6.     ps = push  
  7.     dt = difftool  
  8.     l = log --stat  
  9.     cp = cherry-pick  
  10.     ca = commit -a  
  11.     b = branch  
  12.     r = remote -v  

2)爲git設置提交時的用戶名和郵件

執行以下命令:

[python] view plain copy
  1. git config --global user.name "Your Name"  
  2. git config --global user.email [email protected]  
  3. # 或者直接修改gitconfig文件裏的name和email配置項  

3. 上傳文件過大的問題的解決辦法:

錯誤提示:

error: RPC failed; result=22, HTTP code = 411

解決辦法:

git config --global http.postBuffer 52428800  (改爲最大50M)


錯誤提示:

error: RPC failed; result=22, HTTP code = 413

該錯誤是因爲web server不支持這麼大的文件傳輸,可以修改ng的配置使web server來支持。或者將http方式改用ssh方式。

改用ssh方式的具體做法如下:

1. 設置遠程倉庫地址

[python] view plain copy
  1. git remote set-url origin git@gitRepository:xxx/yyy/zzz.git  
2. 客戶端產生密鑰

[python] view plain copy
  1. ssh-keygen -t rsa -C "[email protected]"  
然後按3次回車來生成對應的郵箱的密鑰
3. 登錄gitlab管理界面,在用戶的profile中add public key(上一步生成的public key位於~/.ssh/id_rsa.pub中)


使用以上方法後clone,push和pull等都不再需要密碼。


4. 常見的.gitignore設置

[python] view plain copy
  1. # kdiff3 ignore  
  2. *.orig  
  3.   
  4. # maven ignore  
  5. target/  
  6.   
  7. # eclipse ignore  
  8. .settings/  
  9. .project  
  10. .classpath  
  11.   
  12. # idea ignore  
  13. .idea/  
  14. *.ipr  
  15. *.iml  
  16. *.iws  
  17.   
  18. # temp ignore  
  19. *.log  
  20. *.cache  
  21. *.diff  
  22. *.patch  
  23. *.tmp  
  24.   
  25. # system ignore  
  26. .DS_Store  
  27. Thumbs.db  
  28.   
  29. # package ignore (optional)  
  30. # *.jar  
  31. # *.war  
  32. # *.zip  
  33. # *.tar  
  34. # *.tar.gz  


附錄一、linux下的SVN使用的簡單流程

1. 第一次把服務器代碼下載到本地。

svn co svn_url [path] 

#path可以省略,設svn_url=https://xxx/mytool,如果省略path,則在當前目錄新建mytool文件夾,並下載svn_url目錄裏的文件下載到其中;如果path=mytool_local,就在當前目錄新建mytool_local,並將svn_url目錄裏的文件下載到其中。

2. 更新本地代碼

svn up

3. 把本地新修改添加的代碼更新到服務器

a) svn st #顯示狀態

b) 對於顯示的列表裏,前面帶有?的表示還沒有添加到待同步列表裏,使用如下命令加入到待同步列表:

svn add {文件名或目錄名} #當添加一個目錄,svn add缺省的行爲方式是遞歸。path參數可以使用類似/home/root/svnroot/*/*形式

svn add * --force #命令svn add *會忽略所有已經在版本控制之下的目錄,可以使用參數--force遞歸到版本化的目錄下

c) 對於顯示的列表裏,前面帶有!的表示本地已經刪除,使用如下命令從待同步列表刪除(需要先svn up將其副本更新到本地,再執行如下命令):

svn delete {文件名或目錄名}

d) svn ci -m "comment"  #提交,不帶comment會出錯

4. 不co直接將文件添加到svn

svn import -m 'comment' [path] svn_url

#path如果省略,則使用當前目錄.作爲參數

#如果path爲目錄,則將path下的內容ci到svn_url的目錄下,而不會新建path目錄,故一般需要在svn_url中添加目錄名。例如:svn import -m 'this is for try' tools http://xxx/bak/tools

svn co --force svn_url

#因爲import後本地目錄並沒有被添加到svn控制之下,所以,使用co命令下載到本地,並且要加--force參數來強制執行(因本地已經存在同名目錄)

5. 其他操作

svn info 需要在已經svn的目錄下使用。顯示當前目錄的svn信息,如url地址,和用戶名等。

svn  rename wc(本地原來目錄名/文件名) wc(重命名後的目錄名/文件名)

svn move SRC DST  移動目錄或文件夾命令

6. 切換用戶

1). 臨時切換
在所有命令下強制加上--username 和--password選項。 
例如:svn up --username zhangsan --password 123456
2).永久切換
刪除目 ~/.subversion/auth/  下的所有文件。下一次操作svn時會提示你重新輸入用戶名和密碼的。換成你想用的就可以了。然後系統默認會記錄下來的。


附錄二、使用主幹與分支,解決版本衝突

1. svn的主幹與分支

trunk--主幹,是開發的主線。  
branches--分支,是從主線上分出來獨立於主線的另一條線。
tags--標記,主要用於項目開發中的里程碑。它往往代表一個可以固定的完整的版本。SVN不推薦在創建的tag基礎上Revision這種情況應用branches,因爲tag一般保持不變不作任何修改。
總之,主幹和分支都是用來進行開發,而標記是用來進行階段發佈的。branches以及tags在TortoiseSVN中創建方法是一致的:它們都是通過存儲類似Linux中的硬連接一樣,只是創建了指向某個版本的鏈接,而不會真正將此版本的內容複製到分支或者標記中,這樣既可以節省空間,也可以很快速的創建,被稱爲“廉價的拷貝”。 

2. 主幹開發,分支發佈

典型操作步驟如下:
1) 開發者提交所有的新特性到主幹。 每日的修改提交到/trunk,包括新特性bug修正和其他。  
2) 這個主幹被拷貝到“待發布”分支。 當小組認爲軟件已經做好發佈的準備如版本1.0然後/trunk會被拷貝到/branches/1.0。  
3) 項目組繼續並行工作測試小組開始對分支進行嚴酷的測試同時開發小組在/trunk繼續新的工作,如準備2.0。如果一個bug在任何一個位置被發現,錯誤修正需要來回運送。
4) 分支已經作了標記並且發佈。當測試結束,/branches/1.0作爲引用快照已經拷貝到/tags/1.0.0,這個標記被打包發佈給客戶。  
5) 分支多次維護。當繼續在/trunk上爲版本2.0工作,bug修正繼續從/trunk運送到/branches/1.0(分支也在“更新”,但只進行bug修復)。如果積累了足夠的bug修正,管理部門決定發佈1.0.1版本,拷貝/branches/1.0到/tags/1.0.1,標記被打包發佈。 

優點:
這種管理方法對已發佈產品的維護工作和下一代產品的開發工作進行了隔離。對於已經發布的產品只有維護的補丁發佈。而新發行的產品不僅包括了所有的bug修改,還包括了新功能。所以,非常適用於產品線的發佈管理。

缺點:
1). 必須對主幹上的新功能增加進行控制,只能增加下一個發佈裏面計劃集成進去的新特性。
2). 已經在主幹上集成的新特性中的任何一個,如果達不到里程碑的要求,穩定分支就不能創建,就會影響下一個發佈的計劃。
3). bug修改必須在各個分支之間合併。

3. 分支開發,主幹發佈

策略介紹:
與上一種分支策略(它的主幹上永遠是最新特性的不穩定版本)正好相反,此策略的主幹上永遠是穩定版本,可以隨時發佈。
bug的修改和新功能的增加,全部在分支上進行。而且每個bug和新功能都有不同的開發分支,完全分離。分支上的開發和測試完畢以後才合併到主幹。
而對主幹上的每一次發佈都做一個標記而不是分支。

優點:
1). 每次發佈的內容調整起來比較容易。如果某個新功能或者bug在下一次發佈之前無法完成,就不可能合併到主幹,也就不會影響其他變更的發佈。
2). 每個分支的生命期比較短,唯一長期存在的就是主幹,這樣每次合併的風險很小。

缺點:
1). 分支開發週期不能過長,如果分支長期沒有合併到主幹上,很可能在最後合併的時候出現嚴重衝突。
2). 測試分支就是各個開發分支,而主幹上的程序是沒有經過測試的。(從這個發佈模式上看,最後一個合併入主幹的開發分支應該和主幹下一次的發佈內容相同,但是這個分支的測試卻只是本分支的修改內容點,而非產品級別的功能迴歸,故稱:主幹上的程序是沒有經過測試的)

4. 分支開發,主幹發佈--改進:拉分支發佈

就是在發佈時不是打tag進行發佈,而是拉一個分支出來,測試後進行發佈。

特點:
當前發佈需要回滾時,可以直接將上一個發佈分支覆蓋到主幹。並且,拉分支發佈時可以測試主幹上的程序,進行成品級別功能迴歸。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章