版本控制

1：版本控制概念

版本控制最主要的功能就是追蹤文件的變更。它將什么時候、什么人更改了文件的什么內容等信息忠實地了記錄下來。每一次文件的改變，文件的版本號都將增加。除了記錄版本變更外，版本控制的另一個重要功能是并行開發。軟件開發往往是多人協同作業，版本控制可以有效地解決版本的同步以及不同開發者之間的開發通信問題，提高協同開發的效率。并行開發中最常見的不同版本軟件的錯誤(Bug)修正問題也可以通過版本控制中分支與合并的方法有效地解決。
具體來說，在每一項開發任務中，都需要首先設定開發基線，確定各個配置項的開發初始版本，在開發過程中，開發人員基于開發基線的版本，開發出所需的目標版本。當發生需求變更時，通過對變更的評估，確定變更的影響范圍，對被影響的配置項的版本進行修改，根據變更的性質使配置項的版本樹繼續延伸或產生新的分支，形成新的目標版本，而對于不受變更影響的配置項則不應發產生變動。同時，應能夠將變更所產生的對版本的影響進行記錄和跟蹤。必要時還可以回退到以前的版本。例如當開發需求或需求變更被取消時，就需要有能力將版本回退到開發基線版本。在曾經出現過的季度升級包拆包和重新組包的過程中，其實就是將部分配置項的版本回退到開發基線，將對應不同需求的不同分支重新組合歸并，形成新的升級包版本。
版本控制是軟件配置管理的核心功能。所有置于配置庫中的元素都應自動予以版本的標識，并保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，為了配合軟件開發流程的各個階段。還需要定義、收集一些元數據來記錄版本的輔助信息和規范開發流程，并為今后對軟件過程的度量做好準備。當然如果選用的工具支持，這些輔助數據將能直接統計出過程數據，從而方便軟件過程改進活動的進行。對于配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設置相應的訪問權限。一般來說，對于基線版本之前的各個版本都應處于被鎖定的狀態,如需要對它們進行變更，則應按照變更控制的流程來進行操作。
版本控制(Revision contro1)是一種在開發的過程中用于管理我們對文件、目錄或工程等內容的修改歷史，方便查看更改歷史記錄，備份以便恢復以前的版本的軟件工程技術。簡單來說就是用于管理多人協同開發項目的技術。
沒有進行版本控制或者版本控制本身就缺乏正確的流程管理，在軟件開發過程中將會引入很多問題,如軟件代碼的一致性、軟件內容的冗余、軟件過程的事物性、軟件開發過程中的并發性、軟件源代碼的安全性，以及軟件的整合等問題。無論是工作還是學習，或者是自己做筆記，都經歷過這樣一個階段!我們就迫切需要一個版本控制工具。(多人開發就必須要使用版本控制)

2：版本控制的功能

（1）檢入檢出控制

軟件開發人員對源文件的修改不能在軟件配置管理庫中進行，對源文件的修改依賴于基本的文件系統并在各自的工作空間下進行。為了方便軟件開發，需要不同的軟件開發人員組織各自的工作空間。一般說來，不同的工作空間由不同的目錄表示，而對工作空間的訪問，由文件系統提供的文件訪問權限加以控制。訪問控制需要管理各個人員存取或修改一個特定軟件配置對象的權限。開發人員能夠從庫中取出對應項目的配置項進行修改，并檢入到軟件配置庫中，對版本進行“升級”;配置管理人員可以確定多余配置項并刪除。
同步控制的實質是版本的檢入檢出控制。檢入就是把軟件配置項從用戶的工作環境存入到軟件配置庫的過程，檢出就是把軟件配置項從軟件配置庫中取出的過程。檢人是檢出的逆過程。同步控制可用來確保由不同的人并發執行的修改不會產生混亂。

（2）分支和合井

版本分支(以一個已有分支的特定版本為起點,但是獨立發展的版本序列)的人工方法就是從主版本一稱為主干上拷貝一份，并做上標記。在實行了版本控制后，版本的分支也是一份拷貝，這時的拷貝過程和標記動作由版本控制系統完成。版本合并(來自不同分支的兩個版本合并為其中一個分支的新版本)有兩種途徑，一是將版本A的內容附加到版本B中;另一種是合并版本A和版本B的內容，形成新的版本C。

