歸納整理Git版本控制學習指南

本篇文章給大家帶來了關于git的相關知識，其中主要總結了版本控制的知識點，下面我們就一起來看一下git版本控制的學習指南，希望對大家有幫助。

推薦學習：《git》

版本控制的起源

• 現在的軟件項目通常是由一個研發小組共同分析、設計、編碼、維護以及測試的
• 針對團隊開發需要解決以下問題：
  • 備份多個版本，費空間，費時間
  • 難于恢復至以前正確版本
  • 難以解決代碼沖突困難
  • 難于追溯問題代碼的修改人和修改時間
  • 無法進行權限控制
  • 項目版本發布困難
• 源代碼管理工具就是為了解決上述問題應運而生的

版本控制(Revision Control)

• 是維護工程藍圖的標準做法，能追蹤工程藍圖從誕生一直到定案的過程。是一種記錄若干文件內容變化，以便將來查閱特定版本修訂情況的系統
  • 如果是團隊開發，使用版本控制是強制性的！
  • 如果是單人開發，也強烈建議現在就開始使用版本控制!

• 使用版本控制可以：
  • 不會對現有工作造成任何損害
  • 不會增加工作量
  • 添加新的功能拓展時，會變得更加容易

常見版本控制工具

• CVS 開啟版本控制之門
  • CVS 1990年誕生，遠古時代的主流源代碼管理工具
• svn 集中式版本控制之王者
  • SVN:又稱subversion，是CVS的接班人，是一款集中式源代碼管理工具。曾經是絕大多數開源軟件的代碼管理工具(google code)，前幾年在國內軟件企業使用最為普遍
• git 分布式版本控制之偉大作品
  • GIT:一款分布式源代碼管理工具，目前國內企業幾乎都已經完成了從SVN到GIT的轉換

• 集中式源代碼管理
  

• 分布式源代碼管理
  

• 分布式和集中式的最大區別在于：

  • 在集中式下, 開發者只能將代碼提交到服務器, 在分布式下, 開發者可以本地提交
  • 在集中式下, 只有遠程服務器上有代碼數據庫, 在分布式下, 每個開發者機器上都有一個代碼數據庫

• SVN(集中式)
  

• GIT(分布式)
  

Git和 SVN 的簡單對比

• 速度
  • 在很多情況下，git的速度遠遠比SVN快
• 結構
  • SVN是集中式管理，git是分布式管理
• 其他
  • SVN使用分支比較笨拙，git可以輕松擁有無限個分支
  • SVN必須聯網才能正常工作，git支持本地版本控制工作
  • 舊版本的SVN會在每一個目錄置放一個.svn，git只會在根目錄擁有一個.git

GIT簡介

• GIT是一款自由和開源的分布式版本控制系統，用于敏捷高效地處理任何或小或大的項目
• 在世界上所有的分布式版本控制工具中，git是最快、最簡單、最流行的
• 是linux之父李納斯的第二個偉大作品
  • 2005年由于BitKeeper軟件公司對Linux社區停止了免費使用權。
  • Linus為了輔助Linux內核的開發(管理源代碼),迫不得己自己開發了一個分布式版本控制工具，從而Git誕生了

GIT工作原理

• 如果想學好GIT必須先了解GIT的工作原理
• 工作區(Working Directory): 倉庫文件夾里面, 除了.git目錄以外的內容
• 版本庫(Repository):.git目錄, 用于存儲記錄版本信息
  • 版本庫中的暫緩區(staga):
  • 版本庫中的分支(master): git自動創建的第一個分支
  • 版本庫中的**HEAD指針:**用于指向當前分支

• git add和git commit命名作用
  • git add: 把文件修改添加到暫緩區
  • 
  • git commit: 把暫緩區的所有內容提交到當前HEAD指針指向的分支
  • 

GIT使用環境

• 多人開發時需要一個共享版本庫, 單人開發初始化一個本地庫即可
• 共享版本庫的形式:
  • 本地共享庫: 文件夾/U盤/硬盤
  • 遠程共享庫: 自己搭建git服務器/托管到第三方平臺(github/oschina等)
• 無論是單人開發還是多人開發, 客戶端都可以使用命令行或者圖形化界面使用git

GIT命令-個人開發

• git help ：git指令幫助手冊

  • 查看其他指令的做法：git help 其他指令

