代碼版本控制
沖突的話可以分為幾種情況，這里隨便說幾種，列舉的可能不全，還有可以追問。
首先根據代碼管理器的情況，確定是否支持多簽出，如果不允許，那就基本可以確定是沖突1（說明：由於本地版本與伺服器版本不同，導致獲取伺服器版本時的沖突。該沖突多見於多人開發且分工不明確的VSS中）；如果允許多簽出，獲取文件或者簽出時會出現沖突1相同的問題，還有可能是簽入時的沖突2（說明：由於修改前版本與伺服器端版本不一致導致沖突產生。該沖突多見於SVN伺服器或特殊設置的VSS伺服器）；這兩種情況之外，還有CM對代碼分支進行合並等操作導致的沖突，這種沖突是必須的，而且大部分需要手動處理，算是沖突3。
『貳』 如何為VS2010添加版本控制
網路搜索 Visual Source Safe 2005 安裝文件，下載並保存。
2，運行setup.exe文件
3，按照步驟執行安裝，默認安裝配置即可
4，安裝完成
5，注意！！！這里要以管理員身份運行Microsoft Visual SourceSafe
6，進入設置向導，點擊下一步
7，選擇簡歷一個新的database
8，任意選擇一個文件夾來存放資料庫數據，點擊下一步，然後任意輸入資料庫的名稱
9，選擇-Modify-Merge-Model，點擊下一步，然後點擊完成
10，打開VS2010,選擇工具——選項——源代碼管理——下來列表中選擇（當前源代碼管理插件）Microsoft Visual SourceSafe——確定
11，打開現有解決方案，選擇文件--源碼管理--將解決方案添加到源代碼管理，即可
『叄』 如何把程序代碼和資料庫一起加入版本控制
那最好把每次修改的內容都保留在腳本裡面,以前的代碼不刪除,不要的就注釋起來,並且加上時間標記,你看看這樣可否滿足？版本控制的軟體挺多的vss,cvs,preforce等等,但個人都覺得不好用,沒有這種方法直觀
所有資料庫腳本 按照普通程序一樣保存為項目 代碼
更新資料庫 就更新腳本 或者增加腳本 作為增量/修改 標志
任何版本控制軟體都可以 做到
我們公司已經用了我說的方法， 為了 做 增量升級
你的腳本還必須 分好 結構 或者寫好一點 執行腳本，方便 執行 全 部署 和增量 部署 。
包括 數據結構 授權 特殊數據更新 存儲過程 觸發器 等等
就算你現在只有存儲過程，難以保證以後沒有其他的。
『肆』 版本控制在軟體開發中由誰管理
svn版本控制器安裝 分類:學習園地Subversion 系統
多年來，並發版本系統（CVS）一直是在Linux上管理代碼或者文本的標准。作為基於RCS上建立但卻允許多用戶協作的系統而言，CVS記錄所有文件的修改信息。這對於程序開發者、網路設計者和系統管理員而言，是非常有用的。
然而，CVS逐漸顯示出它的衰老，出現了相似的源代碼管理軟體。然而大多這種東西都是以牟利為主要目的的。
Subversion就是一種相對新鮮的源代碼管理系統。雖然事實上它還在不斷的反展之中，但是Subversion已經是一個非常穩定而且成熟的產品。它是一個全新的系統，其功能可以和CVS媲美，同時，它要比CVS更直觀，更容易操作。本文就Subversion的安裝和一些特殊功能作一個介紹。
安裝伺服器端
第一步：下載Apache和SVN源碼包
從官方網站台下載httpd-2.0.52.tar.gz,subversion-1.2.3.tar.gz
(因為redhat 9默認安裝的Apache沒有並包含--enable-so選項，所以無法產生mod_dav_svn.沒有這個模塊，SVN就無法採用http方式運行，所以必須重新編譯新的Apache)
以root身份執行：
#tar zxvf httpd-2.2.0.tar.gz
#cd httpd-2.2.0
#./configure --enable-dav --enable-so --enable-maintainer-mode
#make
#make install
此時會產生/usr/local/apache2目錄,接著執行:
#tar zxvf subversion-1.2.3.tar.gz
#./configure --with-apxs=/usr/local/apache2/bin/apxs
# rm /usr/local/lib/libsvn*
# make clean && make && make install
此時會自動在/usr/local/apache2/conf/httpd.conf添加
LoadMole dav_svn_mole moles/mod_dav_svn.so
安裝完成後,運行svnserver --version確認版本號1.2.3。
SVN伺服器安裝結束.
第二步，創建倉庫 svnadmin create /home/svnrepo
/root/svnrepo為所創建倉庫的路徑，理論上可以是任何目錄
第三步，修改配置文件/home/svnrepo/conf/svnserve.conf
代碼
#去掉#[general]前面的#號
[general]
#匿名訪問的許可權，可以是read,write,none,默認為read
anon-access = none
#認證用戶的許可權，可以是read,write,none,默認為write
auth-access = write
#密碼資料庫的路徑，去掉前面的#
password-db = passwd
注意：所有的行都必須頂格，否則報錯。
建議：為了防止不必要的錯誤，建議你直接用我上面的內容覆蓋掉文件原來的內容
第四步，修改配置文件passwd。
代碼
[users]
sxy = sxy
注意
1. 一定要去掉[users]前面的#,否則svn只能以匿名用戶登錄，客戶端不會出現登錄窗口，除非你的anon不為none,否則將返回一個錯誤。
2. 這里的密碼都是沒有加密的，我按照一些教程所說的用htpasswd生成的密碼無法使用。
第五步，啟動svn服務
對於單個代碼倉庫
啟動命令 svnserve -d -r /home/svnrepo --listen-host 192.168.100.200
其中-d表示在後台運行，-r指定伺服器的根目錄，這樣訪問伺服器時就可以直接用svn://伺服器ip來訪問了。如果伺服器有多ip的話--listen-host來指定監聽的ip地址.
我們可以在svn客戶端中通過svn://192.168.100.200來訪問svn伺服器
對於多個代碼倉庫,我們在啟動時也可以用-r選項來指定伺服器根目錄,但訪問時需要寫上每個倉庫相對於svn根目錄的相對路徑.
比如,我們有兩個代碼倉庫/home/repoa和/home/repob,我們用svnserve -d -r /home --listen-host 192.168.100.200來啟動,那麼在客戶端訪問時可以用svn://192.168.100.200/repoa和svn://192.168.1.200/repob來分別訪問兩個項目
啟動完成以後,我們可以用ps aux|grep svnserv來查看是否存在svnserve進程.
第六步 開放伺服器埠
svn默認埠是3690，你需要在防火牆上開放這個埠。
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 3690 -j ACCEPT
/sbin/service iptables save
你也可以通過svnserve的--listen-port選項來指定一個已經開放的其他埠,不過這樣的話客戶端使用也必須家上埠,如svn://192.168.100.200:9999/.
第七步，使用svn客戶端導入項目
推薦使用客戶端 http://tortoisesvn.tigris.org/
eclipse插件 http://subclipse.tigris.org/
附：svnserve [選項]
有效選項：
-d [--daemon] : 後台模式
--listen-port arg : 監聽埠（後台模式）
--listen-host arg : 監聽主機名或IP地址（後台模式）
--foreground : 在前台運行（調試時有用）
-h [--help] : 顯示這個幫助
--version : 顯示版本信息
-i [--inetd] : inetd 模式
-r [--root] arg : 服務根目錄
-R [--read-only] : 不贊成；使用檔案庫配置文件
-t [--tunnel] : 隧道模式
--tunnel-user arg : 隧道用戶名（模式是當前用戶UID的名字）
-T [--threads] : 使用線程代替進程
-X [--listen-once] : 監聽一次（調試時有用）
安裝客戶機端
window客戶機：
直接安裝TortoiseSVN-1.1.1-UNICODE_svn-1.1.1.msi，方法同一般軟體安裝相同。
Linux客戶機：
方法輿安裝伺服器相同。
(注意redhat 9默認安裝的SVN版本為0.17.1,它的客戶端命令svn無法輿新的SVN伺服器通訊,必須重新安裝)
我是從「上海全鼎軟體學院」畢業的————————
『伍』 什麼叫版本控制工具
現在的軟體項目開發中，必然涉及版本控制（Revision Control）工具。沒有使用版本控制工具的開發工作，有人形容就如同生活在「黑暗時代」。版本控制工具是項目開發中必不可少的，以此進行的版本控制可以確保在軟體項目開發中，不同的開發人員所涉及的同一文檔都得到更新。
關於軟體版本控制
如果在開發團隊中沒有使用版本控制，多個開發人員共同負責同一個軟體文檔的開發，每個人在各自的機器上有整個軟體文檔的備份，並對之實施編程開發，在分別完成各自任務之後，再通過文本比對工具將各自機器上的不同版本的程序整合到一台機器上。沒有進行版本控制或者版本控制本身缺乏正確的流程管理，在軟體開發過程中將會引入很多問題，如軟體代碼的一致性、軟體內容的冗餘、軟體過程的事物性、軟體開發過程中的並發性、軟體源代碼的安全性，以及軟體的整合等問題。
版本控制的目的是實現開發團隊並行開發、提高開發效率的基礎。其目的在於對軟體開發進程中文件或目錄的發展過程提供有效的追蹤手段，保證在需要時可回到舊的版本，避免文件的丟失、修改的丟失和相互覆蓋，通過對版本庫的訪問控制避免未經授權的訪問和修改，達到有效保護企業軟體資產和知識產權的目的。
版本控制的功能在於跟蹤記錄整個軟體的開發過程，包括軟體本身和相關文檔，以便對不同階段的軟體及相關文檔進行表示並進行差別分析，對軟體代碼進行可撤消的修改，便於匯總不同開發人員所做的修改，輔助協調和管理軟體開發團隊。
Linux下的版本控制
版本控制在空間上可以保證完成集中統一管理，解決一致性和冗餘問題。在開發工作中，開發人員在提交軟體代碼的時候一般採用伺服器/客戶端方式，盡管開發人員可以在自己的本地留有備份，但最終唯一有效的只有伺服器端的程序代碼；在時間上全程跟蹤記錄工具將會自動記錄開發過程中的每個更改細節，和不同時期的不同版本。這在一定程度上可以解決冗餘、事務性處理並發性問題。項目管理人員可以通過版本控制對團隊中的不同人員，實施操作許可權的控制。對於不同角色的開發人員，對軟體的不同部分可以定義不同的訪問許可權。這在一定程度可以解決軟體安全性問題。版本控制工具的使用，可以減輕開發人員的負擔，節省時間，同時降低人為錯誤。
『陸』 代碼版本控制軟體有哪些
2、常用的版本控制軟體
Perforce，StarTeam）
--------〉入門級
1.Clear case --------〉中堅級 2.CVS --------〉開源奇葩 3.Visual SourceSafe
--------〉新秀級
4.PVCS --------〉小工作組級 5 Perforce --------〉 6.CCC --------〉元老級 7.StarTeam --------〉 8.RCS --------〉元老級 9.SCCS --------〉元老級 10．Hansky Firefly 11.Others（還有一些比較少見或某個公司專用的軟體，如Seapine，北大青鳥的JBCM等）
『柒』 軟體架構選擇及代碼版本管理問題
對於版本控制，主要是你業務覆蓋。這個之前做過版本統一和 多版本落地，主要注意的是兩部分，一是抽象提取管控新定製需求，二是在已完成業務部分實現業務解耦。
這兩步就是實現你第三問的內容。需要你在業務方向上做一個規劃，至少是1年周期，想讓自己的產品大致覆蓋到什麼程度，在方向上有一個規劃。比如你做的crm，是否有客服業務、用戶激活流程粒度、許可權劃分、是否有營銷等，這些都盡可能抽取出 業務流程 ，為以後的定製，有一個定位，這種svn可以規劃在不同業務包開分支，這種分支看用戶需求採用 。
功能模塊解耦後，定製如何實現可配置，就可以並行的去重構。
所有的問題，最終還是在產品 的賣點 。做到普及定製，才是王道。
『捌』 coding 版本控制類型什麼意思
一、概述
二、Git基本概念
1、有關存儲的四個概念
2、分支（branch）
三、項目管理實戰操作
1、安裝 GHfW（GitHub for Windows）
2、在Coding上新建一個項目（新建遠程倉庫）
3、創建本地倉庫
4、GHfW 的基本使用
配置： win7 + GitHub for Windows
目標讀者：不了解Git,沒用過GitHub，想使用Coding且不想使用命令行的同學。
前言：本文的宗旨是一切從簡，只講一些必須用到的步驟和概念。
一、概述
Coding.net 是一個新近的代碼託管平台。類似於總所周知的GitHub。Coding的優點在於：一、中文界面；二、託管私人項目。缺點也有：項目的安全性還未受驗證。總之有利有弊。
本文主要介紹如何用GHfW軟體外包企業 for Windows）對Coding上的項目進行管理。
二、Git基本概念
在介紹GHfW對Coding項目管理之前，先介紹一下Git的基本概念。Git是一個版本控制系統。簡而言之是管理代碼用的。
1、有關存儲的四個概念
工作目錄（working directory）：工作目錄就是文件夾項目，它持有實際文件。
暫存區（the staging area）：暫存區就像是一個索引，把項目文件都聯系在一起。
本地倉庫（local repository）：切實進行提供版本控制的地方。
遠程倉庫（remote respository）：放在網路上的倉庫。
一個項目的納入版本控制的過程大概就是工作目錄->暫存區->本地倉庫向上逐級遞交的過程。當在項目中添加一個新的文件後，也就是在工作目錄中添加了一個文件。此時暫存區並不知道有新的文件，於是把添加新文件的事告訴暫存區，這樣新文件就被追蹤（be tracked）了，同時這個文件被加入（add）暫存區。如果修改的是已經被追蹤的文件，仍然需要在修改後將改動加入（add）暫存區。已經加入暫存區的新文件或者改動，可以提交(commit)到本地倉庫，納入版本控制系統。
當使用多個設備開發一個項目，或者多個人共同開發一個項目，遠程倉庫就派上用場了。遠程倉庫無非就是本地倉庫的一個克隆（clone）。當本地倉庫產生新的提交而產生變化之後，只要與遠程倉庫進行一下合並操作就可以讓他們保持同步。
2、分支（branch）
每次將改動提交到本地倉庫，本地倉庫並不會保存文件被修改的部分，而是保存一份快照。
此圖共有有5個Version,每個Version下有三個快照結點，Version1下方A、B、C均為實線結點，Version2下方A、C結點為實線，B結點為虛線
Git管理提交的方式
上 圖的每一列代表一次提交，每個青藍色的結點代表一個文件快照。假設本地倉庫當前在Version1，在對文件A、C做改動之後提交到了本地倉庫。那麼本地 倉庫會分別保存一份A、C的快照為A1、C1，並用一個鏈表分別指向快照A1、C1與原快照結點B，成為一次新的提交Version2。
分支的概念就是建立在這樣的基礎上的，分支是指向某次提交的指針。由於每個提交之間用一個鏈表相連接。因此一個分支就相當於是從某個提交對象往回看的歷史。
這是一個有向圖，HEAD->*develop->Version2->Version1,master->Version3
在develop分支上進行提交前
上圖中的master與develop就是兩個分支。每一次提交操作都是以某個分支為基礎的,Git為了知道當前在哪個分支上工作，保存一個名為HEAD的指針。可以把HEAD想像為當前分支的別名。（develop前面的星號（*）就是用來區分當前分支與其他分支的。）
這是一個有向圖，HEAD->*develop->Version3->Version2->Version1,master->Version3
在develop分支上進行提交後
當有新的提交產生時，HEAD會指向該新提交，也即當前分支指向新的提交。例如上圖就是在develop分支上進行了一個次新的提交Version3。
三、項目管理實戰操作
1、安裝 GHfW（GitHub for Windows）
下載鏈接：
安裝過程一鍵完成。
2、在Coding上新建一個項目（新建遠程倉庫）
依次是項目名稱、項目描述、是否公開、是否啟用README.md，許可證，添加gitignore文件
新建項目頁面
README：一般項目中都會添加一個README文件對項目進行概述，以便一目瞭然地知道這個項目是做什麼用的，如何使用等信息。README文件採用markdown語法書寫。
開源許可證：定義該項目的傳播方式，比如他人是否可以商業化使用該項目，他人是否可以隨意傳播、發布、更改該項目。
.gitignore文件：該文件可以定義哪些文件不添加到倉庫中，比如項目產生的臨時文件。
3、創建本地倉庫
打開GitHub客戶端，打開的時候該客戶端會要求輸入GitHub的賬戶和密碼，如果沒有GitHub賬戶直接跳過就好了。
在Coding新建的項目頁面左上角會有如下鏈接：遠程倉庫的鏈接地址
點中該鏈接並直接拖放到GitHub客戶端窗口。在彈出窗口中設置本地倉庫的路徑。如此一來遠程倉庫就克隆到本地倉庫了。
4、GHfW 的基本使用
整個界面大概分為 新項目添加、項目列表、當前分支、文件提交、未同步到遠程倉庫的文件列表、已同步的提交歷史、以暫存的文件、同步到遠程倉庫、設置等九個部分
GHfW界面說明
在工作目錄中對文件進行增刪改等操作後，在GHfW窗口勾選需要提交的修改。然後對這次提交進行描述後提交。最後再把修改同步到遠程倉庫。
『玖』 代碼版本控制用SVN還是Git好
SVN屬於被淘汰的上一代版本管理工具。用SVN，你就屬於被淘汰的一類。
GIT牛掰不僅僅是牛掰在離線提交這個方面。事實上本座的團隊使用GIT根本沒有考慮是否能離線提交，每個開發人員基本上走到哪裡都可以有網，離不離線不是關鍵問題。
GIT牛掰的地方在於對分支管理，子項目依賴，代碼沖突管理上比SVN高出不止一個數量級。
舉個例子：用一個開源的庫，我們需要對開源的庫某些部分進行修改，但是又想保證該庫緊跟官方發布不過時。用SVN的話，要不一切手動，要不你就把你的修改提交到官方源去（基本上是不可能的）。用GIT，我可以克隆一個repository，新建一條branch保持私有修改，官方庫有更新隨時pull --rebase。
GIT的commit還可以亂序修改。比如說隊里的熊孩子搞砸了，一連幾個commit都不能編譯。太簡單了：用git rebase -i可以把一條branch上的壞commit一個一個剔掉。換了SVN，提交了壞代碼的話，天皇老子都沒法改。
GIT的高級玩法多了去了。學習曲線比SVN要陡，但是培訓下團隊完全是值得的。現在業界主流都用GIT，數不清的各種工具和雲服務都基於GIT。上Github下個代碼，人家很瀟灑地一站式git clone，你下個zip再解包不寒磣？
就算你是單干，GIT也比SVN好用的多。用SVN如果不用雲服務的話你還得自己架一個SVN伺服器，GIT的話直接本地repository。