Git版本控制 Git、github,gitlab相關操作
目錄
- 關於版本控制
- 版本管理工具
- 集中式管理
- 分散式管理
- 版本管理工具
- git版本管理
- git介紹
- 軟體安裝
- Git工作狀態
- 原理流程步驟
- git基本操作
- 對檔案進行修改
- 分支
- 共享倉庫
- 建立共享倉庫：
- 共享倉庫上傳程式碼
- 從共享倉庫下拉程式碼
- 解決衝突
- 解決衝突
- gitLab操作
- 配置ssh金鑰
- gitHub操作 和gitLab大同小異
- 開發工具中git使用
- 提交檔案
- 分支開發
- 合併分支
- 衝突解決
- 日誌檢視
- 版本檢視
- 版本回退
- 對比不同版本
- GitworkFlow
- workFlow
- Git Flow：
- GitHub Flow ：
- GitLab Flow
- 合併請求
- 建立團隊：
- 分支許可權與合併請求
- 忽略檔案
關於版本控制
- 什麼是版本控制
- 版本控制（Version Control Systems）版本控制(Revision control)是一種軟體工程技巧
- 在開發的過程中，確保由不同人所編輯的同一檔案都得到更新
- 舉例
- 我們通常都是手動的重新命名一個檔案進行備份的 hello.java改成hello1.java或者hello.java.bak等形式
- 然後這種方式對於單個檔案我們還能夠管理，但是對於整個專案而言，就會成為噩夢了！！！
- 檔案版本常見問題
- 合併程式碼：兩個人寫的程式碼如何合併到一起
- 版本回退：在寫程式碼過程當中, 程式碼出現錯誤,如如何才能加回到以前沒有錯誤的程式碼
版本管理工具
集中式管理
特點:
- 集中式版本控制系統，版本庫是集中存放在中央伺服器的 而幹活的時候，用的都是自己的電腦
- 所以要先從中央伺服器取得最新的版本，然後開始幹活，幹完活了，再把自己的活推送給中央伺服器 中央伺服器就好比是一個圖書館
- 你要改一本書，必須先從圖書館借出來，然後回到家自己改，改完了，再放回圖書館
缺點：
集中式版本控制系統最大的毛病就是必須聯網才能工作 所有的版本都在一個伺服器上面 如果服務掛了， 所有記錄的版本都沒了
分散式管理
特點：
- 分散式版本控制系統，則不需要中央伺服器
- 每個協同開發者都擁有一個完整的版本庫
- 這麼一來，任何協同開發者用的伺服器發生故障
- 事後都可以用其它協同開發者本地倉庫恢復
結構：
使用方式：
- 在實際使用分散式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，
- 因為可能你們倆不在一個區域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。
- 因此，分散式版本控制系統通常也有一臺充當“中央伺服器”的電腦，
- 但這個伺服器的作用僅僅是用來方便“交換”大家的修改，沒有它大家也一樣幹活，只是交換修改不方便而已。
git版本管理
git介紹
- git是一款開源的分散式版本管理工具，作者Linux之父-Linus
- 當初Linus 僅僅是為了輔助Linux核心的開發才一併開發了這個至今為止世界上最快的、最簡單的版本管理工具
軟體安裝
git下載地址
安裝步驟：點選exe檔案，一直下一步
安裝完成效果
Git工作狀態
- Git 管理專案時,檔案流轉分為三個工作區域
Git 的工作目錄， 暫存區域， 以及本地倉庫
- 對於任何一個檔案，在 Git 內都只有三種狀態
1.已修改（modified） 已修改表示修改了某個檔案，但還沒有提交儲存
2.已暫存（staged） 已暫存表示把已修改的檔案放在下次提交時要儲存的清單中
3.已提交（committed） 已提交表示該檔案已經被安全地儲存在本地資料庫中了
原理流程步驟
- 工作目錄
- 從專案中取出某個版本的所有檔案和目錄，用以開始後續工作的叫做工作目錄
- 這些檔案實際上都是從 Git 目錄中的壓縮物件資料庫中提取出來的
- 接下來就可以在工作目錄中對這些檔案進行編輯
- 暫存區域
只不過是個簡單的檔案 .git目錄之下，名為index，它一般很小，一般不超過1KB左右 一般都放在 Git 目錄中
有時候人們會把這個檔案叫做索引檔案
暫存區這個索引檔案裡面包含的是檔案的目錄樹，像一個虛擬的工作區，在這個虛擬工作區的目錄樹中，記錄了檔名、檔案的時間戳、檔案長度、檔案型別以及最重要的SHA-1值，檔案的內容並沒有儲存在其中
暫存區的作用：除非是繞過暫存區直接提交，否則Git想把修改提交上去，就必須將修改存入暫存區最後才能commit。每次提交的是暫存區所對應的檔案快照
- git目錄(本地倉庫)
- 當我們在某個目錄下執行git init命令後，在該目錄下便會生成一個.git的子目錄，這個目錄是隱藏的。
- 它是 Git 用來儲存元資料和物件資料庫的地方,這個目錄可以說是Git的核心
- 每次克隆映象倉庫時，實際上拷貝的這個目錄裡的內容而已
- 工作流程
1、在工作目錄中修改檔案。
2、暫存檔案，將檔案的快照放入暫存區域。
3、提交更新，找到暫存區域的檔案，將快照永久性儲存到Git倉庫目錄。 示圖
git基本操作
- 初始化使用者名稱和郵箱
git config --global user.name "自已的名字"
git config --global user.email "自已的郵箱地址"
# 檢視配置的資訊 git config --list
- 建立一個空的資料夾
- 在空的工程中通過git base here命令視窗初始化倉庫
- 在空的專案當中建立新增一些檔案
- 檢視這些檔案在git當中的狀態 命令：git status
發現檔案和資料夾的顏色都是紅色 ,當出現這種情況的時候, 說明這些檔案還沒有新增到git倉庫當中 - 把檔案新增git倉庫中
執行git add *命令後, 再檢視狀態
此時全部變成綠色, 檔案已經新增到git暫存區當中,還沒有提交 - 提交 執行git commit
在執行commit的時候 ,會進入一個vi編輯器介面, 提示讓輸入資訊, 輸入本次做了哪些操作, 儲存並退出即可
在檢視狀態，已經沒有任何需要提交的資料了
- 檢視歷史： git log 檢視提交日誌
對檔案進行修改
- 開啟index.txt對檔案的內容新增進行修改
- 修改之後再檢視狀態時,會出現modified狀態
此時需要再次提交到暫存區並提交
執行 git add * 和 git commit
- 通過git log檢視日誌,可以看到,有一條新的sha記錄
- 恢復歷史
第一個sha就是一個版本記錄, 可能使用reset命令恢復到指定的版本
命令：git reset --hard sha值
分支
- 分支概念:
- 使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線
- 幾乎所有的版本控制系統都以某種形式支援分支。
- 建立分支:
命令：git branch 分支名稱
- 檢視分支
命令：git branch
綠色為當前所在分支,預設有一個master主分支 - 切換分支
命令：git checkout 分支名稱
- 在newBranch分支上新增一些新的程式碼
在次檢視狀態
提交
再次切換到master分支上,檢視日誌,裡面並沒有在newBranch中新增的程式碼
- 合併分支
命令：git merge 分支名稱
- 刪除分支
命令：git branch -d 分支名稱
共享倉庫
- 使用者clone專案
在當中目錄下,clone使用者1專案
命令：git clone 要複製的專案路徑和名稱 複製之後的專案路徑和名稱
- 共享倉庫建立
共享倉庫特點：
- 以專案名稱.git結尾
- 看不到工作區
- 它只用來共享, 不能夠進行修改新增等操作
- 從共享倉庫當中clone的程式碼是可以看到工作的
建立共享倉庫：
命令：
兩種方式：
- git init --bare 倉庫名稱
- git clone --bare 要clone的專案路徑和名稱
共享倉庫上傳程式碼
- 在本地倉庫當中新增檔案, 新增加到本地倉庫
- 先提交到本地倉庫,再推送到遠端倉庫
推送命令：git push 遠端倉庫地址 分支名稱
從共享倉庫下拉程式碼
命令：git pull 倉庫地址 分支名稱
新建goods1資料夾 並初始化
解決衝突
- 什麼是衝突
兩個人共同協作開發時, 改了相同的檔案,都做了提交
- 什麼情況下會產生衝突
- 兩人同時更改了相同的程式碼,並且都提交到了本地.
- 先提交到遠端倉庫的人不會有任何問題
- 後提交的人,需要先pull下來,在pull的時候,就會產生衝突
- 這時就需要先解決衝突,解決衝突完畢後,提交到本地, 再提交到遠端倉庫
操作：
使用者1更改程式碼，提交程式碼，使用者2做同樣的操作
使用者2提交遠端的時候會報錯
解決衝突
先從遠端倉庫下拉程式碼，但是也會出現報錯
解決方案：
開啟下拉的檔案，進行手動修改，保留最終資料
刪除<<<<<<head ======== >>>>>>>sha值
保留最終程式碼
在進行提交遠端
gitLab操作
得現有gitLab賬號，登陸上去 gitLab官方地址
- 建立一個新的倉庫
- 填寫相關資訊
建立完成
配置ssh金鑰
- 點選add an SSH key
- 在本地電腦當中新增生成金鑰
命令：ssh-keygen -t rsa --在客戶端上生成一對金鑰，-t 指定加密型別
在電腦C盤使用者當中檢視生成的金鑰：
- 把id_rsq.pub的內容複製到gitlab當中
- clone遠端的倉庫到本地當中
- 本地檔案push到遠端倉庫
gitHub操作 和gitLab大同小異
開發工具中git使用
- 從gitHub上Clone程式碼
- 在IEDA裡配置git執行程式的路徑：選擇 【File】→ 【Settings】→ 【Vwesion Control】→ 【Git】
- 在遠端git伺服器上建立倉庫
- 開啟IDEA，選擇選單上的 VCS（版本控制工具），選擇【Checkout from Version Control】→【Git】
然後將上邊複製的 git倉庫地址貼上到URL中，選擇一個本地一個空的目錄作為工作區
提交檔案
- 新增檔案到暫存區
在每建立一個檔案的時候, 都會提示新增到暫存區
如果沒有新增到暫存區當中, 也可以手動新增
- 提交到本地倉庫
完成程式碼的開發後，需要將修改和新增的程式碼或檔案提交到本地倉庫上（檔案已新增至暫存區，受git追蹤）
選擇【VCS】→ 【Commit】
- 推送到遠端倉庫
把程式碼推送到遠端伺服器上，點選專案右鍵，【Git】→【 Repositry 】→【Push】
分支開發
假如，現在專案開發完成，需釋出1.0版本，然後新增一個1.0的分支
- 建立分支
- 開啟git分支的面板，點選【New Branch】
切換回主分支
合併分支
把主分支（master分支）與1.0分支進行合併
衝突解決
- 在newbranch分支上c.txt編寫程式碼並提交
- 在master分支上c.txt編寫程式碼並提交
日誌檢視
版本檢視
版本回退
當你誤刪了一段程式碼(方法)，但又提交了，可以使用下面的操作來進行回退 開啟檔案的歷史提交記錄
對比不同版本
- 對單個程式碼檔案的比較，點選檔案，右鍵彈出的選單選項 → 【Git 】→ 【compare with...】
- Compare with the Same Repository Version 當前檔案與伺服器同一分支上該檔案版本的內容進行比較
- Compare with 當前檔案與檔案各次提交的版本做比較
- Compare with Branch 當前檔案與其他分支上該檔案版本進行比較
GitworkFlow
workFlow
概念：
- WorkFlow 的字面意思，工作流，即工作流程
- 專案開發中，多人協作，分支很多，雖然各自在分支上互不干擾，但是我們總歸需要把分支合併到一起
- 而且真實專案中涉及到很多問題，例如版本迭代，版本釋出，bug 修復等
- 為了更好的管理程式碼，需要制定一個工作流程，這就是我們說的工作流,分支管理策略
- 工作流不涉及任何命令，因為它就是一個規則，完全由開發者自定義，並且自遵守
常用工作流形式：
- Git Flow：Git Flow 出現的最早
- GitHub Flow：GitHub Flow 在 Git Flow 的基礎上，做了一些優化，適用於持續版本的釋出
- GitLab Flow：GitLab Flow 出現的時間比較晚，所以綜合前面兩種工作流的優點，制定而成的一個工作流
Git Flow：
特點：採用 Git Flow 工作流的專案中，程式碼的中央倉庫會一直存在以下兩個長期分支
主要分支：
- master:分支上的最新程式碼永遠是版本釋出狀態
- develop:分支則是最新的開發進度
協助分支：
Feature Branch：
- Feature 分支用來做分模組功能開發
- 模組完成之後，會合併到 develop 分支，然後刪除自己。
Release Branch：
- Release 分支用來做版本釋出的預釋出分支，建議命名為 release-xxx
例如：
在軟體 1.0.0 版本的功能全部開發完成，提交測試之後，從 develop 檢出release-1.0.0
測試中出現的小問題，在 release 分支進行修改提交，測試完畢準備釋出的時候，程式碼會合併到 >master 和 develop，master 分支合併後會打上對應版本標籤 v1.0.0, 合併後刪除自己Hotfix Branch：
- Hotfix 分支是用來做線上的緊急 bug 修復的分支,建議命名為 hotfix-xxx
- 當線上某個版本出現了問題，將檢出對應版本的程式碼，建立 Hotfix 分支，問題修復後，合併回 master 和 develop ，然後刪除自己
Git Flow 示意圖：
- master 和 develop 字型被加粗代表主要分支
- master 分支每合併一個分支，無論是 hotfix 還是 release ,都會打一個版本標籤
- feature 分支從 develop 開始，最終合併回 develop
- hoxfixes 從 master 檢出建立，最後合併回 develop 和 master
GitHub Flow ：
概述：
- 是大型程式設計師交友社群 GitHub 制定並使用的工作流模型
- 因為 Git Flow 對於大部分開發人員和團隊來說，稍微有些複雜，而且沒有 GUI 圖形頁面，只能命令列操作， 所以為了更好的解決這些問題，GitHub Flow 應運而生了
特點：
- GitHub Flow 推薦做法是隻有一個主分支 master
- 團隊成員們的分支程式碼通過 pull Request 來合併到 master 上
模型說明：
- 只有一個長期分支 master ,而且 master 分支上的程式碼，永遠是可釋出狀態,一般 master 會設定 protected 分支保護
- 只有有許可權的人才能推送程式碼到 master 分支
- 如果有新功能開發，可以從 master 分支上檢出新分支
- 在本地分支提交程式碼，並且保證按時向遠端倉庫推送
- 當你需要反饋或者幫助，或者你想合併分支時，可以發起一個 pull request。
- 當 review 或者討論通過後，程式碼會合併到目標分支
- 一旦合併到 master 分支，應該立即釋出
合併請求特點：
- 可以很好控制分支合併許可權
- 分支不是你想合併就合併，需要對方同意
- 程式碼 Review
issue tracking 問題追蹤
開發中，會用到很多第三方庫，然後使用過程中，出現了問題，是不是第一個反應是去這個第三方庫的 GitHub 倉庫去搜索一下 issue
，看沒有人遇到過，專案維護者修復了沒有，一般未解決的 issue 是 open 狀態，已解決的會被標記為 closed。這就是 issue
tracking
GitLab Flow
概述：
GitLab 既支援 Git Flow 的分支策略，也有 GitHub Flow 的 Pull Request（ Merge Request
） 和 issue tracking
存在問題：
- 版本的延遲釋出（例如 iOS 應用稽核到通過中間，可能也要在 master 上推送程式碼）
- 不同環境的部署 （例如：測試環境，預發環境，正式環境）
- 不同版本釋出與修復 （只有一個 master 分支真的不夠用）
- GitLab 推薦用生產分支來解決上述問題
- 對於"持續釋出"的專案，它建議在master分支以外，再建立不同的環境分支
上游優先原則：
什麼是上游優先：
- Gitlab flow 的最大原則叫做"上游優先"（upsteam first）
- 即只存在一個主分支master，它是所有其他分支的"上游"。只有上游分支採納的程式碼變化，才能應用到其他分支。
舉例：
- "開發環境"的分支是master，"預發環境"的分支是pre-production，"生產環境"的分支是production。
- 開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。程式碼的變化，必須由"上游"向"下游"發展。production。
- 比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合併到master，
- 確認沒有問題，再提交到pre-production，這一步也沒有問題，才進入production
版本釋出：
- 對於"版本釋出"的專案，建議的做法是每一個穩定版本，都要從master分支拉出一個分支
- 比如2-3-stable、2-4-stable等等。
- 以後，只有修補bug，才允許將程式碼合併到這些分支
- 並且此時要更新小版本號
合併請求
建立團隊：
填寫資訊
邀請成員
分支許可權與合併請求
在指定專案上建立分支：
預設主分支是受保護的
當一個分支是一個受保護的分支時,必須要發起合併請求後操作
設定分支許可權
設定儲存分支入口
展開分支儲存按鈕
忽略檔案
在專案開發中，我們使用git託管專案時往往會忽略一些不必要的檔案或資料夾
步驟：在版本庫根目錄建立.gitignore，修改檔案，新增忽略正則
規則：
？：代表任意的一個字元
＊：代表任意數目的字元 {!ab}：必須不是此型別 {ab,bb,cx}：代表ab,bb,cx中任一型別即可
[abc]：代表a,b,c中任一字元即可
[ ^abc]：代表必須不是a,b,c中任一字元
示例：
注意事項：
- 新增忽略之後，已經提交到版本庫中的檔案是無法忽略的,只能clone到本地，刪除後，再進行忽略
- gitignore只能忽略那些原來沒有被track的檔案，如果某些檔案已經被納入了版本管理中，則修改.gitignore是無效的。