Git版本控制 Git、github,gitlab相關操作

目錄

• 關於版本控制
  • 版本管理工具
    • 集中式管理
    • 分布式管理
• git版本管理
  • git介紹
  • 軟件安裝
  • Git工作狀態
  • 原理流程步驟
  • git基本操作
    • 對文件進行修改
  • 分支
  • 共享倉庫
    • 創建共享倉庫：
    • 共享倉庫上傳代碼
    • 從共享倉庫下拉代碼
  • 解決沖突
    • 解決沖突
  • gitLab操作
    • 配置ssh密鑰
  • gitHub操作 和gitLab大同小異
  • 開發工具中git使用
    • 提交文件
    • 分支開發
    • 合並分支
    • 沖突解決
    • 日志查看
    • 版本查看
    • 版本回退
    • 對比不同版本
• GitworkFlow
  • workFlow
  • Git Flow：
  • GitHub Flow ：
  • GitLab Flow
  • 合並請求
    • 創建團隊：
    • 分支權限與合並請求
• 忽略文件

關於版本控制

1. 什么是版本控制

1. 版本控制（Version Control Systems）版本控制(Revision control)是一種軟件工程技巧
2. 在開發的過程中，確保由不同人所編輯的同一檔案都得到更新

2. 舉例

1. 我們通常都是手動的重命名一個文件進行備份的 hello.java改成hello1.java或者hello.java.bak等形式
2. 然后這種方式對於單個文件我們還能夠管理，但是對於整個項目而言，就會成為噩夢了！！！

3. 文件版本常見問題

1. 合並代碼：兩個人寫的代碼如何合並到一起
2. 版本回退：在寫代碼過程當中, 代碼出現錯誤,如如何才能加回到以前沒有錯誤的代碼

版本管理工具

集中式管理

特點:

1. 集中式版本控制系統，版本庫是集中存放在中央服務器的 而干活的時候，用的都是自己的電腦
2. 所以要先從中央服務器取得最新的版本，然后開始干活，干完活了，再把自己的活推送給中央服務器 中央服務器就好比是一個圖書館
3. 你要改一本書，必須先從圖書館借出來，然后回到家自己改，改完了，再放回圖書館
   

缺點：

集中式版本控制系統最大的毛病就是必須聯網才能工作 所有的版本都在一個服務器上面 如果服務掛了， 所有記錄的版本都沒了

分布式管理

特點：

1. 分布式版本控制系統，則不需要中央服務器
2. 每個協同開發者都擁有一個完整的版本庫
3. 這么一來，任何協同開發者用的服務器發生故障
4. 事后都可以用其它協同開發者本地倉庫恢復
   結構：
   

使用方式：

1. 在實際使用分布式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，
2. 因為可能你們倆不在一個局域網內，兩台電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。
3. 因此，分布式版本控制系統通常也有一台充當“中央服務器”的電腦，
4. 但這個服務器的作用僅僅是用來方便“交換”大家的修改，沒有它大家也一樣干活，只是交換修改不方便而已。

git版本管理

git介紹

1. git是一款開源的分布式版本管理工具，作者Linux之父-Linus
2. 當初Linus 僅僅是為了輔助Linux內核的開發才一並開發了這個至今為止世界上最快的、最簡單的版本管理工具

軟件安裝

git下載地址

安裝步驟：點擊exe文件，一直下一步

安裝完成效果

Git工作狀態

1. Git 管理項目時,文件流轉分為三個工作區域

Git 的工作目錄， 暫存區域， 以及本地倉庫

2. 對於任何一個文件，在 Git 內都只有三種狀態

1.已修改（modified） 已修改表示修改了某個文件，但還沒有提交保存
2.已暫存（staged） 已暫存表示把已修改的文件放在下次提交時要保存的清單中
3.已提交（committed） 已提交表示該文件已經被安全地保存在本地數據庫中了

原理流程步驟

1. 工作目錄

1. 從項目中取出某個版本的所有文件和目錄，用以開始后續工作的叫做工作目錄
2. 這些文件實際上都是從 Git 目錄中的壓縮對象數據庫中提取出來的
3. 接下來就可以在工作目錄中對這些文件進行編輯

2. 暫存區域

只不過是個簡單的文件 .git目錄之下，名為index，它一般很小，一般不超過1KB左右 一般都放在 Git 目錄中
有時候人們會把這個文件叫做索引文件
暫存區這個索引文件里面包含的是文件的目錄樹，像一個虛擬的工作區，在這個虛擬工作區的目錄樹中，記錄了文件名、文件的時間戳、文件長度、文件類型以及最重要的SHA-1值，文件的內容並沒有存儲在其中
暫存區的作用：除非是繞過暫存區直接提交，否則Git想把修改提交上去，就必須將修改存入暫存區最后才能commit。每次提交的是暫存區所對應的文件快照

