老鐵，這年頭不會點Git真不行！！！

轉載自武沛齊的博客:http://www.cnblogs.com/wupeiqi/p/7295372.html#commentform

 

版本控制

說到版本控制，腦海裏總會浮現大學畢業是寫畢業論文的場景，你電腦上的畢業論文必定出現過這番景象！

1 2 3 4 5 6 7 8 9 10 11

畢業論文_初稿.doc 畢業論文_修改 1.doc 畢業論文_修改 2.doc 畢業論文_修改 3.doc 畢業論文_完整版 1.doc 畢業論文_完整版 2.doc 畢業論文_完整版 3.doc 畢業論文_最終版 1.doc 畢業論文_最終版 2.doc 畢業論文_死也不改版.doc ...

以上就是使用最原始的方式進行版本控制，可是這種方式有顯著缺點：

• 多個文件，保留全部版本時，須要爲每一個版本保存一個文件...
• 協同操做，多人協同操做時，須要將文件打包發來發去...
• 容易丟失，被刪除意味着永遠失去...（能夠選擇網盤）

爲了解決以上版本控制存在問題，應運而生了一批版本控制工具：VSS、CVS、SVN、Git等，其中Git屬於絕對霸主地位。

注意：通常版本控制工具包含兩部分

• 客戶端（本地）：本地編寫內容以及版本記錄
• 服務端（網盤）：將內容和版本記錄同時保存在遠程（無關緊要）

GIT介紹  

Git 是一個開源的分佈式版本控制軟件,用以有效、高速的處理從很小到很是大的項目版本管理。 Git 最初是由Linus Torvalds設計開發的，用於管理Linux內核開發。Git 是根據GNU通用公共許可證版本2的條款分發的自由/免費軟件，安裝參見：http://git-scm.com/

GitHub是一個基於Git的遠程文件託管平臺（同GitCafe、BitBucket和GitLab等）。

Git自己徹底能夠作到版本控制，但其全部內容以及版本記錄只能保存在本機，若是想要將文件內容以及版本記錄同時保存在遠程，則須要結合GitHub來使用。使用場景：

• 無GitHub：在本地 .git 文件夾內維護歷時文件
• 有GitHub：在本地 .git 文件夾內維護歷時文件，同時也將歷時文件託管在遠程倉庫

其餘：

    集中式：遠程服務器保存全部版本，用戶客戶端有某個版本
    分佈式：遠程服務器保存全部版本，用戶客戶端有全部版本

Git使用之小P創業史：初創期

小P是一個年輕有爲程序員，從小立志要幹出一番大事，某個深夜小P在網上查找**老師主演的學習視頻，花了1個小時才找到想要的資源，小P想到和本身同樣的有爲青年天天花費大量的時間尋找喜歡老師的做品，感受本身幹大事的機會來了，毅然決然選擇創業，建立一個**平臺，提供**老師的全部資源！！！

創業初期，小P獨自封閉開發一個月，第一個版本終於上線：

回顧開發過程，其中辛酸只有小P本身知道。上線完成後的某一天，小P猛然看到本身開發目錄，臥槽這拓麻也太亂了，加入那天程序出問題回滾到上個版本的時候，本身都找不到肯定版本，而且我老子作的這個系統往後是要成千上萬人來維護開發，這種經過原始文件來保存版本的形式簡直Low到爆啊。

開始調研：小P發現了版本控制神奇Git，可是都是道聽途說，到底牛逼成什麼樣子也不清楚，因此抱着試試看的態度，小P開始使用Git進行版本控制。

1 2 3 4

MacBook-Pro-4:pondo wupeiqi$  pwd                    # 進入程序目錄 /Users/wupeiqi/PycharmProjects/pondo MacBook-Pro-4:pondo wupeiqi$ git init                 # git初始化 Initialized empty Git repository  in  /Users/wupeiqi/PycharmProjects/pondo/ .git/

初始化後，會在當前目錄自動建立 .git 文件夾，該文件是Git中最重要的文件夾，由於Git相關文件以及版本都將保存在該文件夾中，有了它，媽媽不再用擔憂我好多文件來記錄版本了，經過Git命令能夠將全部版本保存在 .git 文件中，兩條命令建立一個版本：

+ View Code

注意：執行git commit 命令時，可能會提示進行用戶和郵箱的配置，該配置用於記錄當前版本由那個用戶提交

