SCM版本控制梳理——以git爲例

0.什麼是SCM

首先咱們平時用的什麼git，svn啥的都屬於SCM。SCM（Software Configuration Management，軟件配置管理）是一種標識、組織和控制修改的技術。它應用於整個軟件生存期。 最原始古老的方法是採用手工管理版本的方式，例如當一個新版本產生時用當時的日期來命名文件夾，而後再複製一下之後的修改在複製的文件夾內進行，這樣上一個版本就被保存下來了，周而復始不一樣的版本不會被覆蓋。雖然這種方式能夠從某種程度上解決版本的回溯問題，但他存在的缺點是顯而易見的：第一點若是保留結果過於頻繁，將會致使產生大量的有着重複內容的文件夾和龐大的物理空間佔用，管理起來很麻煩；若是保留舊版本的時間間隔太長，可能產生某些有用的老程序沒法回溯。第二容易產生版本的混亂，若是是團隊開發軟件，這種簡單的方法更難解決問題的本質了。

幾乎全部的SCM都離不開三大基本步驟1.Get Latest Version 2.Check Out 3.修改完後Check In。
以git爲例，分別是

1. 從git取數據（git clone）
2. 改動代碼
3. 將改動傳回git（git push）

1, 3兩個步驟涉及到remote server/remote repository/remote branch，2涉及到local repository/local branch。git clone 會根據你指定的remote server/repository/branch，拷貝一個副本到你本地，再git push以前，你對全部文件的改動都是在你本身本地的local repository來作的，你的改動(local branch)和remote branch是獨立（並行）的。Gitk顯示的就是local repository。

1.創建和github遠程倉庫之間的可靠鏈接

一切在本地作好的改動，最終都是須要上傳到遠程倉庫的，因此首先要創建和github遠程倉庫的可靠鏈接。有多種方式能夠選擇，常見的有https協議和ssh協議兩種方式。ssh的方式，直接在本地管理密鑰，安全也更爲方便。打開git終端輸入ssh-keygen -t rsa -C 「youremail@example.com」。後面的 your_email@youremail.com 改成你在 Github 上註冊的郵箱，以後會要求確認路徑和輸入密碼，咱們這使用默認的一路回車就行。成功的話會在 ~/ 下生成 .ssh 文件夾，進去，打開 id_rsa.pub，複製裏面的 key。
回到 github 上，進入 Account => Settings（帳戶配置）。




左邊選擇 SSH and GPG keys，而後點擊 New SSH key 按鈕,title 設置標題，能夠隨便填，粘貼在你電腦上生成的 key。


爲了驗證是否成功，輸入如下命令：

$ ssh -T git@github.com
Hi tianqixin! You've successfully authenticated, but GitHub does not provide shell access.

說明咱們已成功連上 Github。

2.創建github遠程倉庫

經過github創建遠程倉庫的好處不言而喻。可是對於咱們獨立的開發者，如何從無到有創建一個遠程倉庫，建完倉庫以後如何去添加代碼呢？首先在github的網頁上，點擊(New repository)新建倉庫，輸入該倉庫的名稱，選擇私有仍是公開和其餘信息便可。

建立完這個空殼後，須要把項目文件放上去。 這個時候git的遠程倉庫中一開始沒有代碼，就須要從本地上傳代碼到git的遠程倉庫。 通常github會提示你對新建的倉庫進行一下三種操做來充實這個剛剛建立的倉庫。

1. 快速設置。這個是系統默認的方式，會給項目自動添加README,LICNESE和gitignore三個文件
2. 經過命令行手動建立。
3. 經過命令行手動導入一個現有的本地倉庫到這個遠程倉庫。

通常而言，用戶第一次使用git，連本地的git倉庫都沒有，因此須要按照github提示的語句建倉並提交遠程倉。具體以下：

echo 「# mediago」 >> README.md
git init
git add README.md
git commit -m 「first commit」
git remote add origin git@github.com:yourusername/repositoryname.git
git push -u origin master

每一個步驟的詳細解釋以下：首先是初始化本地倉庫，用init命令新建一個git。在本地的git的bash下，切換到須要執行git的目錄，而後git init初始化git，就在當前目錄下生成了.git文件夾（一般來講是隱藏文件夾），這裏面有git管理的一切信息。而後輸入

git add .

注意add和.之間有一個空格。這句話的意思是把當前目錄下的全部文件添加到git的本地暫存區中。 而後再出入

git commit -m 「first commit」

這句話表示確認暫存區的內容，並正式提交本地暫存區的內容到本地倉庫。

（這裏插上一段，若是輸入git commit，不輸入-m 「」直接回車，會進入vim或者nano界面讓你編輯commit文件。固然，有解決方式，具體見如此連接。
爲了不麻煩，仍是輸入-m吧。另外commit -m和-am是有區別的。-am是直接不須要add就能提交，對於-m,若是改動了文件而沒有add，直接commit -m是沒用的。參見）

至此，本地倉庫創建完成。

git push origin xxx 表示推送到遠程倉庫
PS:xxx表示遠程倉庫的分支名，若是在第一次鏈接遠程倉庫時將本地與遠程倉庫的分支關聯，後續提交時候能夠直接輸入 git push origin master 。具體方法以下：先執行

git remote add origin git@github.com:user/yourRepository.git。

