這是我參與8月更文挑戰的第9天，活動詳情查看：8月更文挑戰git

1、版本控制

1.一、什麼是版本控制

版本控制是一種記錄一個或若干文件內容變化，以便未來查閱特定版本修訂狀況的系統。在公司中，通常以團隊的形式進行項目的開發。在一個團隊中，每個團隊成員都須要一份相同的代碼，而你們又都基於這份代碼去開發着不一樣的功能，過程當中就會產生至關多的問題，針對這些問題，咱們能夠採用版本控制的方式來解決，也所以誕生了不少的版本控制工具，如市面上比較常見的 cvs/svn/git 等等。程序員

1.二、爲何要有版本控制

有了它你就能夠將某個文件回溯到以前的狀態，甚至將整個項目都回退到過去某個時間點的狀態。就算你亂來一氣把整個項目中的文件改的改刪的刪，你也照樣能夠輕鬆恢復到原先的樣子。但額外增長的工做量卻微乎其微。你能夠比較文件的變化細節，查出最後是誰修改了哪一個地方，從而找出致使怪異問題出現的緣由，又是誰在什麼時候報告了某個功能缺陷等等。版本控制深刻程序員在團隊配合中,若是你的項目沒有版本控制：算法

代碼管理混亂。
解決代碼衝突困難。
在代碼整合期間引起BUG。
沒法對代碼的擁有者進行權限控制。
項目不一樣版本發佈困難。

1.三、版本控制工具分類

目前市面上主要有兩種類型的版本控制工具：shell

集中化的版本控制系統
分佈式的版本控制系統

1.3.一、集中化的版本控制系統

集中化的版本控制系統諸如 CVS，svn 以及 Perforce 等，都有一個單一的集中管理的服務器，保存全部文件的修訂版本，而協同工做的人們都經過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這已成爲版本控制系統的標準作法。數據庫

這種作法帶來了許多好處，如今，每一個人均可以在必定程度上看到項目中的其餘人正在作些什麼。而管理員也能夠輕鬆掌控每一個開發者的權限，而且管理一個集中化的版本控制系統; 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。事分兩面，有好有壞。這麼作最顯而易見的缺點是中央服務器的單點故障。若是服務器宕機一小時，那麼在這一小時內，誰都沒法提交更新，也就沒法協同工做。同時他必須聯網才能工做，若是在局域網內還好，帶寬夠大，速度夠快，可若是在互聯網上，遇到網速慢的話，可能提交一個10M的文件就須要5分鐘。緩存

1.3.二、分佈式的版本控制系統

因而分佈式版本控制系統面世了。在這類系統中，像 Git，BitKeeper 等，客戶端並不僅提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工做用的服務器發生故障，過後均可以用任何一個鏡像出來的本地倉庫恢復。由於每一次的提取操做，實際上都是一次對代碼倉庫的完整備份。安全

分佈式的版本控制系統在管理項目時存放的不是項目版本與版本之間的差別.它存的是索引(所需磁盤空間不多因此每一個客戶端均可以放下整個項目的歷史記錄) 和集中式版本控制系統相比，分佈式版本控制系統的安全性要高不少，由於每一個人電腦裏都有完整的版本庫，某一我的的電腦壞掉了沒關係，隨便從其餘人那裏複製一個就能夠了。而集中式版本控制系統的中央服務器要是出了問題，全部人都無法幹活了。在實際使用分佈式版本控制系統的時候，其實不多在兩人之間的電腦上推送版本庫的修改，由於可能大家倆不在一個局域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。所以，分佈式版本控制系統一般也有一臺充當「中央服務器」的電腦，但這個服務器的做用僅僅是用來方便「交換」你們的修改，沒有它你們也同樣幹活，只是交換修改不方便而已。bash

1.四、Git簡史

Git 是目前世界上最早進的分佈式版本控制系統。同生活中的許多偉大事件同樣，Git誕生於一個極富紛爭大舉創新的年代。Linux 內核開源項目有着爲數衆廣的參與者。絕大多數的 Linux 內核維護工做都花在了提交補丁和保存歸檔的繁雜事務上（1991－2002年間）。到 2002 年，整個項目組開始啓用分佈式版本控制系統 BitKeeper 來管理和維護代碼。到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合做關係結束，他們收回了無償使用 BitKeeper 的權力。這就迫使 Linux 開源社區（特別是 Linux的締造者 Linus Torvalds ）不得不吸收教訓，只有開發一套屬於本身的版本控制系統纔不至於重蹈覆轍。自誕生於 2005 年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留着初期設定的目標。它的速度飛快，極其適合管理大項目，它還有着使人難以置信的非線性分支管理系統能夠應付各類複雜的項目開發需求。服務器