（3）歷史記錄

版本的歷史記錄有助于對軟件配置項進行審核，有助于追蹤問題的來源。歷史記錄包括版本號、版本修改時間、版本修改者、版本修改描述等最基本的內容，還可以有其他一些輔助性內容，比如版本的文件大小和讀寫屬性。

3：版本控制的流程

（1）創建配置項。

項目成員依據《配置管理計劃》，在配置庫中創建屬于其任務范圍內的配置項。此時配置項的狀態為“草稿”其版本號格式為 8.YZ。

（2）修改狀態為“草稿”的配置項目。

項目成員使用配置管理軟件的 Check in/check out 功能，可以自由修改處于“草稿”狀態的配置項,版本號格式為0.YZ。

（3）技術評審或領導審批。

如果配置項是技術文檔，則需要接受技術評審。如果配置項是“計劃”這類文件，則需要項目經理(或上級領導)的審批。若配置項通過了技術評審或領導審批，則轉向下一步·否則轉回上一步。

（4）正式發布。

配置項通過技術評審或領導審批之后。則配置項的狀態從“草稿”變為“正式發布”，版本號格式為
X.Y。

（5）變更。

修改處于“正式發布”狀態的配置項，必須按照“變更控制流程”執行。

4：版本控制的優勢

實現跨區域多人協同開發
追蹤和記載一個或者多個文件的歷史記錄
組織和保護你的源代碼和文檔
統計工作量
并行開發、提高開發效率
跟蹤記錄整個軟件的開發過程
減輕開發人員的負擔，節省時間，同時降低人為錯誤

版本控制的分類

1：本地版本控制

許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這么做唯一的好處就是簡單，但是特別容易犯錯。 有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。
為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的數據庫來記錄文件的歷次更新差異。但是，它的最大的弊端就是無法讓位于不同系統上的開發者協同工作。

2：集中化的版本控制

為了解決不同開發者之間的協同工作，集中化的版本控制系統(centralized version contro]Systems，簡稱 CVCS)應運而生。這類系統，諸如 CVS、Subversion 以及 Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這已成為版本控制系統的標準做法。
這種做法帶來了許多好處，特別是相較于老式的本地 S 來說。 現在，每個人都可以在一定程度上看到項目中的其他人正在做些什么。而管理員也可以輕松掌控每個開發者的權限,并且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕松容易。
事分兩面，有好有壞。 這么做最顯而易見的缺點是中央服務器的單點故障。 如果宕機一小時，那么在這一小時內，誰都無法提交更新，也就無法協同工作。 如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問你將丟失所有數據–包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。 本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。

3：分布式版本控制

為了避免中央服務器的單點故障,于是分布式版本控制系統(Distributed Version Control system,
簡稱 DVCS)面世了。
在這類系統中,像 Git、Mercurial、Bazaar 以及 Darcs 等,客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來，包括完整的歷史記錄。這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。
更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。 你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。這就是git 分布式版本系統的優勢。

常見的版本控制系統介紹

1：Git

Git(讀音為/git/)是一個開源的分布式版本控制系統，可以有效、高速地處理從很小到非常大的
項目版本管理。也是Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。
Git 的優勢就是:每個人都擁有全部的代碼，可以避免一些安全隱患。不會因為服務器損壞或者網絡問題，造成不能工作的情況。
所有版本信息倉庫全部同步到本地的每個用戶，這樣就可以在本地查看所有版本歷史，可以離線在本地提交，只需在連網時 push 到相應的服務器或其他用戶那里。由于每個用戶那里保存的都是所有的版本數據，只要有一個用戶的設備沒有問題就可以恢復所有的數據，但這增加了本地存儲空間的占用。
Git 是分布式版本控制系統，沒有中央服務器，每個人的電腦就是一個完整的版本庫，工作的時候不需要聯網了，因為版本都在自己電腦上。協同的方法是這樣的:比如說自己在電腦上改了文件 A，其他人也在電腦上改了文件 A，這時，你們兩之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。Git 可以直接看到更新了哪些代碼和文件!

2：GitHub