這句話至關於爲遠程倉庫建立了一個在本地的別名。這裏的origin可能比較難理解，其實把它理解爲 git@github.com:user/yourRepository.git 就能夠了。
origin就是一個名字，或者一個標籤。爲何我這裏選擇origin，由於若是經過clone區克隆一個託管在Github上代碼庫時，git爲你默認建立的指向這個遠程代碼庫的標籤就是origin。

個人版本輸入git branch只能查看本地倉庫的分支。輸入git branch -a或者 git branch -r能夠查看當前git下的全部分支。以下圖所示：

最後，git push -u origin master。-u這個參數表示，若是你下次須要在這個目錄下push，就不須要打origin master，直接git push 就能夠了。把commit以後的本地倉庫所有push更新到遠程倉庫中去。固然，也能夠不經過命令行的方式。在github網站的頁面上，進入本身的倉庫，點擊uploadfiles按鈕也能夠上傳本地文件。

3.用github開發和維護項目

前面說到， 用git進行開發有三大步驟。

1. 從git取數據（git clone）
2. 改動代碼
3. 將改動傳回git（git push）

第一步1是本地不存在代碼的狀況。因此才須要去clone。clone適用的場景是已經在遠程倉庫存在一個比較成熟的項目了，而後開發者本地沒有代碼的狀況下，才須要clone。clone完成後再本地遠程倉庫的別名就是origin，這個是默認的。若是遠程倉庫的代碼就是從本地上傳的，或者做者很清楚本地倉庫的代碼就是以前已經從遠程倉庫clone過來的，那就不要進行第一步git clone，直接進入本地git的目錄操做便可。

重點仍是在改動代碼這一塊。一般的操做是改完以後執行git add 「文件名」，git commit -m 「commit標記」，git pull(一般是git pull origin master)三連操做。add比較好理解，改了哪些文件就add哪些。其實就是把代碼放到臨時區。commit 是爲了告訴 git 我此次提交改了哪些東西，否則你只是改了可是 git 不知道你改了,也就無從判斷比較;

重點是pull它是git fetch再git merge的意思。
執行了pull以後，若是本地的這幾個 commit 和遠程的 commit 有衝突的部分就merge,而後根據提交時間排序再新建一個merge 的 commit 記錄 。對於本地 commit 和遠程commit 的對比記錄,git 是按照文件的行數操做進行對比的,通常狀況自動merge就能結局問題。可是若是同時操做了某文件的同一行那麼就會產生衝突,git 也會把這個衝突給標記出來,這個時候就須要先把和你衝突的項目成員拉過來問問保留誰的代碼,而後在 git add && git commit && git pull 這三連,再次 pull 一次是爲了防止再大家協商的時候另外一我的給又提交了一版東西,若是真發生了那流程重複一遍,一般沒有衝突的時候就直接給你合併了,不會把你的代碼給覆蓋掉。

不commit，就會出現代碼覆蓋或者丟失的狀況:好比A B兩人的代碼pull 時候的版本都是1,A在本地提交了2,3而且推送到遠程了,B 進行修改的時候沒有commit 操做,他先本身寫了東西,而後 git pull 這個時候 B 本地版本已經到3了,B 在本地版本3的時候改了 A 寫過的代碼,再進行了git commit && git push 那麼在遠程版本中就是4,並且 A 的代碼被覆蓋了,因此說全部人都要必定要先 commit 再 pull！

4.補充

上面提到的git pull只是爲了樹立整個git的流程，實際上，須要儘可能少用git pull。

git pull的問題是它把過程的細節都隱藏了起來，以致於你不用去了解git中各類類型分支的區別和使用方法。固然，多數時候這是沒問題的，但一旦代碼有問題，你很難找到出錯的地方。git的使用文檔有以下說明：

將下載（fetch）和合並（merge）放到一個命令裏的另一個弊端是，你的本地工做目錄在未經確認的狀況下就會被遠程分支更新。固然，除非你關閉全部的安全選項，不然git pull在你本地工做目錄還不至於形成不可挽回的損失，但不少時候咱們寧願作的慢一些，也不肯意返工重來。

5.常見問題

在執行git pull的時候，報錯:There is no tracking information for the current branch。這經常是由於偷懶直接寫了git pull而沒有加上其餘信息。本地分支和遠程分支沒有創建聯繫 (使用git branch -vv 能夠查看本地分支和遠程分支的關聯關係) .根據命令行提示只須要執行如下命令便可

git branch –set-upstream-to=origin/遠程分支的名字 本地分支的名字

或者勤快一點，每次都加上遠程分支的名字git pull origin master

可是問題又來了，輸入git pull origin master提示refusing to merge unrelated histories。緣由是 git 會發現這兩個倉庫可能不是同一個，爲了防止開發者上傳錯誤，因而就給了這個的提示。若是確認兩個倉庫都是本身的沒問題，咱們須要這樣寫git pull origin master --allow-unrelated-histories。

這個方法只解決由於兩個倉庫有不一樣的開始點，也就是兩個倉庫沒有共同的 commit 出現的沒法提交。若是使用本文的方法還沒法提交，須要看一下是否是發生了衝突，解決衝突再提交。解決衝突的方法具體見這篇博文或者廖雪峯的文章。

6.其餘指令熟悉

git status –查看當前代碼狀態，改動，所在分支，是否有代碼衝突等 
git ls-files –查看當前分支下暫存區文件
git branch -a –查看當前主幹下有哪些分支 
git checkout –切換分支 
git diff –查看分支代碼改動
git rm –刪除文件