2、Git的安裝

2.一、在Windows上安裝

Git的官網Windows版本，下載完安裝包以後，雙擊 exe 安裝包，進行安裝。markdown

完成安裝以後，就可使用命令行的 git 工具（已經自帶了 ssh 客戶端）。在桌面或者任意文件夾的空白位置右鍵，出現下圖所示的這個菜單欄即表示安裝成功。

當你點擊 git bash Here 菜單以後，能夠看到一個終端窗口，在終端裏面輸入命令就能夠查看到版本信息。

git --version
複製代碼

2.二、在Mac上安裝

Git的官網Mac版本，下載下來以後能夠看到一個 dmg 文件，雙擊打開壓縮文件，能夠看到裏面有一個文件，再次雙擊 pkg 文件，就能夠進行安裝，而後按照引導一直點擊繼續按鈕就能夠完成安裝了。

3、Git初始化

3.一、Git初始化配置

由於Git是分佈式版本控制系統，因此，每一個機器都必須自報家門：你的名字和Email地址。這兩條配置很重要，每次 Git 提交時都會引用這兩條信息，說明是誰提交了更新，因此會隨更新內容一塊兒被永久歸入歷史記錄。咱們能夠在Git命令行輸入兩條命令進行配置：

git config --global user.name "你的名字"
git config --global user.email "你的郵箱"
複製代碼

要檢查已有的配置信息，可使用以下命令：

git config --list 
複製代碼

3.二、初始化倉庫

要對現有的某個項目開始用 Git 管理，只需到此項目所在的目錄，執行：

git init
複製代碼

執行完後咱們能夠發現當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的。全部 Git 須要的數據和資源都存放在這個目錄中。不過目前，僅僅是按照既有的結構框架初始化好了裏邊全部的文件和目錄，但咱們尚未開始跟蹤管理項目中的任何一個文件。

3.三、.git目錄詳解

hooks 目錄包含客戶端或服務端的鉤子腳本；
info 包含一個全局性排除文件
logs 保存日誌信息
objects 目錄存儲全部數據內容；
refs目錄存儲指向數據的提交對象的指針（分支）
config 文件包含項目特有的配置選項
description用來顯示對倉庫的描述信息
HEAD 文件指示目前被檢出的分支
index 文件保存暫存區信息

4、Git的使用

4.一、使用git命令將文本添加到版本庫中

在添加以前先作一個標記操做。其實是先將文件添加到緩存區, 而後再添加到版本庫。先使用命令告訴Git：把文件交給 Git 進行管理

git add
複製代碼

而後再告訴Git，把文件提交到本地倉庫

git commit -m "wrote a readme file"
複製代碼

-m後面輸入的是本次提交的說明，能夠輸入任意內容，固然最好是有意義的，這樣你就能從歷史記錄裏方便地找到改動記錄。git commit命令執行成功後會告訴你，1個文件被改動（咱們新添加的readme.txt文件），插入了兩行內容（readme.txt有兩行內容）。

在執行 commit 以前，都先執行一下 add 操做，避免有文件被漏掉了

4.二、工做區和暫存區

在git中進行 crud 操做時都須要執行 git add 文件這個操做，底層操做將操做文件添加一個叫緩存區區域中緩存，當操做完畢以後，使用 git commit 操做，進行統一提交，將編輯文件統一同步版本中。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-igqUf3nC-1620290751987)(G:\叩丁狼\高級框架\四、Git\資料\images\git\圖片 35.png)]

4.三、查看版本庫狀態

如何查看項目目前的狀態？我在電腦前寫了一段時間代碼，用Git管理，中途上廁所，而後又去吃了個蘋果，繼續回來工做，不記得以前用Git幹了些什麼了？

# 查看當前git版本庫的狀態(查看緩存區中的文件內容)
git status 
複製代碼

4.四、查看日誌

咱們腦子裏怎麼可能記得一個幾千行的文件每次都改了什麼內容，因此版本控制系統確定有某個命令能夠告訴咱們歷史記錄。

git log
複製代碼

git log 命令顯示從最近到最遠的提交日誌，若是嫌輸出信息太多，看得眼花繚亂的，能夠試試加上--pretty=oneline參數：

git log --pretty=oneline
複製代碼

