1.git 和 svn 的差異
git和svn 最大的差異在於git是分布式的管理方式而svn是集中式的管理方式。如果不習慣用**管理工具，可能比較難理解分布式管理和集中式管理的概念。下面介紹兩種工具的工作流程（團隊開發），通過閱讀下面的工作流程，你將會很好的理解以上兩個概念。
集中式管理的工作流程如下圖（圖2.1）：
集中式**管理的核心是伺服器，所有開發者在開始新一天的工作之前必須從伺服器獲取**，然後開發，最後解決衝突，提交。所有的版本資訊都放在伺服器上。如果脫離了伺服器，開發者基本上是不可以工作。下面舉例說明：
開始新一天的工作：
2：進入自己的分支，進行工作，每隔1個小時向伺服器自己的分支提交一次**（很多人都有這個習慣。因為有時候自己對**改來改去，最後又想還原到前乙個小時的版本，或者看看前乙個小時自己修改了哪些**，就需要這樣做了）。
3：下班時間快到了，把自己的分支合併到伺服器主分支上，一天的工作完成，並反映給伺服器。
這就是經典的svn工作流程，從流程上看，有不少缺點，但也有優點。
缺點：1、伺服器壓力太大，資料庫容量暴增。
2、如果不能連線到伺服器上，基本上不可以工作，看上面第二步，如果伺服器不能連線上，就不能提交，還原，對比等等。
優點：1、管理方便，邏輯明確，符合一般人思維習慣。
2、易於管理，集中式伺服器更能保證安全性。
3、**一致性非常高。
4、適合開發人數不多的專案開發。
5、大部分軟體配置管理的大學教材都是使用svn 和vss。
下面是分布式管理的工作流程，如下圖（圖2.2）：
分布式和集中式的最大區別在於開發者可以在本地提交。每個開發者機器上都有乙個伺服器的資料庫。
圖2.2就是經典的git開發過程。步驟如下：
一般開發者的角度：
1：從伺服器上轉殖資料庫（包括**和版本資訊）到單機上。
2：在自己的機器上建立分支，修改**。
3：在單機上自己建立的分支上提交**。
4：在單機上合併分支。
5：新建乙個分支，把伺服器上最新版的**fetch下來，然後跟自己的主分支合併。
6：生成補丁（patch），把補丁傳送給主開發者。
7：看主開發者的反饋，如果主開發者發現兩個一般開發者之間有衝突（他們之間可以合作解決的衝突），就會要求他們先解決衝突，然後再由其中乙個人提交。如果主開發者可以自己解決，或者沒有衝突，就通過。
8：一般開發者之間解決衝突的方法，開發者之間可以使用pull命令解決衝突，解決完衝突之後再向主開發者提交補丁。
主開發者的角度（假設主開發者不用開發**）：
1：檢視郵件或者通過其它方式檢視一般開發者的提交狀態。
2：打上補丁，解決衝突（可以自己解決，也可以要求開發者之間解決以後再重新提交，如果是開源專案，還要決定哪些補丁可用，哪些不用）。
3：向公共伺服器提交結果，然後通知所有開發人員。
優點：適合分布式開發，強調個體。
公共伺服器壓力和資料量都不會太大。
速度快、靈活。
任意兩個開發者之間可以很容易的解決衝突。
缺點：資料少（起碼中文資料很少）。
學習週期相對而言比較長。
不符合常規思維。
**保密性差，一旦開發者把整個庫轉殖下來就可以完全公開所有**和版本資訊。
2.git常用命令介紹
git init
建立乙個資料庫
git clone
複製乙個資料到制定資料夾
git add 和git commit
把想提交的檔案add上，然後commit這些檔案到本地資料庫。
git pull
git fetch
git whatchanged
檢視兩個分支的變化
git branch
建立分支，檢視分支，刪除分支
git checkout
切換分支
git merge
合併分支，把目標分支合併到當前分支
git config
配置相關資訊，例如email和name
git log
檢視版本歷史
git show
檢視版本號對於版本的歷史，如果引數是head檢視最新版本。
git tag
標定版本號
git reset
恢復到之前的版本
--mixed是git-reset的預設選項，它的作用是重置索引內容，將其定位到指定的專案版本，而不改變你的工作樹中的所有內容，只是提示你有哪些檔案還未更新。
--soft選項既不觸動索引的位置，也不改變工作樹中的任何內容。該選項會保留你在工作樹中的所有更新並使之處於待提交狀態。相當於在--mixed基礎上加上git add。
--hard 把整個目錄還原到乙個版本，包括所有檔案。
git push
向其他資料庫推送自己的資料庫
git status
顯示當前的狀態
git mv
重新命名檔案或者資料夾
git rm
刪除檔案或者資料夾
git help
檢視幫助，還有幾個無關緊要的命令，請自己檢視幫助。
3.git開發模式
1：大專案開發模式（如圖4.1）
對於專案負責人
1：初始化
對於最終專案負責人：
使用git init --bare在公共伺服器上建立乙個空資料庫，在自己的機器上通過
或者資料庫（這裡需要設定一下訪問許可權，由於git沒有提供許可權管理功能，所以要通過ssh設定，具體是對下一級子專案專案可讀不可寫，對自己可讀可寫）。
新建一些必要的資料夾和檔案放到自己的資料庫上
然後使用
提交到公共伺服器上，作為原始版本。
告訴下級公共伺服器的位址。
對於子專案負責人：
在子公共伺服器上轉殖乙個資料庫
設定訪問許可權，對下級可讀不可寫，對自己可讀可寫。
在自己的計算機中轉殖乙個資料庫
告訴下級子公共伺服器位址。
對於最底層的開發人員：
在上級公共伺服器中轉殖乙個資料庫
2：開展工作
對於最終專案負責人
收來自下級的郵件
在自己的資料庫上建分支，並轉到分支上
重複上述步驟，直到所有補丁打完。
如果發現在合併分支的時候發現有些衝突需要下級專案負責人協助解決的話，可以通知下級專案負責人。
對於子專案負責人：
如果上級專案負責人需要他們之間合作解決某些衝突，他們可以通過
解決衝突。
如果上級專案負責人沒有要求合作解決衝突，那專案負責人應該做以下事情：
然後專案負責人就開始接收郵件，然後打補丁
重複上述工作，直到補丁全部打完。
下面是向上級提交更新的過程
對於最底層的開發人員：
如果上級要求解決衝突，同樣是要解決衝突，然後再提交補丁
如果不用，就從上級伺服器更新
然後建分支，並開發**
然後是向上級提交**
以上就是git在大專案開發中的應用。
但是明顯是不適合我們實驗室的。
原因有三：
1、我們學生中沒有專門的維護人員。
2、我們學生中沒有對全域性都很了解架構師。
3、我們的老師可以擔當此重任也只有我們的老師有這樣的實力，但是老師太忙，沒時間每天做這些瑣事。
所以我們需要一種新的合作模式（一種沒有專案負責人的模式）。
這種模式對開發人員的素質要求很高。
合作模式如下圖（圖4.2）：（適合我們實驗室使用）
git團隊合作開發流程
關於git的環境配置在以前已說過就不羅索了，這裡介紹在公司如何團隊一起開發專案 首先你需要把你的秘鑰給管理員，如何配置以前介紹過了就不說了 進入正題 git ls files檢視當前廠庫被add得所有檔案 git push origin branchname 刪除遠端的branchname分支 gi...
團隊合作開發許可權管理
步驟一，tomcat的conf目錄下tomcat users.xml內容如下 xml version 1.0 encoding utf 8 tomcat users role rolename manager role rolename admin user username xiaolu pass...
用svn進行多人合作開發
版本合併 svn merge from url from ver to url to ver 意思是把from url的from ver版本到to url的to ver版本變化施加到當前工作區 比如你打branch的時候版本是a，開發完了版本是b，那麼這個命令就是把a到b做乙個diff，然後patc...