• git config --local user.name '武沛齊'
• git config --local user.email 'you@example.com'

Git把管理的文件分爲了兩個區域四個狀態。

工做區：當前開發程序所在目錄稱爲工做區，即：工做開發都是在該目錄，該區域的文件會有狀態的變化且狀態由git自動檢測，若是程序中文件作任何操做（增、刪、改），文件狀態均會被檢測到，可使用 【git status】命令查看。

  View Code

版本庫：工做區檢測到有文件發生變化，那麼意味着較上一個版本以後對程序進行了修改，修改完成以後，能夠當作下一版本進行提交，那麼就是執行 【git add .】 將全部文件提交到暫存區，而後再執行【git commit -m '又一個版本'】提交到版本庫的分支便可，以後可使用【git log】命令查看版本記錄。

  View Code

目前已使用Git的四個命令，這四個命令已經能夠代替本地多個文件保存版本的方式：

• git init，初始化，表示即將對當前文件夾進行版本控制。
• git status，查看Git當前狀態，如：那些文件被修改過、那些文件還未提交到版本庫等。
• git add 文件名，將指定文件添加到版本庫的暫存狀態。
• git commit -m '提交信息'，將暫存區的文件提交到版本庫的分支。
• git log，查看提交記錄，即：歷史版本記錄

 調研完，小P好氣本身喲，這麼6的東西爲何沒有早發現，今後小P的版本管理就告別繁雜的文件夾了，趕忙搞起來。

+ View Code

剛好，此時須要開發一個非洲專區的功能，不再用從新copy一遍文件了，在工做區直接開始搞起來，30分鐘開發測試完成，又一個版本完成了咯！！！

+ View Code

非洲專區上線一個月後，接連收到用戶投訴，原來清新脫俗的小P那裏去了？怎麼變得如此重口味？想回到過去....

小P向來秉承爲人民服務的原則，人民不想看那必定要修改。決定：回滾，回到上一個版本。

那麼問題來了？

一個月過去了，代碼修改的位置早就忘記了，怎麼修改，總不能再開發一遍吧。機智的小P猜測Git既然這麼牛逼，應該會提供這樣的功能，通過一番查找，果不其然Git提供了這個回滾的功能。

回滾到指定版本：

+ View Code

回滾卻是完成了，小P在想若是某一天想要在回有非洲專區功能的版本怎麼辦呢？來來來，不能像以往經過【git log】來查看記錄再回滾了，再回去須要這麼搞：

+ View Code

Git使用之小P創業史：成長期

企業想要不被淘汰，就要跟緊時代步伐，近日直播行業日趨火熱，小P的也但願本身的平臺加入直播功能，已經評估預計2個月開發完成，小P開始沒日沒夜的幹了起來...

一個月過去了，開發任務和按照預期有條不紊的進行着，直播功能也已完成一半，就是在此時線上運行平臺出現Bug須要緊急修復，怎麼辦？怎麼辦？？怎麼辦？？？

小P出了幾個解決方案：

• 正在開發代碼不動，拷貝一份線上運行的代碼進行修改         ------> 不行，又踏馬回去拷貝去了。
• 把開發了一個月的代碼刪掉，修改Bug，而後再重頭開始      ------> 不行，必定是傻逼才這麼幹，我不是傻逼。
• 據說git的stash能夠                                                       ------> 據說過，沒見過
• 據說git的branch能夠                                                     ------> 據說過，沒見過

方案一：stash

stash用於將工做區發生變化的全部文件獲取臨時存儲在「某個地方」，將工做區還原當前版本未操做前的狀態；stash還能夠將臨時存儲在「某個地方」的文件再次拿回到工做區。

+ View Code

特別的：執行 git stash pop 命令時，可能會遇到衝突，由於在緊急修復bug的代碼和經過stash存儲在「某個地方」的代碼會有重合部分，因此執行 git stash pop 時候就會出現衝突，有衝突解決衝突便可。

  git stash pop 出現衝突

stash相關經常使用命令：

• git stash             將當前工做區全部修改過的內容存儲到「某個地方」，將工做區還原到當前版本未修改過的狀態
• git stash list        查看「某個地方」存儲的全部記錄
• git stash clear     清空「某個地方」
• git stash pop       將第一個記錄從「某個地方」從新拿到工做區（可能有衝突）
• git stash apply     編號, 將指定編號記錄從「某個地方」從新拿到工做區（可能有衝突） 
• git stash drop      編號，刪除指定編號的記錄