咱們能夠看到，commit id 是一串長長的字符，而不是數字，緣由是由於當兩我的同時在一個代碼上工做時候，分別往各自的本地的版本庫提交時，相同的提交號對應着不一樣的修改，若是使用1,2,3這樣的數字不能保證惟一性，因此Git使用SHA-1算法產生惟一標識符，保證全球惟一。好比程序員甲和乙負責共同開發一個聊天軟件，使用Git來版本控制。 Git是分佈式版本控制，每一個人都有一個版本庫。若是Git版本控制用1,2,3這樣的數字來生成版本號，那麼程序員甲和乙代碼合併的時候就會出現問題。版本1究竟是誰的？ SVN 是集中式的版本控制，只有一個版本庫，因此版本號能夠從1,2,3開始。Git是分佈式版本控制，每一個人都有一個版本庫，因此不能從1,2,3開始。

4.五、查看差別

若是一個文件知道被人修改了，但若是能看看具體修改了什麼內容，天然是更好的好比你休假兩週從國外回來，第一天上班時，已經記不清上次怎麼修改的readme.txt，因此，須要用git diff這個命令看看：

# 查看不一樣版本之間的文件差別
git diff 
複製代碼

4.六、版本回退

每當你以爲文件修改到必定程度的時候，就能夠**「保存一個快照」**，這個快照在Git中被稱爲 commit。一旦你把文件改亂了，或者誤刪了文件，還能夠從最近的一個commit 恢復，而後繼續工做，而不是把幾個月的工做成果所有丟失。

Git必須知道當前版本是哪一個版本，在Git中，用HEAD表示當前版本，上一個版本就是HEAD^，上上一個版本就是HEAD^^，固然往上100個版本寫100個^比較容易數不過來，因此寫成HEAD~100。

若是咱們要把當前版本回退到上一個版本，就可使用git reset命令：

git reset --hard HEAD^
複製代碼

回到指定版本

git reset --hard <commit id>
複製代碼

4.七、撤銷修改

git checkout -- filename能夠丟棄工做區的修改：-- 後面是一個空格，好比：

git checkout -- readme.txt
複製代碼

這個命令的意思是說把readme.txt文件在工做區的修改所有撤銷，這裏有兩種狀況：

readme.txt 自修改後尚未被放到暫存區(git add)，如今，撤銷修改就回到和版本庫如出一轍的狀態；
readme.txt 已經添加到暫存區後，又做了修改，如今，撤銷修改就回到添加到暫存區後的狀態。

總的來講就是讓這個文件回到最近一次 git commit 或 git add 時的狀態。

git checkout -- file 命令中的 -- 很重要，沒有 -- ，就變成了「切換到另外一個分支」的命令。

4.八、刪除文件

通常狀況下，你一般直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：

git rm test.txt
複製代碼

4.九、分支管理

Git 擁有強大的分支管理系統，且推薦在項目開發過程當中大量的使用分支來解決各類項目中的問題。

4.9.一、查看分支

咱們可使用命令去查看當前分支。

git  branch
複製代碼

4.9.二、建立分支

咱們可使用命令去建立分支。

git  branch 分支名字
複製代碼

4.9.三、切換分支

git checkout 分支名字
複製代碼

4.9.四、建立+切換分支

git checkout -b 分支名字
複製代碼

4.9.五、合併到當前分支

git merge 分支名
複製代碼

4.9.六、刪除分支

git branch -d 分支名
複製代碼

5、推送遠程倉庫命令

初始化本地的倉庫

git init
複製代碼

設置碼雲的用戶名跟碼雲註冊郵箱

git config --global user.name "碼雲裏面用戶名"
git config --global user.email "碼雲裏面註冊郵箱/手機"
複製代碼

配置忽略提交的文件.gitignore
將項目添加到本地倉庫

git add .
git commit -m "項目初始化"
複製代碼

配置遠程倉庫請求路徑

git remote add origin 本身在碼雲建立倉庫路徑
複製代碼

將本地倉庫中crm項目推送到遠程倉庫

git push -u origin master
複製代碼

彈出一個框，輸入碼雲帳號與密碼

6、團隊開發注意事項

組員每次開發，都先 push 到本身的遠程分支
每次對 master 分支作合併或推送以前，原地備份代碼
確保本身分支的代碼與 master 分支都沒有錯誤之後，將本地 master 推送到遠程
開發前，先切換到 master 分支，更新代碼，確保是最新版本，若是有更新下來內容，一樣先對整個項目進行備份，再切換到本身的分支，而後將 master 合併到本身的分支上
除了將代碼提交到本身的分支之外，都必須再將本身的代碼合併到master
再次強調，每次合併或推送前，都先對項目進行備份，避免操做不熟練致使出錯後代碼丟失

✨往期回顧

感謝閱讀，但願能對你有所幫助博文如有瑕疵請在評論區留言或在主頁我的介紹中添加我私聊我,感謝每一位小夥伴不吝賜教

❤Git真的就是Pull和Push嗎？❤