Temporality » git http://www.sylin.net/blog my causerie Sat, 26 Jun 2010 19:44:04 +0000 en hourly 1 http://wordpress.org/?v=3.0 SCM大車拼 http://www.sylin.net/blog/2009/03/01/153 http://www.sylin.net/blog/2009/03/01/153#comments Sun, 01 Mar 2009 07:45:19 +0000 sylin http://www.sylin.net/blog/?p=153 去年初的時候也寫過一篇 CMS 大車拼，今年換寫 SCM。

最近在看 git 的資料時，順便查了一下和其他 Version Control System 的比較，主要是因為要查 MS 提供的 Visual Source Safe，雖然沒必要我是不會去用它的，不過瞭解一下它和 Subversion 及 git 的差異倒沒問題。

找到在 Version control systems comparison 提供了常見 SCM 工具的功能比較表。這裡比較了我知道認識的人有再用的幾套，包括 ClearCase, CVS, Git, Subversion, Visual Source Safe。

Atomic Commit

指的是帶入 transcation 的觀念，一次的提交(commit)的內容可能會包含多個檔案的修改，這會被視為一個整體的操作，避免在 commit 的過程中發生錯誤，導致版本內容不一致。以 CVS 為例，假如我加了一個功能，需要修改10的檔案，就會一次 commit 10個檔案，如果在中途發生錯誤，會導致有些檔案是新版的，有些是舊版，有 Atomic Commit 可以避免這個問題。

Intelligent Merging after Moves or Renames

以 Subversion 為例，它的 rename 等於是把原檔案刪除，再加入一個新的檔案(內容不變)，系統本身不維護更名這動作的資訊，所以要作 merge 到一個已被更名的檔案就會有麻煩，基本上這還是要透過人工的方式處理，而其他幾套也都不支援這樣的動作。

File and Directories Copies

Subversion有，可是 Git 沒有..再研究看看會有什麼影響..

其他的部份

在幾個比較項目上，Subversion 還需要透過其他 plug-in 或程式來達成，而 VSS 本身只支援 Windows 平台

比較的項目太多了，暫時先不一一註記，不過如果要打槍 VSS 的話，在 Wikipedia 上反而有個不錯的理由：
Visual SourceSafe

VSS雖然是微軟公司的產品，但微軟內部卻很少使用它。微軟內部使用一個名為SLM的版本控制系統，直至1999年。之後，微軟內部改以使用修改自Perforce的SourceDepot。

連自己都不用的產品，應該也沒什麼前途……

其他教學文件

© admin for Temporality, 2009. | Permalink | No comment | Add to del.icio.us
Post tags: , , , , , ,

Feed enhanced by Better Feed from Ozh

]]> http://www.sylin.net/blog/2009/03/01/153/feed 0 Git 入門筆記 http://www.sylin.net/blog/2009/02/22/151 http://www.sylin.net/blog/2009/02/22/151#comments Sun, 22 Feb 2009 10:54:26 +0000 sylin http://www.sylin.net/blog/?p=151 前言

這兩天花了蠻多時間在 Survey Git 這套先進的 SCM。在新的工作上，我打算從 Subversion 轉換到 Git 來做專案、程式的版本控制。

之前在學習 Subversion 時，是根據 SVN Book 中文版開始入門，從而瞭解 CVS 和 Subversion 設計及使用的觀念，讓我知道，使用 CVS 或 Subversion 的差異，以及該如何使用 SVN 融入我的開發流程，以文件來說， SVN Book 是寫的相當清楚易懂的。不過 Git 在這個部份，我卻沒有找到相似的介紹文件，尤其是它著名的 Distributed 特性，讓我不太了解如何套用，以及使用這樣 Distributed 的特性，會對原本工作的流程產生什麼樣的影響和變化。這些都是在 Survey 的過程中需要先被確認的。

疑問 – 如何規劃 Repository?

首先，我的第一個問題就是「我該如何規劃 Repository?」在 CVS/Subversion 中，我們可以使用一個 Repository 來放許多個不同的 Project，並以目錄來區分，如同工作複本這段所敘述的。更複雜一點的，可以使用檔案庫配置這段所建議兩種架構中選擇一種。


而在工作目錄的部份，可以直接依據情況，只 checkout 需要的子目錄部份即可，而因為 Subversion 會在 Working Directory 的每個子目錄下，都建立一個 .svn/ ，所以它仍可以正確對應目錄資訊，不過 Git 由於只在 Working Directory 的最頂層放一個 .git/ 來處理，使得我蠻懷疑要怎麼處理這樣的狀況？

從這樣的一個基本的疑問，我開始查資料去瞭解 Git ~

參考文件

一開始我先看 Linus 之前在 Google 演講 Git 的錄影 – Linus Torvalds on git (相關介紹可參考 Rex’s 的介紹)，不過聽了半天，發現我只能斷斷續續的聽懂幾句話，而且錄影是以 Linus 的講演為主，對我來說學習的效果不佳，只好另外找其他資料。
於是找到了另一篇簡報的錄影 – OGRE Git Tutorial，這篇介紹了 Git 的內部設計(實做)概念，以及幾個主要的 Work Flow 跟常用指令，這一篇就蠻有幫助的。
以下是一些相關的筆記：

  • 不需要 trunk 或 branch 這樣的目錄結構，在 .git 裡面會處理這訊息 *

  • git show = svn status (and svn diff)
    git show –stat 單純顯示 status, 也就是 Working 和 HEAD 的差異
    git show –name-status 如同 svn st 的顯示方式

  • branch 分成3種: local branch (綠色方塊)、tag (藍紫色方塊)、remote branch(橘色方塊)
  • 使用 git checkout -b 做切換分支的動作 *
  • HEAD 代表目前 Work Directory 所使用的 branch (的最新版本)
  • merge 指令
  • rebase 指令, 可以將 (local) branch 整合到 (local) trunk 上，但和 merge 有點不同，感覺有點類似 merge 以後將分支砍掉的感覺 *

其中有標 * 的表示和 Subversion (包括觀念或用法)比較不同的地方。
不過在最後面有關 push 跟 poll 的部份，我還沒有看懂是怎麼分辨其他人能不能 push patch 到 original 去的，不過這不是大問題，用了以後就會知道了。

結論

基本上看完這些以後，目前是傾向把一個 git 來管理一個 project 吧，否則一個 branch 或 tag 在 git 是代表整個 repository 的版本，但對對多個 project 來說，這樣的 branch 或 release tag 並沒有意義。

© admin for Temporality, 2009. | Permalink | One comment | Add to del.icio.us
Post tags: , , , ,

Feed enhanced by Better Feed from Ozh

]]> http://www.sylin.net/blog/2009/02/22/151/feed 1