• git init : 倉庫初始化(個人倉庫)

  • 倉庫文件目錄

  HEAD:	指向當前分支的一個提交 description:	項目的描述信息 config:	項目的配置信息 info/:	里面有一個exclude文件，指定本項目要忽略的文件 objects/:	Git對象庫(commit/tree/blob/tag) refs/:	標識每個分支指向哪個提交 hooks/:	默認的hook腳本

• GIT設置配置信息

  • 配置用戶名：git config user.name “用戶名”（用于跟蹤修改記錄）
  • 配置郵箱：git config user.email “郵箱”（用于多人開發間的溝通）
  • git config -l : 查看配置信息
  • git config -e : 編輯配置信息

• git status ：查文件的狀態

  • 查看某個文件的狀態：git status 文件名
  • 查看當前路徑所有文件的狀態：git status

• git add ：將工作區的文件保存到暫緩區

  • 保存某個文件到暫緩區：git add 文件名
  • 保存當前路徑的所有文件到暫緩區：git add .（注意，最后是一個點 . ）

• git commit：將暫緩區的文件提交到當前分支

  • 提交某個文件到分支：git commit -m ”注釋” 文件名
  • 保存當前路徑的所有文件到分支：git commit -m ”注釋”

• git log ：查看文件的修改日志

  • 查看某個文件的修改日志：git log 文件名
  • 查看當前路徑所有文件的修改日志：git log
  • 用一行的方式查看簡單的日志信息：git log ––pretty=oneline
  • 查看最近的N次修改：git log –N（N是一個整數）

• git diff ：查看文件最新改動的地方

  • 查看某個文件的最新改動的地方：git diff 文件名
  • 查看當前路徑所有文件最新改動的地方：git diff

• git reflog ：查看分支引用記錄（能夠查看所有的版本號）

• git rm：刪除文件（刪完之后要進行commit操作，才能同步到版本庫）

• git reset：版本回退（建議加上––hard參數，git支持無限次后悔）

  • 回退到上一個版本：git reset ––hard HEAD^
  • 回退到上上一個版本：git reset ––hard HEAD^^
  • 回退到上N個版本：git reset ––hard HEAD~N（N是一個整數）
  • 回退到任意一個版本：git reset ––hard 版本號（版本號用7位即可）

• Git忽略提交規則 – .gitignore配置

  • 別看了, 你想要的都在這企業開發專用鏈接

#               表示此為注釋,將被Git忽略*.a             表示忽略所有 .a 結尾的文件!lib.a          表示但lib.a除外/TODO           表示僅僅忽略項目根目錄下的 TODO 文件，不包括 subdir/TODO build/          表示忽略 build/目錄下的所有文件，過濾整個build文件夾； doc/*.txt       表示會忽略doc/notes.txt但不包括 doc/server/arch.txt   bin/:           表示忽略當前路徑下的bin文件夾，該文件夾下的所有內容都會被忽略，不忽略 bin 文件 /bin:           表示忽略根目錄下的bin文件 /*.c:           表示忽略cat.c，不忽略 build/cat.c debug/*.obj:    表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj **/foo:         表示忽略/foo,a/foo,a/b/foo等 a/**/b:         表示忽略a/b, a/x/b,a/x/y/b等!/bin/run.sh    表示不忽略bin目錄下的run.sh文件*.log:          表示忽略所有 .log 文件 config.php:     表示忽略當前路徑的 config.php 文件  /mtk/           表示過濾整個文件夾*.zip           表示過濾所有.zip文件/mtk/do.c       表示過濾某個具體文件   被過濾掉的文件就不會出現在git倉庫中（gitlab或github）了，當然本地庫中還有，只是push的時候不會上傳。   需要注意的是，gitignore還可以指定要將哪些文件添加到版本管理中，如下：!*.zip!/mtk/one.txt   唯一的區別就是規則開頭多了一個感嘆號，Git會將滿足這類規則的文件添加到版本管理中。為什么要有兩種規則呢？ 想象一個場景：假如我們只需要管理/mtk/目錄中的one.txt文件，這個目錄中的其他文件都不需要管理，那么.gitignore規則應寫為：：/mtk/* !/mtk/one.txt   假設我們只有過濾規則，而沒有添加規則，那么我們就需要把/mtk/目錄下除了one.txt以外的所有文件都寫出來！ 注意上面的/mtk/*不能寫為/mtk/，否則父目錄被前面的規則排除掉了，one.txt文件雖然加了!過濾規則，也不會生效！   ---------------------------------------------------------------------------------- 還有一些規則如下： fd1/* 說明：忽略目錄 fd1 下的全部內容；注意，不管是根目錄下的 /fd1/ 目錄，還是某個子目錄 /child/fd1/ 目錄，都會被忽略；   /fd1/* 說明：忽略根目錄下的 /fd1/ 目錄的全部內容；   /* !.gitignore !/fw/  /fw/* !/fw/bin/ !/fw/sf/ 說明：忽略全部內容，但是不忽略 .gitignore 文件、根目錄下的 /fw/bin/ 和 /fw/sf/ 目錄；注意要先對bin/的父目錄使用!規則，使其不被排除。

