GitHub、GitLab、Git 操作的一些規範

時光_靜好發表於2021-07-20
GithubGitlab

GitHub、GitLab、Git 操作的一些規範

不規範的 commit message 導致填寫內容隨意、質量參差不齊，可讀性低亦難以維護。

分支規範

  • master分支為主分支(保護分支)，不能直接在master上進行修改程式碼和提交
  • develop分支為測試分支，所有開發完成需要提交測試的功能合併到該分支
  • production分支為生產分支，所有測試完需要提交生產的功能合併到該分支
  • feature分支為開發分支，大家根據不同需求建立獨立的功能分支，開發完成後合併到develop分支
  • fix分支為bug修復分支，需要根據實際情況對已釋出的版本進行漏洞修復

Commit 格式規範

提交格式：type(scope)：subject

type：用於說明commit的類別，規定為如下幾種 :

  • feat：新增功能；

  • fix：修復bug；

  • docs：修改文件；

  • refactor：程式碼重構，未新增任何功能和修復任何bug；

  • build：改變構建流程，新增依賴庫、工具等（例如webpack修改）；

  • style：僅僅修改了空格、縮排等，不改變程式碼邏輯；

  • perf：改善效能和體現的修改；

  • chore：非src和test的修改；

  • test：測試用例的修改；

  • ci：自動化流程配置修改；

  • revert：回滾到上一個版本；

    示例 enter description here
    enter description here
    enter description here
    enter description here

Ignore 規則

  • 忽略檔案中的空行或以井號（#）開始的行將會被忽略。

  • 可以使用Linux萬用字元。例如：星號（*）代表任意多個字元，問號（？）代表一個字元，方括號（[abc]）代表可選字元範圍，大括號（{string1,string2,...}）代表可選的字串等。

  • 如果名稱的最前面有一個感嘆號（!），表示例外規則，將不被忽略。

  • 如果名稱的最前面是一個路徑分隔符（/），表示要忽略的檔案在此目錄下，而子目錄中的檔案不忽略。

  • 如果名稱的最後面是一個路徑分隔符（/），表示要忽略的是此目錄下該名稱的子目錄，而非檔案（預設檔案或目錄都忽略）。

Stash 和 Pop

相關命令

git stash 將工作區隱藏

git stash list 獲取隱藏工作區列表

git stash pop 獲取最上面一個隱藏工作區程式碼並刪除

git stash apply 獲取最上面一個隱藏工作區程式碼，但不刪除

git stash drop  刪除最上面一個隱藏工作區程式碼

git stash apply stash@{0} 獲取指定位置的隱藏工作區程式碼
複製程式碼

常見的問題

1. 如何恢復已經刪除掉的分支？

在記得提交號的情況下，可以使用 git reset –hard id的方式來將指標指向已刪除的分支內容。如果提交號不記得的情況下，也是有辦法恢復已刪除的分支的。首先通過git reflog來獲取近期的每一次命令，然後查詢刪除分支最近的一次提交，找到提交號，則又可以順利的取回分支內容。

2.當下正在進行dev程式碼開發，突然來了生產bug1.0需要及時修復，但是dev下開發的程式碼又沒提交，這個時候該如何操作？

先通過git stash 將當前工作區程式碼隱藏到棧中，儲存臨時狀態。再切出一個fixbug分支來解決問題，當問題解決後，通過git stash pop取回隱藏到棧中的工作區程式碼，繼續dev的開發。通過git stash pop命令取回工作區程式碼的同時，還會將棧中之前推進去的程式碼刪除。git stash list是檢視所有臨時工作區程式碼。也可以通過git stash apply stash@{0}來精確恢復棧中的程式碼。

3. 如何解決衝突問題 使用命令提交出現衝突的問題

只能是用第三方軟體compare軟體,比較兩個檔案的區別來進行修改。

使用介面提交出現的衝突問題 enter description here

  • 採用當前更改：保留當前，捨棄遠端
  • 採用傳入的更改：捨棄當前，保留遠端
  • 保留雙方更改：在對應位置保留雙方
  • 比較更改：對比檔案，進行修改

總結

編碼規範、流程規範在軟體開發過程中是至關重要的，它可以使我們在開發過程中少走很多彎路。Git commit規範也是如此，確實也是很有必要的，幾乎不花費額外精力和時間，但在之後查詢問題的效率卻很高。作為一名程式設計師，我們更應注重程式碼和流程的規範性，永遠不要在質量上將就。

相關文章