手把手教你如何進行 代碼版本控制

請各位讀者添加一下做者的微信公衆號，之後有新的文章，將在微信公衆號直接推送給各位，很是感謝。

0.前言

---

注意：若文章中出現圖片沒法加載的狀況，請移步做者的其餘博客。

• 簡書
• CSDN

最近 S 君進入某互聯網公司進行開發，但是進入公司工做的第一件事就是要將本身天天開發的成果遞交給老大。

但是，這時候 S 君遇到一個問題。

「大家天天的代碼要上傳到倉庫裏，記得檢查衝突。」

倉庫？代碼上傳？這些都是什麼意思呀？

抱着試試看的心態，S 君找到了我，因而也就有了今天的文章。

1.版本控制

---

首先在文章的開始前，先來介紹一下，什麼叫作版本控制。

版本控制(Revision control)是一種軟體工程技巧，籍以在開發的過程當中，確保由不一樣人所編輯的同一檔案都獲得更新。

說白了，所謂的版本控制其實就是咱們在平常的開發過程當中，將天天、每一個階段、每一個功能等要求完成以後，將咱們的代碼再提供給他人的一種行爲。

這個行爲的目的就是，讓每個人的開發過程都有據可查，最後實現多人合做開發的目的。

而版本控制的過程當中，很是重要的一個問題就是，儲存庫（也就是倉庫）的建立。

接下來咱們來介紹一下，關於倉庫的概念。

2.數據倉庫

---

通常在開發的過程當中，項目 leader 通常會將大家的項目倉庫進行劃分。

可是通常來講，無論怎麼劃分，都離不開如下幾個內容。

首先來講一下上圖中出現單詞的含義。

• Master ： 領導，通常是大家 leader
• Hotfix ： 熱修復，通常是有問題了，以後通知用戶本身下載補丁
• Release ：發佈，就是上線了
• Develop ：開發者，不用說了，就是咱們
• Feature ：特點，備用版本

除此以外，在開發過程當中，其實跟程序息息相關的倒是另外幾個倉庫。

這裏會設計到一些公司 CTO 的想法和意見，因此每一個公司都不相同，請選擇查看。

通常公司內部都會有一個研發規範，而我們須要注意的就是在研發規範中，對於倉庫的使用。

PS:我竟然能找到這個，當時本身都驚了。

倉庫名稱	穩定程度	權限	說明
branches	開發分支，不穩定	開發team有權限	有開發任務時，從trunk打分支到branches，分支命名以dev_爲前綴，加上日期（若是trunk分支在測試且證實極度不穩定，想取穩定分支，從tags取）。開發完成時，而且開發自測完成，由研發Leader合併到主幹trunk，測試從trunk發包進行測試。
trunk	主幹分支，趨於穩定	開發Leader有權限	最新趨於穩定版本代碼存放地。開發Leader有權限從開發分支merge代碼到主幹，而後質量部進行測試，測試經過由運維部打上線分支到tags。研發leader要控制trunk的時序性。（也就是說盡可能避免一個brances合併到trunk進行測試以後，在沒有完成測試前又合併一個分支，致使測試返工。）
tags	上線分支，穩定	運維有權限	方便回滾和記錄。以日期命名，如201 *

實際開發中，大概就是這個樣子。

固然，若是大家公司使用的是 Git ，其實效果也是同樣，具體的都會由大家 leader 來完成。

3.版本控制的工具

---

上面說了這麼多的內容，咱們在開發的過程當中，使用到了各類倉庫。

能夠，咱們又回到了 S 君的問題，就是，咱們怎麼去進行版本控制呢？

在此，我想說明的是，若是遇到一個問題，你第一個反應不該該是去詢問他人，而是看看本身是否可以解決。你是本身查詢資料也好，是在網絡上搜索也罷，只要是你本身獨立解決的問題，你的記憶會很是深入的。

好了，迴歸正題。

關於代碼版本控制經常使用的兩個倉庫分別是 SVN 和 Github，固然，也有不少其餘的控制工具。

對於純代碼的方式，你們能夠優先學習一下，並且網上教程一堆，在此就不作更多說明了。

而做者在此給你們推薦兩個圖形化倉庫管理工具。

