為什麼使用 Git 和 Dropbox 來做版本管理，直接用 Dropbox 來做不行嗎？

01-29

很多人都用Git做版本管理，然後用Dropbox來在各個機器之間同步Git的倉庫。但Dropbox不是有與Git相似的版本管理功能嗎（除了象分支這樣的更強大的功能外），大多數文件回滾、衝突解決等功能Dropbox都有了。
請問對於個人開發的小項目，為什麼不直接把項目放在Dropbox的目錄下，用Dropbox來直接做代碼的版本管理？
對於多人團隊開發的項目，將Git保存在伺服器上，然後Dropbox伺服器上的目錄。可是Dropbox專門聲明不建議管理網路共享目錄，因為Dropbox無法及時監控到來自網路請求導致的文件變化。那這種Git + Dropbox方式對於團隊是不是就不合適？

Dropbox主要還是用來同步的,文件歷史功能並不強,即使購買了無限歷史服務,依然有一些問題:

在git中,你的每一次"提交"都是保存著整個項目的一個"狀態",一個狀態可能同時是多個文件的修改,

多個文件的更改構成了一個"狀態",就像你打遊戲存檔,每一次存檔是把遊戲世界中所有的角色的

血條,位置等信息都保存下來.

而Dropbox中沒有這種概念,一個文件的修改就是一個文件的修改,當你修改了多個文件後,你根本想不起來哪個文件的哪個版本和哪個文件的哪個版本對應著昨天你這個項目的"狀態".每一個歷史記錄都是對應著文件,而不是項目,就像把一個遊戲世界裡所有角色的信息一個一個地分別保存一樣,當你想還原遊戲狀態時,已經記不住每個角色什麼時間的狀態加起來才是某個時刻的遊戲狀態了.

Dropbox沒有Commit/Changeset的概念，對於軟體開發管理來講是硬傷。

dropbox別說git，就連svn的功能都趕不上。

隨便一個基本功能，比如對每次commit提供一個說明，本次修改幹了什麼，是誰改的。如果這段代碼出了問題，可以方便的找出來blame當時是誰在什麼情況下提交的。dropbox根本幹不了。

實際上上面的blame對個人同樣有效，一個月之後你根本不記得上個月為什麼要這麼寫，本來就沒什麼文檔，不能方便的查看每次commit的內容，基本屬於抓瞎。

個人做作業的項目dropbox估計還行，因為只有同步這一個需求，一個月後這代碼就沒人看了。3人以上團隊，或者需要向用戶交付高質量產品的團隊，用dropbox估計藥丸。

Dropbox只能夠做到最基礎的版本管理，而Git的功能則覆蓋了Commit,Changeset,Branch,Tag等非常多強大的功能。

在開發過程中，對代碼並沒有如此高的同步要求。我們一般會開發到一個小小里程碑的時候再將代碼提交到庫中，同時在提交時可以標註這次提交我到底做了什麼。這樣無論回滾到庫中的任何版本，所存放的代碼都是非常健康的。甚至我們可以通過Tag去指定代碼基線和問題代碼跟蹤，對整體代碼的健康度是非常有幫助的。

我們非常喜歡在一個軟體項目結束之後，查看版本樹。每個階段的過程都是可以有據可循的。如果在團隊開發中，每個版本能夠關聯到用戶請求（Request）你就會發現這是一件很棒的事情。

當然用Dropbox協作完成文檔類工作是件非常方便的事情，可惜國內網速慢了點。

最後談一談Git+Dropbox....

那為什麼不直接用GitHub呢....？

如果你只是把git當網盤用，換dropbox也沒什麼不妥。

從來沒聽說過哪個公司用dropbox同步git

Git 是一種版本控制系統。在開發過程中，為了跟蹤代碼，文檔，項目等信息中的變化，版本控制變得前所未有的重要。但跟蹤變化遠遠不能滿足現代軟體開發行業的協同需求，基於 Git 的 Workflow 滿足了合作編程的需求，讓開發從此變得更加高效和有趣。相比集中式版本控制系統如 SVN ，分散式版本控制系統 Git 擁有更強大的分支管理與合併能力，支持離線開發，並良好地保留了提交過程，讓您和您的團隊在開發過程中如虎添翼。

來自：Coding-on-Coding

git的管理結構要比dropbox複雜得多。

首先，如果有兩個程序員同時貢獻同一個文檔的代碼，git就會將這兩份代碼整合在這個文件中並且備份。很明顯dropbox沒有這個功能。

同時，git被許多ide支持，寫完代碼保存後點一下git按鈕直接發到伺服器上，比dropbox方便。