GitHub 是一個面向開源及私有軟件項目的托管平臺，因為只支持 Git 作為唯一的版本庫格式進行托管，故名 GitHub。GitHub 可以提供給用戶空間創建 Git 倉儲,保存用戶的一些數據文檔或者代碼等GitHub 作為開源代碼庫以及版本控制系統，目前擁有 140 多萬開發者用戶。隨著越來越多的應用程序轉移到了云上，GitHub 已經成為了管理軟件開發以及發現已有代碼的首選方法。GitHub 可以托管各種Git 庫，并提供一個 Web 界面，但與其它像 SourceForge 或 Google code 這樣的服務不同，GitHub的獨特賣點在于從另外一個項目進行分支的簡易性。
GitLab 是一個基于 Git 的項目管理軟件,用于倉庫管理系統的開源項目。使用 Git 作為代碼管理工具，并在此基礎上搭建起來 web 服務。Git、Gitlab、Github 都是基于 Git 的，可以說是 Git 的衍生品。

3：GitLab

Gitlab 是一款自由和免費的開源軟件，因此不需要編寫許可證或購買許可證。它允許開發者將源代碼托管到自有服務器或者像 Gitlab.com 這樣的云端服務器上。這個免費的模式非常適合中小型企業開發者，可以獲得許多強大的功能，如代碼分枝、分支合并、查看歷史變更等
Gitlab 非常易于使用和管理。它提供了一個友好的 web 界面，可以讓開發者在瀏覽器中完成 Git 的核心操作。它為用戶提供了許多簡單易用的功能，如 API、集成、安全，以及其他一些其他的托管服務功能。除此之外，Gitlab 管理界面也很直觀，可以方便的管理用戶權限和代碼基礎設施的其他方面。

4：其他版本控制系統

其他開放源碼的版本控制工具還有有很多，如 Concurrent Versions system(csv)、Subversion(SVN)、Vesta、Revision Control System(Rcs)、Source code control system(sccs)等。比較常用的兩個工具是 CVS 和 SVN。CVS 是 Dick Grune在 1984年~1985 年基于 RCS 開發的一個客戶一服務器架構的版本控制軟件，長久以來一直是免費版本控制軟件的主要選擇。SVN的一個重要開發目標是修正 CVS 中廣為人知的缺點，提供一個新的版本控制軟件。對于中小規模團隊，SVN 是一個比較好的開源版本控制工具，SVN 常用客戶端工具為TortoiseSVN。

Git的工作原理

1：Git的核心概念

Git 是一個分布式版本控制系統，它的核心是 Git 對象、Git 樹和提交(快照)歷史鏈這三個概念。Git 原理的核心可以概括為以下幾點:

（1）Git 對象

Git 中的所有數據都存儲在 Git 對象中。每個 Git 對象都由一個 SHA-1 校驗和作為唯一的標識符,可以是文件內容、目錄結構或者版本歷史等。

（2）Git 樹

Git 樹是由 Git 對象組成的一個目錄結構，保存了文件夾、文件和子樹的信息，每個樹對象都包含一個或多個子對象的引用。

（3）提交歷史鏈

每個提交對象都可以有一個或多個父對象，形成一個提交歷史鏈。通過這個提交歷史鏈，Git 可以跟蹤每個文件的修改歷史，也可以方便地進行版本回滾、分支合并等操作。

（4）Git 分支

分支是指向 Git 倉庫中某一次提交的一個指針，也就是一個指向 Git 提交歷史的引用。每個分支都包含了 Git 倉庫中的一個提交對象，這個提交對象指向了你項目的一個特定狀態。

（5）Git 工作區

工作區是文件的實際工作目錄，是你在電腦上看到的目錄。在執行“git add” 命令前，工作區的文件修改和添加不會被 Git 跟蹤。

（6）Git 暫存區

暫存區是一個臨時的存儲區域，用于存儲將要提交的文件和修改。在執行“git add”命令時，修改的文件會被保存到暫存區中。

（7）Git 遠程倉庫

遠程倉庫是指存儲在遠程服務器上的 Git 倉庫，用于多人協作開發、備份和共享代碼。Git 支持多種協議，如 HTTPS、SSH 等，可以通過、gitremote、命令管理遠程倉庫。
Git的強大之處在于它的分布式特性和提交歷史鏈的設計,使得團隊協作和代碼管理更加方便和高效。