也就是 SourceTree 以及 Cornerstone。

關於下載地址，你們能夠自行在網上搜索一下，做者在這裏就不作更多說明了。

4.將你的代碼上傳至倉庫

---

由於做者日常使用的都是 Git，因此這裏的演示也以 Git 爲準。

除此以外，今天只演示如何將一個本地的文件上傳至 Git 上，若是在公司的話，請按照公司本身的標準來。

最後，在開始操做前，你須要保證本身已經有了如下內容。

• SourceTree 的客戶端
• Github 的帳號

若是你們以前已經使用過 SourceTree 或者已經登陸過某帳號了，請在 SourceTree 中刪除本來帳號。

以後請打開你的 Github，並登陸。

以後請在右下角處，選擇 New repository 去建立一個新的倉庫。

點擊事後會出現這個界面。

建立完畢，這時候咱們就已經獲得咱們的倉庫了。

但是，想要向倉庫中添加內容，這裏還只是個開始。

這時候咱們找到咱們的倉庫的地址，複製下來。

打開咱們的 SourceTree 工具。

一樣點擊 New Repository。

選擇 Clone from URL。

選擇完成後會要求你填寫三個內容。

• 第一個指的是你 Github 上的那個地址連接。
• 第二個是指你須要克隆所使用的文件夾地址
• 第三個會根據第二個自動生成，固然，你也能夠修改

當克隆完畢以後，咱們當前這個文件夾就和 Git 上的那個文件夾相連啦。

這時候咱們只須要將咱們對應的文件直接拖進當前文件夾便可。

以後咱們須要作的就是，回到咱們的 SourceTree 中，開始提交。

固然，提交的過程當中，會提示你，讓你輸入你 GIT 的帳號和密碼。

正常輸入便可，當提交完畢以後，你就會發現咱們的內容已經上傳到 Git 上啦。

5.經過代碼來完成代碼的上傳

---

5.1 初始化

一般有兩種方式來進行初始化：

1）git clone是一種較爲簡單的初始化方式，當你已經有一個遠程的git版本庫時，只須要在本地克隆一份便可。 例如在終端中輸入:

git clone git://github.com/someone/some_project.git some_project複製代碼

上面的命令就是將遠程版本庫克隆到本地電腦的some_project目錄下。

2）git init和git remote。這種方式稍微複雜一些。當你本地建立了一個工做目錄，你能夠進入這個目錄，使用git init命令建立一個git版本管理庫。這時候若是須要將工程放到遠程服務器上，能夠在遠程服務器上建立一個目錄，並把可訪問的URL記錄下來，此時就可使用git remote add命令來增長一個遠程服務器版本了。例如：

git remote add origin git://github.com/someone/another_project.git複製代碼

上面的命令就會增長該URL地址且名稱爲origin的遠程服務器。之後提交的代碼只須要使用origin這個別名便可。

5.2 分支操做

• 查看本地分支:git branch
• 查看遠程分支:git branch -r
• 查看全部的分支:git branch -a
• 建立本地分支:git branch name
  • 注意新分支建立後不會自動切換爲當前分支

• 切換分支:git checkout name

  • 這裏須要注意的一點就是，若是是要同步遠程的分支（好比同事創建了新的分支，以保證針對某個版本的修改在該分支下），請不要在本地新建一個跟遠端同名的分支，也就是說不要使用git branch name這個命令，而是直接使用git checkout name命令把遠端的分支拉下來便可。以免把新的代碼合併到舊的分支裏。

• 建立新分支並當即切換到新分支:git checkout -b name

• 刪除分支:git branch -d name
  • -d選項只能刪除已經參與了合併的分支，對於未有合併的分支是沒法刪除的。若是想強制刪除一個分支，可使用-D選項
• 合併分支:git merge name
  • 將名稱爲name的分支與當前分支合併，是合併到當前分支，而不是合併到name分支。要注意的合併前先使用 git branch查看下當前所處的分支。
  • 能夠在後面加參數

好比我要把issue340分支合併到dev分支，能夠先checkout到dev分支並使用如下命令：

git merge issue340 -n --ff複製代碼

• 建立遠程分支(本地分支push到遠程):git push origin name