GIT命令-團隊開發

• git init –bare : 倉庫初始化(共享倉庫)
  • 注意: 不要直接在共享倉庫中編寫代碼
• git clone：下載遠程倉庫到本地
  • 下載遠程倉庫到當前路徑：git clone 倉庫的URL
  • 下載遠程倉庫到特定路徑：git clone 倉庫的URL 存放倉庫的路徑
• git pull：下載遠程倉庫的最新信息到本地倉庫
• git push：將本地的倉庫信息推送到遠程倉庫
  • 提交時如果遠程倉庫有其它人提交的最新代碼, 必須先pull, 再提交
• 沖突解決:
  • 當多個人同時修改了同一個文件時, 后提交的需要先從服務器pull代碼到問題, 手動解決完沖突之后再push到遠程服務器

<<<<<<< HEAD 	你本地的新增的代碼======= 	服務器上和你沖突的代碼>>>>>>> e9609de28b65bf97539f94c6458cdebdf2711c9f

GIT經典協同模型

• 中心倉庫：包含master和develop兩個分支

• 分支分類

  • 主要分支：master和develop分支
  • 支持性分支：特性分支，發布分支，熱補丁分支

• 對于商業級項目，真正開發過程中都是基于develop分支進行的，develop分支是開發主線！

• master分支中，只存放相對穩定的分支，例如：0.1版本, 0.2版本

• 在實際產品開發中，需要“規劃版本”，例如：將100個功能規劃到5個不同的版本上

• 發現bug，要基于“上一個最穩定的版本”進行修復，這是熱補丁分支存在的意義！

• 理解清楚版本管理分支的特性，是迭代式開發的重要基礎！
  

• git branch : 查看所有分支

• git branch 分支名稱 : 創建分支

• 新創建的分支中的內容和master分支中的內容一樣

• git checkout 分支名稱 : 切換到指定分支
• git merge 分支名稱 : 合并分支
  • 將當前所在分支和指定名稱分支進行合并
• git branch -d 分支名稱 : 刪除指定分支

• 不能在當前分支中刪除自己

使用GIT我們應該

• 經常更新：降低沖突的可能性
• 提交前需在本機測試通過：降低將問題代碼傳到版本庫
• 提交時一定寫備注：方便其他員工查看和自己以后回顧
• 對于不需要提交的文件不要提交到版本庫

提示:每次提交之前先更新每天下班前提交當天編譯通過的代碼每天上班第一件事情更新前一天的代碼

GITHUB使用

• 1.注冊GitHub賬號
  • 
• 2.登錄GitHub
  • 
• 3.點擊你的倉庫
  • 
• 4.創建一個新的倉庫
  • 
• 5.新建的倉庫可以下載, 但是提交需要賬號密碼
• 6.配置ssh Key
  • 6.1打開git 命令行工具
  • 輸入指令ssh-keygen -t rsa -b 4096 -C “your_email@example.com”
  • 
  • 6.2復制剛才生成的公鑰
  • 
  • 
  • 6.3將生成好的SSH Key 添加到GitHub
  • 
  • 
  • 
  • 6.4測試是否配置成功 ssh -T git@github.com
  • 如果后面出現 : Hi ****! You’ve successfully authenticated, but GitHub does not provide shell Access.證明成功
• 7.利用SSH Key操作GitHub
  • 

oschina使用

• 和 GitHub 方法相同

推薦學習：《git》