2：git的存儲

Git 的工作流程可以簡單概括為將工作目錄(working directory)的修改提交到暫存區(stagingarea)，再將暫存區的修改提交到本地倉庫(1ocal repository)，最后將本地倉庫的修改推送到遠程倉庫(remote repository)。
在 Git 中，對象分為三種類型:blob、tree 和 commit。blob 對象表示文件內容;tree 對象表示文件夾或目錄結構;commit 對象表示一個提交或快照，commit 對象包含作者、時間戳、提交信息等版本信息。每一次我們修改文件，Git 都會完整的保存一份這個文件的快照而非記錄差異。每次提交到暫存區的時候,都會把需要暫存文件的副本放到倉庫里面(為blob對象)并為每個blob對象生成一個sha-1,這一堆 blob 對象包括當前暫存的所有修改。
提交的時候，生成一個快照(一堆暫存的 blob 對象和沒有變化的對象就形成了當前修改的一個快照,是一個 tree 對象)，并生成一個提交對象包含這個快照的指針，并包含一些提交信息。同時還有一個或者多個指針指向當前提交的前一次提交。
每次提交會生成一個校驗和，這個校驗和就唯一指定一個提交。所以一次提交就相當于給整個庫打了一個不可變的快照。
git add 添加文件到暫存區，并且創建數據對象添加到 tree 對象中且記錄到 git 數據庫git commit 然后把以上的 tree 對象添加到 commit 對象中記錄到 git 數據庫中。

3：相關概念

(1)Git 的標簽(Tag)管理
Git 支持標簽管理，可以給代碼庫中的某個版本打上標簽，方便以后查找和回滾到指定版本。

(2)Git 的遠程倉庫管理
Git 可以將本地倉庫推送到遠程倉庫進行備份或共享。常用的遠程倉庫有 GitHub、GitLab、Bitbucket 等，Git 支持多種協議進行遠程倉庫之間的數據傳輸，如 HTTPS、SSH 等。

(3)Git的鉤子(Hook)
Git 的鉤子是一種腳本,可以在 Git 命令執行前或執行后自動觸發,用于實現自定義的功能。Git 支持多種鉤子，如提交鉤子、合并鉤子等。

(4)Git的子模塊(Submodule)
Git的子模塊是一種管理外部代碼庫的方式,可以將外部代碼庫嵌入到主代碼庫中,方便管理和維護。

(5)Git的工作流(Workflow)
Git 支持多種工作流，如集中式工作流、功能分支工作流、Gitflow 工作流等，可以根據項目需求選擇不同的工作流進行代碼管理和版本控制。

部署Git服務器

1：基礎環境

一臺git一臺client，需要時間同步



兩臺都安裝git

2：服務器端基本設置

初始化git倉庫

在本案例中，我們要將該服務器初始化為遠程倉庫，提供給其他開發人員用來提交項目，在初始化的時候，需要加上–bare 的選項。

備注:
git init:建立一個標準的 git 倉庫，它將我們所在的目錄轉換為一個 Git 本地倉庫。
建立一個標準的 Git 倉庫，這樣的倉庫初始化后，其項目目錄為工作空間，其下的.git 目錄是版本控制器。git init 命令執行后會在本地生成一個.git 的文件夾，用來追蹤倉庫的所有變更。

git init–bare:它將我們所在的目錄指定為遠程服務器倉庫。這樣的倉庫初始化后，其項目目錄下就是標準倉庫.git 日錄里的內容，沒有工作空間。這個倉庫只保存git 歷史提交的版本信息，而不允許用戶在上面進行各種 git 操作(如:push、commit 操作)。但是,你依舊可以使用 git show 命令查看提交內容。

3：客戶端基本信息設置

設置密鑰對，免輸入密碼

從git服務器中克隆版本倉庫到本地

此時會在當前目錄下生成一個空目錄，這個步驟的目的是將服務器端的項目(空項目)克隆到本地，這樣就在本地建立了一個代碼庫，開發者就可以基于此代碼庫進行程序開發。之后就可以將代碼從本地提交到遠程的代碼庫了。