• 刪除遠程分支:git push origin :heads/name 或 git push origin : name。

這裏須要注意的是，在開發新功能、測試或者重構部分代碼時，最好是新建一條分支來操做，測試新功能OK後再合併回主分支，以免干擾到主分支。

5.3版本操做

• 查看版本:git tag

• 建立版本:git tag name

• 刪除版本:git tag -d name

5.4 撤銷文件更改

git checkout有兩個做用，其中一個功能是在不一樣的branch之間進行切換，例如git checkout another_branch就會切換到another_branch的分支上去。

另外一個功能是還原代碼的做用，例如git checkout app/model/user.rb就會將user.rb文件從上一個已提交的版本中更新回來，未提交的內容所有會回滾到改動前的狀態。

5.5 查看git配置

git config --list該指令能夠查看全部關於git的配置，用戶和郵箱，遠程庫的URL等。

5.6 版本回滾

git版本管理的好處就在於有無限的反悔權。git reset HEAD^就會回到前一版本(一個^表示是前一版)，並把其中的 changes 繼續留在 working tree 中。適合發現前一次 commit 有問題或是想要修改 commit log，能夠修改後再從新 commit。

git reset若是加上–soft參數則會把 changes 直接加到 staging area（暫存區）。加上–hard參數表示不留 staging area 也不留 working tree(徹底刪除任何修改記錄)。例如git reset --hard指令會清楚全部與最近一次commit不一樣的修改，也就是說放棄當前全部的更改。

若是在合併（merge）過程當中發生衝突了，想放棄此次合併，也可使用git reset --hard來取消。

git reset --hard ORIG_HEAD指令會取消最近一次成功的合併以及全部你在此次合併後所作的修改。

5.7 修改上一次提交的信息

有時候手抖，在尚未輸入完提交信息的時候按了回車，能夠用以下指令修改提交的信息：

git commit -m"your message" --amend複製代碼

5.8 單個文件回滾

有時候爲了改了一個功能，沒徹底測試OK就推到服務器了，發現改的功能還不如以前的好用怎麼辦？ 有兩種狀況，第一種是，在你提交錯誤的代碼到服務器後，隊友還有沒有提交過，可使用該指令：

git reset --hard commit_id複製代碼

其中commit_id是提交記錄的代號，可使用指令:

git log複製代碼

來查看全部的提交記錄，找到你須要回滾的版本便可（鍵盤方向鍵可滾動查看全部記錄，鼠標目測不行）。

這裏要注意的是，git會回滾到你最近一次提交的commit_id以後的版本，而不是commit_id以前的版本。在本次操做中，因爲隊友都沒有更新，只須要找到當前提交的上一次的commit_id便可。好比今天是3月21日，你提交了錯誤的代碼到服務器，服務端在以前3月20日有一次更新，那你找到3月20日的commit_id便可。

第二種狀況是，若是你提交了錯誤代碼後隊友也有新的提交，直接版本回退會把隊友新提交的代碼也搞沒了，這時候若是你改動的文件很少的話，可使用單個文件回滾的方式： 1)執行git log test.h查看該文件的提交記錄，找到須要回滾的commit版本，複製版本號。 2)執行git reset 「commit版本號」 test.h 3)繼續執行git checkout test.h，文件回滾成功。

須要注意的是，若是文件在比較深的目錄下，上述操做室須要輸入目錄結構的，好比git log aaa/bbb/test.h。

5.9 其餘

1. 提交代碼的一般步驟git status查看當前狀態，有改動則使用git add.把全部改動添加到本地倉庫or暫存區？而後git commit -m"your commit message"後，先it pull拉下服務器的最新代碼，確認沒有問題後能夠git push提交代碼。

2. git pull以後，或者進入其餘界面，均可使用:wq退回到git的操做界面

3. 若是在git pull或者git push時，提示沒有設置pull或者push的默認分支，按照提示的指令設置默認分支便可。

再次強調，在開發新功能、測試或者重構部分代碼時，最好是新建一條分支來操做！

6.後記

---

前先後後花了 6 個多小時，總算是寫完了。

但願可以幫到大家吧。

看完記得點個贊。

最後，本文由 李鵬 手打完成，請勿隨意轉載。

做者保留法律追究權利。