3. git目錄(本地倉庫)

1. 當我們在某個目錄下運行git init命令后，在該目錄下便會生成一個.git的子目錄，這個目錄是隱藏的。
2. 它是 Git 用來保存元數據和對象數據庫的地方,這個目錄可以說是Git的核心
3. 每次克隆鏡像倉庫時，實際上拷貝的這個目錄里的內容而已

4. 工作流程

1、在工作目錄中修改文件。
2、暫存文件，將文件的快照放入暫存區域。
3、提交更新，找到暫存區域的文件，將快照永久性存儲到Git倉庫目錄。 示圖

git基本操作

1. 初始化用戶名和郵箱

git config --global user.name "自已的名字"
git config --global user.email "自已的郵箱地址"
# 查看配置的信息 git config --list

2. 創建一個空的文件夾
   
3. 在空的工程中通過git base here命令窗口初始化倉庫
   
   
4. 在空的項目當中創建添加一些文件
   
5. 查看這些文件在git當中的狀態 命令：git status
   
   發現文件和文件夾的顏色都是紅色 ,當出現這種情況的時候, 說明這些文件還沒有添加到git倉庫當中
6. 把文件添加git倉庫中
   執行git add *命令后, 再查看狀態
   
   此時全部變成綠色, 文件已經添加到git暫存區當中,還沒有提交
7. 提交 執行git commit
   
   在執行commit的時候 ,會進入一個vi編輯器界面, 提示讓輸入信息, 輸入本次做了哪些操作, 保存並退出即可
   
   在查看狀態，已經沒有任何需要提交的數據了
   
8. 查看歷史： git log 查看提交日志
   

對文件進行修改

1. 打開index.txt對文件的內容添加進行修改
   
2. 修改之后再查看狀態時,會出現modified狀態
   
   此時需要再次提交到暫存區並提交
   執行 git add * 和 git commit
   
3. 通過git log查看日志,可以看到,有一條新的sha記錄
   
4. 恢復歷史
   第一個sha就是一個版本記錄, 可能使用reset命令恢復到指定的版本
   命令：git reset --hard sha值
   

分支

1. 分支概念:

1. 使用分支意味着你可以把你的工作從開發主線上分離開來，以免影響開發主線
2. 幾乎所有的版本控制系統都以某種形式支持分支。

2. 創建分支:
   命令：git branch 分支名稱
   
3. 查看分支
   命令：git branch
   
   綠色為當前所在分支,默認有一個master主分支
4. 切換分支
   命令：git checkout 分支名稱
   
5. 在newBranch分支上添加一些新的代碼
   
   在次查看狀態
   
   提交
   
   再次切換到master分支上,查看日志,里面並沒有在newBranch中添加的代碼
   
6. 合並分支
   命令：git merge 分支名稱
   
7. 刪除分支
   命令：git branch -d 分支名稱
   

共享倉庫

1. 用戶clone項目
   在當中目錄下,clone用戶1項目
   命令：git clone 要復制的項目路徑和名稱 復制之后的項目路徑和名稱
   
2. 共享倉庫創建
   共享倉庫特點：

1. 以項目名稱.git結尾
2. 看不到工作區
3. 它只用來共享, 不能夠進行修改添加等操作
4. 從共享倉庫當中clone的代碼是可以看到工作的

創建共享倉庫：

命令：

兩種方式：

1. git init --bare 倉庫名稱
2. git clone --bare 要clone的項目路徑和名稱
   
   

共享倉庫上傳代碼

1. 在本地倉庫當中添加文件, 添加加到本地倉庫
2. 先提交到本地倉庫,再推送到遠程倉庫

推送命令：git push 遠程倉庫地址 分支名稱

從共享倉庫下拉代碼

命令：git pull 倉庫地址 分支名稱
新建goods1文件夾 並初始化

解決沖突

1. 什么是沖突

兩個人共同協作開發時, 改了相同的文件,都做了提交

2. 什么情況下會產生沖突

1. 兩人同時更改了相同的代碼,並且都提交到了本地.
2. 先提交到遠程倉庫的人不會有任何問題
3. 后提交的人,需要先pull下來,在pull的時候,就會產生沖突
4. 這時就需要先解決沖突,解決沖突完畢后,提交到本地, 再提交到遠程倉庫

操作：
用戶1更改代碼，提交代碼，用戶2做同樣的操作

用戶2提交遠程的時候會報錯

解決沖突