方案二：branch

分支學習：branch稱爲分支，默認僅有一個名爲master的分支。通常開發新功能流程爲：開發新功能時會在分支dev上進行，開發完畢後再合併到master分支。

  通常流程示例（上圖）

學習參考上圖，小P也能夠按照着這樣的流程進行開發，若是遇到上文開發到通常須要臨時修復Bug的狀況，能夠按照下圖的流程進行：

+ View Code

注意：git merge 時也可能會出現衝突，解決衝突的方式上述stash相同，即：找到衝突文件，手動修改衝突並提交，此處再也不敖述。

branch相關經常使用命令：

• git branch 分支名稱             建立分支
• git checkout 分支名稱          切換分支
• git branch -m 分支名稱        建立並切換到指定分支
• git branch                          查看全部分支
• git branch -d 分支名稱         刪除分支
• git merge 分支名稱              將指定分支合併到當前分支

 

Git使用之小P創業快速發展期

小P不忘初心始終如一的爲廣大有爲青年提供資源，使得網站的訪問量不斷攀升，已經出具規模並賺了一些錢，有錢就要造麼，索性國貿租了一間寫字樓用於辦公，而且也完善運營市場團隊。。屌絲終歸是屌絲，小P仍是離不開寫代碼的習慣，因此開發的任務仍是由本身一人承擔，小P今後開始了白天在國貿寫代碼，晚上回天通苑寫代碼。PS：有錢，公司一臺新電腦，家裏一臺原來老電腦。。。。。 媽的，故事怎麼才能變得有趣呢？太拓麻難了。

小P內心開始尋思，我愛寫代碼，公司寫，家裏寫，若是天天來回帶一個U盤拷貝着實麻煩，Git有沒有相似於雲盤似得東西能夠進行數據同步呢？答案確定是有。 必須有，否則老子真的就編不下去了。

GitHub，一個基於Git實現的代碼託管的平臺，能夠將內容以及版本記錄在遠程也保存一份，這樣就不用U盤咯（相似於雲盤）。PS: 相似GitHub的產品還有許多，如：GitLab、Bitbucket、碼雲等。

基於GitHub實現代碼託管，須要一下步驟：

• 註冊GitHub
• 建立倉庫，建立完倉庫後會有一個URL代指該倉庫，如：
   
• git能夠是用該URL進行向遠程推送版本信息或獲取版本信息
  

   

小P學會使用Git和GitHub以後，就能夠基於GitHub進行代碼遠程託管。

在家裏，小P開發完畢部分功能將代碼推送到GitHub。

+ View Code

在公司，新電腦第一次使用，須要將代碼從GitHub中獲取並繼續開發，開發完事下班就下班回家。

+ View Code

在家裏，因爲白天在公司已經開發一部分功能並提交到GitHub，家裏電腦的代碼仍是昨晚的版本，因此須要從GitHub拉去最新代碼，而後繼續開發。

+ View Code

 在公司，因爲昨天晚上在家已經開發了一部分功能，在公司須要先把昨晚開發的功能從GitHub中拉取，並繼續開發。

+ View Code

久而久之，將Git和GitHub結合使用作到避免電腦損壞形成數據丟失以及多地開發的問題，上文執行過程當中執行 【git pull origin 分支】命令等同於【git fetch origin 分支】+ 【git merge origin/分支】，而且在執行過程當中可能會出現衝突，緣由是因爲本地代碼和獲取的最新代碼有重合部分，那麼就須要本身手動解決衝忽然後再繼續開發。

Git使用之小P創業成熟期

小P的公司發展愈來愈好，可是公司產品單一是嚴重缺點，通過學習考察小P決定再招聘3個Python程序開發另一個產品「約P」平臺來豐富公司業務線，爲用戶提供一整套服務。

小P的Slogan：看了想要，想要就約。 不要問我怎麼想要的，我本身也不知道    哈哈哈哈哈哈哈哈

「約P」平臺須要三人協同開發，GitHub中多人協同開發和單人開發仍是有點差異，協同開發通常有兩種方式：