配置用戶信息

4：代碼提交操作

編寫代碼

添加到暫存區

備注:
“git add.”命令可以將當前目錄中的所有文件添加到暫存區。

添加到本地倉庫
備注:
-m:m指的是 message，可以是一些備注信息
-a:用于先將所有工作區的變動文件，提交到暫存區，再運行git commit。用了-a參數,就不用執行“git add .”

注意:
git commit -m 只是 git add 之后文件放在在暫存區之后的提交，如果暫存區沒有 add，是沒有效果的。
git commit -am 是之前提交過到工作區的日志信息已經存在(git commit -m “日志信息”文件名)已經執行過，再執行同樣的日志信息可以不用 add，一步到位

為當前版本庫設置標簽


master 分支是當前主分支的最新版本，上一步中為代碼版本打過標簽后沒有再提交過新的代碼，所以查看到的是相同的內容。

修改文件內容


查看工作狀態

添加遠程版本庫

注意:
在克隆了一個遠程倉庫到本地的時候，已經在本地自動添加了名稱為origin 的遠程倉庫，如果想設置其他的倉庫名稱，可以使用 git remote add 的命令進行添加。

備注:
如果要刪除一個遠程倉庫，可以使用命令:
git remote remove gitserver

上傳代碼

為了驗證文件是否推送到遠程的 Git服務，可以換個目錄(或主機)再次克隆一份版本倉庫

備注:
指定標簽下載對應的版本
不指定版本默認下載的最新的版本
git clone -b v1.1 root@192.168.207.137:/opt/mypro.git
git clone -b v1.2 root@192.168.207.137:/opt/mmypro.git
git clone -b master root@192.168.207.137:/opt/mypro.git

-b master 的參數可以省去，默認就是克隆master 分支的當前版本

部署GitLab服務器

1：基礎環境

需要時間同步，另一臺client可以繼續使用

2：安裝GitLab

3：修改配置文件

4：加載配置文件并啟動

注意80端口不能被占用

備注:
重啟:gitlab-ctl restart
關閉:gitlab-ctl stop
啟動:gitlab-ctl start
狀態:gitlab-ctl status
幫助:gitlab-ctl–help

5：訪問

查看密碼

6：修改密碼

7：設置可以導入的類型

8：創建項目

客戶機克隆空項目

創建本地代碼

提交暫存區

從暫存區提交到本地倉庫

分支命名

為客戶端設置 GitLab 為遠程倉庫

將分支版本提交到遠程倉庫

-u:相當于記錄了 push 到遠端分支的默認值，這樣當下次我們還想要繼續 push 的這個遠端分支的時候推送命令就可以簡寫成 git push 即可
-f:強制更新，需要 gitlab 權限允許。

設置權限允許強制更新

9：創建新用戶

添加組


添加用戶


備注:
access level:用戶地訪問級別。
Regular:普通用戶，只能訪問屬于他自己的組和項目Admin:管理員，可以訪問所有的組合項目

設置密碼


將用戶加入組

Gitlab 用戶在組里面有5種不同權限:
Guest:可以創建 issue、發表評論，不能讀寫版本庫。
Reporter:可以克隆代碼，不能提交，QA、PM可以賦予這個權限
Developer:可以克隆代碼、開發、提交、push，普通開發可以賦予這個權限。
Maintainer:可以創建項目、添加 tag、保護分支、添加項目成員、編輯項目，核心開發可以賦予這個權限。
0wner:可以設置項目訪問權限:-Visibility Level、刪除項目、遷移項目、管理組成員，開發組組長可以賦予這個權限。

10：在用戶組中創建項目

以zhangsan身份登錄

重新設置密碼后添加項目

選擇導入項目

添加倉庫的url
此處，我們選擇一個 gitee 上的開源項目 mall，其連接如下:
https://gitee.com/kgc-wjq/league.git

注意:
此處設置的訪問級別為Private，在客戶端進行克隆的時候，就需要輸入 zhangsan 的賬號密碼進行身份認證后才能克隆下來。如果選擇Public，在克隆的時候就不需要身份驗證了。

驗證結果


在客戶機克隆