先從遠程倉庫下拉代碼，但是也會出現報錯

解決方案：
打開下拉的文件，進行手動修改，保留最終數據

刪除<<<<<<head ======== >>>>>>>sha值
保留最終代碼

在進行提交遠程

gitLab操作

得現有gitLab賬號，登陸上去 gitLab官方地址

1. 創建一個新的倉庫
   
2. 填寫相關信息
   
   創建完成
   

配置ssh密鑰

1. 點擊add an SSH key
   
2. 在本地電腦當中添加生成密鑰
   命令：ssh-keygen -t rsa --在客戶端上生成一對密鑰，-t 指定加密類型
   在電腦C盤用戶當中查看生成的密鑰：
   
3. 把id_rsq.pub的內容復制到gitlab當中
   
4. clone遠程的倉庫到本地當中
   
   
   
5. 本地文件push到遠程倉庫
   
   

gitHub操作 和gitLab大同小異

開發工具中git使用

1. 從gitHub上Clone代碼

1. 在IEDA里配置git執行程序的路徑：選擇 【File】→ 【Settings】→ 【Vwesion Control】→ 【Git】
2. 在遠程git服務器上創建倉庫
3. 打開IDEA，選擇菜單上的 VCS（版本控制工具），選擇【Checkout from Version Control】→【Git】
   然后將上邊復制的 git倉庫地址粘貼到URL中，選擇一個本地一個空的目錄作為工作區
   
   

提交文件

1. 添加文件到暫存區

在每創建一個文件的時候, 都會提示添加到暫存區

如果沒有添加到暫存區當中, 也可以手動添加

2. 提交到本地倉庫

完成代碼的開發后，需要將修改和添加的代碼或文件提交到本地倉庫上（文件已添加至暫存區，受git追蹤）
選擇【VCS】→ 【Commit】

3. 推送到遠程倉庫

把代碼推送到遠程服務器上，點擊項目右鍵，【Git】→【 Repositry 】→【Push】

分支開發

假如，現在項目開發完成，需發布1.0版本，然后添加一個1.0的分支

1. 創建分支
   
2. 打開git分支的面板，點擊【New Branch】
   
   切換回主分支
   

合並分支

把主分支（master分支）與1.0分支進行合並

沖突解決

1. 在newbranch分支上c.txt編寫代碼並提交
2. 在master分支上c.txt編寫代碼並提交
   
   

日志查看

版本查看

版本回退

當你誤刪了一段代碼(方法)，但又提交了，可以使用下面的操作來進行回退 打開文件的歷史提交記錄

對比不同版本

1. 對單個代碼文件的比較，點擊文件，右鍵彈出的菜單選項 → 【Git 】→ 【compare with...】
2. Compare with the Same Repository Version 當前文件與服務器同一分支上該文件版本的內容進行比較
3. Compare with 當前文件與文件各次提交的版本做比較
4. Compare with Branch 當前文件與其他分支上該文件版本進行比較
   

GitworkFlow

workFlow

概念：

1. WorkFlow 的字面意思，工作流，即工作流程
2. 項目開發中，多人協作，分支很多，雖然各自在分支上互不干擾，但是我們總歸需要把分支合並到一起
3. 而且真實項目中涉及到很多問題，例如版本迭代，版本發布，bug 修復等
4. 為了更好的管理代碼，需要制定一個工作流程，這就是我們說的工作流,分支管理策略
5. 工作流不涉及任何命令，因為它就是一個規則，完全由開發者自定義，並且自遵守

常用工作流形式：

1. Git Flow：Git Flow 出現的最早
2. GitHub Flow：GitHub Flow 在 Git Flow 的基礎上，做了一些優化，適用於持續版本的發布
3. GitLab Flow：GitLab Flow 出現的時間比較晚，所以綜合前面兩種工作流的優點，制定而成的一個工作流

Git Flow：

特點：采用 Git Flow 工作流的項目中，代碼的中央倉庫會一直存在以下兩個長期分支
主要分支：

1. master:分支上的最新代碼永遠是版本發布狀態
2. develop:分支則是最新的開發進度

協助分支：

Feature Branch：

1. Feature 分支用來做分模塊功能開發
2. 模塊完成之后，會合並到 develop 分支，然后刪除自己。

Release Branch：

1. Release 分支用來做版本發布的預發布分支，建議命名為 release-xxx
   例如：
   在軟件 1.0.0 版本的功能全部開發完成，提交測試之后，從 develop 檢出release-1.0.0
   測試中出現的小問題，在 release 分支進行修改提交，測試完畢准備發布的時候，代碼會合並到 >master 和 develop，master 分支合並后會打上對應版本標簽 v1.0.0, 合並后刪除自己

