SAIKURON 13.Ned

distributed even if your workflow isnt distributed is the new centralized. Git靠在檔案裡面記錄的內容來維護自己的狀態，Daemon看使用者的位置在哪個容器，就對哪個容器作事情。 目錄名稱有.git就是裸容器 用檔案內容經過SHA1產生唯一ID，長度為160bit，只需比對ID，就可得知檔案是否相同 用ID的前16bit做目錄名稱分配，避免同一目錄檔案過多，造成效能低下。 160bit的SHA1 ID不只用在內容，Git內部的資料結構，全部都使用SHA1，blob，tree，commit，tag，全部都有自己的SHA1 ID。架構簡潔，容易了解。 整個系統的資料結構，只有blob、tree、commit、tag，非常簡單。 同一個檔案，如果做了更動，ID就會不同，也會將內容存成一個新的blob，相較於其他SCM是記錄檔案變動，較耗空間。所帶來的好處更多? 不以檔案系統的檔名與路徑來決定內部管理資料結構，避免與檔案系統內容綁死，像是改名，追蹤歷史，都以ID來判斷。 只要檔案內容不改變，不管是更名，分支，搬移，複製，全部都不需要再多一份檔案。 透過維護Tree Object把所有git相關設定放在容器根目錄底下，避免四散設定檔 沒有所謂daemon或是Servcie，全部都是有需要才執行功能，功能執行根據容器的內容來處理。這樣省記憶體，省CPU時間。 本來想說要是檔案有好幾百萬，那光是開個tree就會很耗記憶體，搜尋與比對檔案內容是否相同，也非常花時間。Git的tree裡面可以有tree，所以tree裡面的內容會因檔案的樹狀結構而分散，除非極端的狀況，同一個目錄就幾百萬個檔案，不然一般的使用狀況，tree檔案的內容應該都很小。 是不是多個專案都應該放在一個容器裡面？在Ruckus用Perforce是這麼做，在網龍用Subversion是分開，在Git裡面應該是?因為在Git裡面的branch都是以容器為單位，commit物件也是追蹤容器，所以如果多個專案在同一個repository內，沒有辦法區分出各專案的歷史。而Perforce與Subversion都是以檔案為單位，可以用資料夾來區分歷史，所以可以把多個Project放在同一個Repositor...

描述軟體開發的理想世界 在理想世界我們只有一個版本，沒有bug，有足夠的時間開發，開發不會延遲。但是現實世界並非如此，所以我們有了軟體版本控制系統，我們有了分支。 限制分支的數量，把分支看成一個一個stage(development、QA、Beta test、Live)，來處理短周期Release，避免分支過多，不管Release再怎麼短，Release Branch只會有三個(所以並不會限定development branch)，這個作法稱為staging codeline。 從mainline中分支出development分支，來處理不同開發者，不同團隊開發延遲或是錯誤的程式碼造成無法Release的問題 除非開發者的成果可以正常編譯且功能正常，否則不會進mainline，達成mainline可以維持在理想狀態不斷前進 用Map(地圖)、Protocols(協定)、Convention(公約)、Etiquette(禮讓)來讓Branch可以被管理， Ex：道路 codeline=觀念 branch=實作 codeline分支出來的起源稱為baseline 沒有baseline就稱為mainline aka=also known as tofu scale：越上面越硬(可測試，接近Release，也就是穩定)，越下面越軟(不穩定，離Release遠)，這個等級代表改變codeline的風險程度。mainline在中間的位置，每個codeline的tofu scale相對於mainline，注意：親子codeline可以表示相對硬度，兄弟codeline只能跟baseline比較 staging codeline與tofu scale在mainline上合體，形成可以兼顧Release與development的分支策略 以map方式表達分支狀態，處理兄弟codeline表示的問題，表達Change該如何流動 使用Change Flow的策略，完成把所有Change Flow全部匯流到mainline的理想，所以mainline只會穩定的成長 Change Flow只能在codeline與它的baseline之間流動，所以一個codeline的改變只能流到baseline，基本上不能跳著流動 ...