簡介 Git
Edit: 2012-01-30 新增4圖, p.s.
隨著 Drupal 放棄 CVS 而使用 Git 之後,
作為一個 Drupal developer, 你便需要使用 Git 了
如果你之前有看過的的 SVN 教學的話,
你便會發覺 CVS 和 SVN 很類似
而這次我也會使用很多 SVN/CVS 的詞彙令大家更容易過渡到 Git
Git 是一種分散式的代碼管理系統 (DCVS)
相比 SVN/CVS, 各種操作都可以單機完成, 最後再上交到一個或者多個伺服器
具體的分別有:
SVN Merge
使用了 SVN 一段時間之後, 你便會遇到複雜的情況: Conflicts
例如你和你的拍擋同時在修改同一個文件, 大家都是基於 r27
你的拍擋 commit 了, 變成 r28
但係也 commit 一個基於 r27 的檔案, 想要變作 r28
而且大家修改的行數相當接近, 自動的 merge 不能完成的時候
SVN 便會提示你, 已經發生了一個 Conflict
要求你先 solve Conflict 再 commit, 也即你需要 Merge 了
有 conflict 的檔案會標示為 conflict state, 檔案的內容也會有相關 conflict 的資料
你需要做的便是先 update, 將你的拍檔修改的部份了解一下
再手動修改這個檔案, 直到它能正常執行
也包含了你和你的拍檔的修改之後
儲存, 將這個檔案摽示為 "已解決"
Note to self: Create new svn repo for new project
sudo svnadmin create /svn/project1
sudo vi /svn/project1/conf/svnserve.conf
anon-access = none
auth-access = write
realm = Project1 Repository
sudo vi /etc/apache2/sites-available/default
#create a new vhost for svn
#define the passwd path
sudo htpasswd -cm /svn/project1/conf/passwd joe
sudo htpasswd -m /svn/project1/conf/passwd joe2svn import 的問題
Svn import 的使用原意是, 將一個已經建立好的專案匯入到 svn 的管理之下
作為第一次的提交, 是假設專案已經開展了, 一次匯入多個檔案
但 svn import 最後卻得不到廣大使用者的支持
svn 的文檔中也建議使用另一個方法匯入 (ref2)
原因有二:
1. 匯入之後的本機文件不會處於svn 的客戶端管理之下 (ref1)
意思其實是 import 了 c:\htdocs\abc 之後,
你需要再從 repo 之中 checkout svn 中的檔案
因為 import 之後, 本機的文件是不會有任何改變, 包括svn 的改變
2. 匯入的文件結構指令很容易出錯
我應該匯入 c:\htdocs\abc 還是 c:\htdocs\abc\* ?
checkout 時應該 checkout 根目錄還是子目錄?
3. 應該習慣建立 trunk, branches, tags 等的根目錄作為分支時使用 (ref3)
但import 方法不支持先建立以上的目錄樹
svn 概念, 初階使用
UPDATE: 2011-01-09 SVN merge
UPDATE: 2010-04-13 images added
ORG: 2009-06-13
svn 是一個管理源碼的工具
它提供一個容許多人協作的平台, 幫助一個多人開發的團隊管理代碼
同時提供一個保存多版本的功能 (version-ing)
而我因為多數都自己一個開發, 主要為了 versioning 而使用 svn
但因為有多個開發機器
為了保持代碼在多個機器中同步, 都會使用 svn
SVN merge
merge 是一件麻煩事. 當然, 用了branch 或者tag 才需要 merge.
當一個或者多個commit 需要同時應用到另一個branch, 你便需要merge. 通常你都會從trunk merge 到branch 的
一開始使用merge 可能會感到害怕, 但merge 和commit, update 一樣, 用多了使自然覺得很方便了. 而且, 不需要擔心merge 錯, 因為merge 的動作本身是不會提交到svn 的. merge 完了, 你確認了代碼, 功能都沒有問題之後, commit, 才會提交到svn.
在merge 的過程, 你要選擇你merge 的 revision number, 所以, svn 的 commit message 便很重要, 會是你決定用不用某一commit 的最重要依據.
merge 時, 你應該先switch 到被merge 的branch, 再選擇trunk 的revision, 例如, trunk revision 123 需要copy 到 branch, 便應該switch 到 branch, 再用merge
2009-07-17 svn tagging and branching
svn 是一種使用之前會討厭,
但使用過以後你已經不能缺少的開發環節 (情況和測試驅動開發(TDD)一樣)
在"使用過" 並愛上的青況之下,
你很容易便會提起興趣學習進階的 branch 和 tag 的功能了
但如果沒有, 直接跳過就好了
對於使用者來說, tag 和 branch 建立之後, 你會發現 svn 好像複製了 trunk 的檔案到另一個地方
所以你的在 trunk 的 commit 不會對tag 和 branch 的資料做成影響, 相反如是
如果你瀏覽你的 repo, 你便可以發現你的 code 都在 trunk 資料夾之下(如果正常的設定之下)
上一層便可以看到 tags 和 branches 資料夾, 甚至是 releases 資料夾
但tagging 並不會對你的檔案系統和硬碟做成壓力
因為它只會建立連結到 tags, 而不會建立另一組的檔案
另一面說, 就是 svn 提供一個快速的 tag 和 branch, 令你樂於使用, 就好像 commit 一樣