Hotfix Branch：

1. Hotfix 分支是用來做線上的緊急 bug 修復的分支,建議命名為 hotfix-xxx
2. 當線上某個版本出現了問題，將檢出對應版本的代碼，創建 Hotfix 分支，問題修復后，合並回 master 和 develop ，然后刪除自己

Git Flow 示意圖：

1. master 和 develop 字體被加粗代表主要分支
2. master 分支每合並一個分支，無論是 hotfix 還是 release ,都會打一個版本標簽
3. feature 分支從 develop 開始，最終合並回 develop
4. hoxfixes 從 master 檢出創建，最后合並回 develop 和 master

GitHub Flow ：

概述：

1. 是大型程序員交友社區 GitHub 制定並使用的工作流模型
2. 因為 Git Flow 對於大部分開發人員和團隊來說，稍微有些復雜，而且沒有 GUI 圖形頁面，只能命令行操作， 所以為了更好的解決這些問題，GitHub Flow 應運而生了

特點：

1. GitHub Flow 推薦做法是只有一個主分支 master
2. 團隊成員們的分支代碼通過 pull Request 來合並到 master 上

模型說明：

1. 只有一個長期分支 master ,而且 master 分支上的代碼，永遠是可發布狀態,一般 master 會設置 protected 分支保護
2. 只有有權限的人才能推送代碼到 master 分支
3. 如果有新功能開發，可以從 master 分支上檢出新分支
4. 在本地分支提交代碼，並且保證按時向遠程倉庫推送
5. 當你需要反饋或者幫助，或者你想合並分支時，可以發起一個 pull request。
6. 當 review 或者討論通過后，代碼會合並到目標分支
7. 一旦合並到 master 分支，應該立即發布

合並請求特點：

1. 可以很好控制分支合並權限
2. 分支不是你想合並就合並，需要對方同意
3. 代碼 Review

issue tracking 問題追蹤

開發中，會用到很多第三方庫，然后使用過程中，出現了問題，是不是第一個反應是去這個第三方庫的 GitHub 倉庫去搜索一下 issue
，看沒有人遇到過，項目維護者修復了沒有，一般未解決的 issue 是 open 狀態，已解決的會被標記為 closed。這就是 issue
tracking

GitLab Flow

概述：

GitLab 既支持 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request
） 和 issue tracking

存在問題：

1. 版本的延遲發布（例如 iOS 應用審核到通過中間，可能也要在 master 上推送代碼）
2. 不同環境的部署 （例如：測試環境，預發環境，正式環境）
3. 不同版本發布與修復 （只有一個 master 分支真的不夠用）
4. GitLab 推薦用生產分支來解決上述問題
5. 對於"持續發布"的項目，它建議在master分支以外，再建立不同的環境分支

上游優先原則：

什么是上游優先：

1. Gitlab flow 的最大原則叫做"上游優先"（upsteam first）
2. 即只存在一個主分支master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應用到其他分支。

舉例：

1. "開發環境"的分支是master，"預發環境"的分支是pre-production，"生產環境"的分支是production。
2. 開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。代碼的變化，必須由"上游"向"下游"發展。production。
3. 比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合並到master，
4. 確認沒有問題，再提交到pre-production，這一步也沒有問題，才進入production

版本發布：

1. 對於"版本發布"的項目，建議的做法是每一個穩定版本，都要從master分支拉出一個分支
2. 比如2-3-stable、2-4-stable等等。
3. 以后，只有修補bug，才允許將代碼合並到這些分支
4. 並且此時要更新小版本號

合並請求

創建團隊：

填寫信息

邀請成員

分支權限與合並請求

在指定項目上創建分支：

默認主分支是受保護的
當一個分支是一個受保護的分支時,必須要發起合並請求后操作

設置分支權限
設置保存分支入口

展開分支保存按鈕

忽略文件

在項目開發中，我們使用git托管項目時往往會忽略一些不必要的文件或文件夾

步驟：在版本庫根目錄創建.gitignore，修改文件，添加忽略正則
規則：

？：代表任意的一個字符
＊：代表任意數目的字符 {!ab}：必須不是此類型 {ab,bb,cx}：代表ab,bb,cx中任一類型即可
[abc]：代表a,b,c中任一字符即可
[ ^abc]：代表必須不是a,b,c中任一字符

示例：

注意事項：

1. 添加忽略之后，已經提交到版本庫中的文件是無法忽略的,只能clone到本地，刪除后，再進行忽略
2. gitignore只能忽略那些原來沒有被track的文件，如果某些文件已經被納入了版本管理中，則修改.gitignore是無效的。