• 合做者，將其餘用戶添加到倉庫合做者中以後，該用戶就具備向當前倉庫提交代碼。
  
• 組織，建立一個組織，而後再該組織下能夠建立多個項目，組內成員能夠向組內全部項目提交代碼。PS：也能夠對某個項目指定合做者
  

協同開發命令和以上步驟相似，此處就再也不從新寫代碼，而是使用文件描述三人協同開發整個過程。

• 建立程序
• 用戶A建立程序，提交到GitHub
• 用戶B克隆項目
• 用戶C克隆項目
• 開發功能
• 用戶A開發功能1
• 用戶B開發功能2
• 用戶C開發功能3
• 提交
• 用戶A提交功能1，並push（A用戶手速快，先提交。）
• 用戶B提交功能2，沒法push，由於GitHub上已經有其餘人提交的新代碼。
  解決方法：從GitHub上獲取最新代碼併合併到本地，提交本身開發的功能2。
• 用戶C提交功能3，沒法push，沒法提交，由於GitHub上已經有其餘人提交的新代碼。
  解決方法：從GitHub上獲取最新代碼併合併到本地，提交本身開發的功能3。
• 獲取最新代碼
  • 用戶A獲取最新代碼
  • 用戶B獲取最新代碼
  • 用戶C獲取最新代碼

在上面紅色標註的解決方法位置能夠有三種方式操做，三者均可以完成合並並提交新功能，可是日誌記錄會有差別，如：前二者版本記錄中會出現合併，而第三種能夠保證版本記錄乾淨整潔。

• 先 git pull origin master   而後 git push origin master
• 先 git fetch origin master 而後 git merge origin/master   再 git push origin master
  
  + View Code
• 先 git fetch origin master 而後 git rebase origin/master  再 git push origin master
  
  + View Code

使用Git之小P創業上市期

終於終於小P等到了公司上市實現財務自由，但做爲一個技術屌仍是脫離不了屌絲的本質，因此天天都是逛逛github，看看別人有什麼好的項目，本身能夠給他挑挑bug裝裝逼，可是別人不可能給小P搞成合做者什麼的，那怎麼才能給別人貢獻代碼呢？那就是fork了。。。。

• 找到想搞的項目，fork一下，而後這個項目就在本身倉庫出現了
  
• 從本身倉庫獲取代碼並進行編輯提交
• 建立並提交一個pull request，而後等待原做者是否贊成這個pull request，若是贊成那麼在做者的源代碼中就推出現小P提交的功能
    

其餘補充

1. 配置文件

Git的配置文件有三個：

• 系統配置： /private/etc/gitconfig
• 用戶配置： ~/.gitconfig
• 項目配置：.git/config

2. 用戶憑證

因爲Git和Github交互操做可能會很頻繁，那麼必定少了用戶受權的操做，爲了防止每次操做重複輸入用戶名和密碼，Git提供了兩種解決方法：

• 祕鑰
  首先建立一對祕鑰  ssh-keygen -t rsa，而後將 id_rsa.pub (公鑰)內容拷貝到github中，往後操做無需再輸入用戶名和密碼。
  注意：這種方式須要使用GIt中 git@github.com:WuPeiqi/xxxxx.git 格式地址。
• 密碼
  Https訪問git時，避免每次操做須要輸入用戶名和密碼，能夠在配置文件中添加以下配置項：
      [credential]
      helper = store/cache/第三方
  

  store:
          表示將用戶名和密碼保存在硬盤上
          第一次輸入過用戶名和密碼以後，用戶名和密碼就會保存在當前用戶根目錄的 .git-credentials 文件中，內容格式爲：https://用戶名:密碼@github.com

          自動添加配置命令：git config credential.helper store
  cache: 
          表示將用戶名和密碼保存在緩存中
          第一次輸入過用戶名和密碼以後，用戶名和密碼就會保存在緩存中，默認超時時間是 900 秒，緩存相關文件保存在當前用戶根目錄的 git-credential-cache 中 
          自動添加配置命令：
                 git config credential.helper cache
                 git config credential.helper 'cache --timeout=300'

  相關操做：
          清除緩存：git credential-cache exit 
          指定超時：
              [credential]
              helper = cache --timeout=300
  注意：這種方式須要使用GIt中 https://github.com/WuPeiqi/xxxx.git 格式地址。

就醬紫，之後想到再加吧...