git操作與分支管理規(guī)范

一、git操作規(guī)范

git操作流程數(shù)據(jù)流圖

image.png
image.png
  1. Remote：遠程主倉庫
  2. Repository：本地倉庫
  3. Index：Git追蹤樹，暫存區(qū)
  4. workspace：本地工作區(qū)

代碼正常的提交流程

// 工作區(qū)
git status                         // 查看狀態(tài)
git add .                          // 將所有修改修改加入暫存區(qū)
git commit -m "提交描述"            // 將代碼提交到本地倉庫
git pull origin <共同開發(fā)的遠程分支> // 拉取共同開發(fā)的遠程分支，并合并到本地分支
git push                            // 將本地倉庫代碼更新到遠程倉庫

git add 進階

  • 場景1：工作區(qū)

當改動了工作區(qū)的某個文件時，想恢復修改前，用命令 git checkout -- <filename>

  • 場景2： 暫存區(qū)

當不但改動了工作區(qū)的某個文件時，想恢復修改前，還 git add 添加到了暫存區(qū)時，想丟棄修改，分兩步，<br />第一步用命令 git reset HEAD <filename>，回到場景1；<br />第二步按場景1操作。

git commit 進階

  • 場景1：更改 commit 信息

git commit --amend -m "新提交信息"

  • 場景2：漏提交
  1. git add <filename> git commit -m "提交信息" // git上會出現(xiàn)兩次 commit
  2. git add <filename> git commit --amend --no-edit // --no-edit 表示提交消息不會更改，在 git 上僅為一次提交
  • 場景3：提交了錯誤文件，則需要 git reset或 git revert

git reset

刪除指定的 commit

  1. --mixed 默認選項，會把暫存區(qū)里的東西重置到指定的提交狀態(tài)，并且指針指向這個提交。
  2. git reset --soft HEAD~1

修改版本庫，保留暫存區(qū)，保留工作區(qū)；<br />將版本庫軟回退1個版本，軟回退表示將本地版本庫的頭指針全部重置到指定版本，且將這次提交之后的所有變更都移動到暫存區(qū)。

  1. git reset --hard HEAD~1

修改版本庫，修改暫存區(qū)，修改工作區(qū)；<br />將版本庫回退1個版本，不僅僅是將本地版本庫的頭指針全部重置到指定版本，也會重置暫存區(qū)，并且會將工作區(qū)代碼也回退到這個版本。

  1. git reset --hard commit_id

git版本回退，回退到特定的 commit_id 版本，可以通過 git log 查看提交歷史，以便確定要回退到哪個版本( commit 之后的即為 ID )

git revert

撤銷某次操作，此次操作之前和之后的commit和history都會保留，并且把這次撤銷作為一次最新的提交。

  1. git revert HEAD

撤銷前一次 commit

  1. git revert HEAD^

撤銷前前一次 commit

  1. git revert commit-id

撤銷指定的版本，撤銷也會作為一次提交進行保存。 <br />
<br />git revert 是提交一個新的版本，將需要revert的版本的內容再反向修改回去， 版本會遞增，不影響之前提交的內容

git branch

  1. git branch ，git checkout -b [name_new_branch]

查看,創(chuàng)建并查看項目分支。

  1. git branch -d [name_branch]

刪除分支。

  1. git checkout [branch-name]

切換分支。

  1. git merge [your_branch]

合并分支。 注意：需要到主合并分支下合并，例如要合并某分支到master ,首先需要切換到master 分支下再進行合并。

  1. git diff [branch] [branch]

分支比較。 比較兩個分支上最后 commit 的內容的差別

  1. git branch -m [branch] [new_name_branch]

重命名branch

git stash

能夠將所有未提交的修改（工作區(qū)和暫存區(qū)）保存至堆棧中，用于后續(xù)恢復當前工作目錄。

  • git stash save

git stash save 和 git stash 的作用相同，區(qū)別在于前者可以加一個對應stash的名稱

  • git stash list

查看當前 stash列表中的內容

  • git stash pop

將當前 stash 中的內容彈出，并應用到當前分支對應的工作目錄上。該命令會將堆棧中最近保存的內容刪除。<br />如果從 stash 中恢復的內容和當前目錄中的內容發(fā)生了沖突，會提示出錯，可以通過創(chuàng)建新分支以解決沖突。

  • git stash apply

將堆棧中的內容應用到當前目錄，該命令不同于 git stash pop 會將內容從堆棧中刪除。<br />可以使用 git stash apply <stash_name> （如 stash@{1}）指定恢復哪個 stash 到當前的工作目錄。

  • git stash drop <stash_name>

從堆棧中移除某個指定的 stash。

  • git stash clear

清除堆棧中的所有內容。

  • git stash show

查看堆棧中最新保存的 stash 和當前目錄的差異。<br />git stash show stash@{1} 查看指定的 stash 和當前目錄的差異。<br />可以通過 git stash show -p 查看詳細的不同。

  • git stash branch

從最新的 stash 創(chuàng)建分支，可用于解決 stash 中的內容和當前工作區(qū)內容沖突。

遠程remote

  1. git remote add origin [git_address]

添加遠程地址

  1. git pull

拉取遠程主機某分支的更新，再與本地的指定分支合并（相當與fetch加上了合并分支功能的操作）

  1. git push origin master

分支推送到遠程的版本

優(yōu)化操作

  • 拉取代碼 git pull --rebase

假設提交線圖在執(zhí)行 pull 前是這樣的：<br />
image.png
image.png

<br />如果是執(zhí)行 git pull 后，提交線圖會變成這樣：<br />
image.png
image.png
<br />結果多出了 H 這個沒必要的提交記錄。如果是執(zhí)行 git pull --rebase 的話，提交線圖就會變成這樣：<br />
image.png
image.png
<br />F G 兩個提交通過 rebase 方式重新拼接在 C 之后，多余的分叉去掉了，目的達到。<br />
  • tip：rebase 在 git 中，算得上是『危險行為』

使用 git pull --rebase 比直接 pull 容易導致沖突的產生，如果預期沖突比較多的話，建議還是直接 pull。

  • 注意：

git pull = git fetch + git merge <br />git pull --rebase = git fetch + git rebase<br />

二、git分支管理規(guī)范

git 分支管理數(shù)據(jù)流圖

<br />
bigpicture-git-branch-all.png
bigpicture-git-branch-all.png

各主分支介紹

master 分支

  • master 分支為主分支，具有穩(wěn)定性，代碼是經過測試的且已具備部署生產環(huán)境的條件；
  • master 分支一般由 develop 分支或者 hotfix 分支合并，禁止直接對 master 分支進行直接修改。

develop 分支

  • develop 分支為開發(fā)分支，可以作為合入 master 分支的備選分支，此分支保存最新完成開發(fā)的功能以及經過測試后 bug 已被修復的代碼；
  • 一般開發(fā)新功能時，都是基于 develop 分支創(chuàng)建新的 feature 分支；
  • 從 develop 分支總能獲得項目最新開發(fā)進展的代碼。

feature 分支

  • feature 分支用于開發(fā)一個獨立的新的功能，基于 develop 分支創(chuàng)建；
  • 開發(fā)新的功能需要創(chuàng)建新的功能分支，命名格式可以以 feature- 或 feature/ 作為開頭，如 feature-login 或者 feature/login，不過最好在同一項目中統(tǒng)一開頭命名格式；
  • feature 分支最終也歸于 develop 分支或者被刪除。

release 分支

  • release 分支基于 develop 分支創(chuàng)建，為預上線分支，在發(fā)布前的提測階段，會以 release 分支代碼為基準提測；
  • release 最終歸于 develop 分支或 master 分支。分支命名可以以 relseae- 開頭；
  • release 分支可以用來做版本號等元素的準備工作、bug的修復、發(fā)布前的準備，創(chuàng)建 release 分支最好的時機是 develop 分支已完成對應版本的功能開發(fā)，新功能 feature 分支已合入 develop 分支且基本達到預期狀態(tài)。若在測試過程中存在 bug 需要修復，則可直接基于 release 分支修復并提交，此過程不做新功能的加入，新功能依舊基于 develop 分支開發(fā)；
  • 當測試完成并驗證再無新 bug 后，將 release 分支合并進 master 分支和 develop 分支，此時 master 分支為具備上線條件的分支。

hotfix 分支

  • hotfix 分支基于 master 分支創(chuàng)建，用于處理項目上線后發(fā)現(xiàn)的緊急的非預期 bug;
  • hotfix 分支最終歸于 develop 分支或 master 分支，分支命名可以以 hoxfix- 開頭；
  • 設立 hotfix 分支的原因，是為了避免開發(fā)新功能的排期受到線上 bug 的影響。

操作規(guī)范

commit messages 規(guī)范

項目當中好的 commit messages 規(guī)范編寫有助于多人維護項目和 review 項目，作為一名開發(fā)人員，也應該是一名項目的協(xié)作者，編寫規(guī)范的 commit messages 是基本的要求。<br />Angular 團隊的代碼 commit messages 規(guī)范是社區(qū)中比較合理且系統(tǒng)化的，如下圖：<br />

image.png
image.png
<br />Angular Git Commit Guidelines<br />https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines<br />

具體格式為
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type: 本次 commit 的類型，諸如 bugfix docs style 等
  • scope: 本次 commit 波及的范圍
  • subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調了幾點：
  1. 使用祈使句，是不是很熟悉又陌生的一個詞
  2. 首字母不要大寫
  3. 結尾無需添加標點
  • body: 同樣使用祈使句，在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |
  • footer: 描述與之關聯(lián)的 issue 或 break change，如 Closes #123 可關閉對應的 issue，詳情可見

Closing issues using keywords<br />https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue，使用 jira 時，我們在 commit message 中可以填寫其影響的JIRA_ID，若要開啟該功能需要先打通 jira 與 gitlab。參考文檔：https://docs.gitlab.com/ee/user/project/integrations/jira.html<br />一次 commit 的過程當中，type 和 subject 為必須描述的信息，其他信息可以根據(jù)本次提交改動的規(guī)模進行選擇描述。

type 的類型說明
  • feat: 添加新特性
  • fix: 修復bug
  • docs: 僅僅修改了文檔
  • style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
  • refactor: 代碼重構，沒有加新功能或者修復bug
  • perf: 增加代碼進行性能測試
  • test: 增加測試用例
  • chore: 改變構建流程、或者增加依賴庫、工具等

利用 Gitlab 平臺的能力

Merge Request && Code Review
  1. 合并遠程分支代碼時，使用 gitlab 平臺上的 New merge request
image.png
image.png

<br />

  1. 選擇 Source branch 和 Target branch
image.png
image.png

<br />

  1. 填寫合并信息和選擇Assignee
image.png
image.png

<br />

  1. Merge操作與Code Review
image.png
image.png

<br />如果對于 Changes 中的代碼有更好的方案，可以添加評論并且暫不點擊 Merge 操作合并代碼，等待代碼優(yōu)化后下次 push 代碼的時候會自動繼續(xù)走 Merge Request 的流程。<br />Code Review 不僅僅是去看對方的代碼寫得規(guī)不規(guī)范、細節(jié)上有沒有小問題，更多的是：

  1. 暫時忘記對方的代碼，如果讓你來實現(xiàn)這個需求，你會如何設計，跟對方的設計思路一致么？差異在哪里？誰的更優(yōu)？
  2. 暫時忘記具體的需求（或者你原本就不知道需求），看著對方的代碼，是否能夠理解他想完成一件什么事情么？他理解需求了么？他完成的好么？

其實 CR 就是對設計和實現(xiàn)的再次確認，在反復較量的過程中，相互學習和成長。如果以上兩個問題存在否定的答案，那就有必要好好寫寫 CR 評語了。

PipeLines

持續(xù)集成是一種軟件開發(fā)實踐，即團隊開發(fā)成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構建（包括編譯，發(fā)布，自動化測試)來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。許多團隊發(fā)現(xiàn)這個過程可以大大減少集成的問題，讓團隊能夠更快的開發(fā)內聚的軟件。

在 PineLines 中，可以集成 Gitlab-CI 和 Gilab-Runner。GitLab-Runner 是配合 GitLab-CI 進行使用的。一般地，GitLab 里面的每一個工程都會定義一個屬于這個工程的軟件集成腳本，用來自動化地完成一些軟件集成工作。當這個工程的倉庫代碼發(fā)生變動時，比如有人 push 了代碼，GitLab 就會將這個變動通知 GitLab-CI。這時 GitLab-CI 會找出與這個工程相關聯(lián)的 Runner，并通知這些 Runner 把代碼更新到本地并執(zhí)行預定義好的執(zhí)行腳本。<br />詳細的介紹和使用可以閱讀這篇文章 Gitlab-CI 和 Gitlab-Runner<br />https://www.cnblogs.com/cnundefined/p/7095368.html

Issues
image.png
image.png

<br />Issues 可以有兩個作用

  1. 團隊再需求評審之后，把各個功能模塊進行拆分，每個模塊都可以創(chuàng)建一個 issue，并填寫該 issue 的相關信息，最后指定 Assignee 對該模塊進行開發(fā)可配合 git 的 commit 信息進行相關操作，當該模塊開發(fā)完成，在 commit 可以指定相關 issue 進行關閉；
  2. 當需求開發(fā)完成并進行提測后，測試會測試出一些 bug，如果 bug 比較多且是多人名下的，開發(fā)團隊的管理可以把每個 bug 記錄為一個 issue，完成一個 bug 的修復便可自行 close 對應的 issue。

總之， Issues 把每個需求直接掛載對應人的名下，可以直接看出該需求的責任人。并且通過觀察所有的 Issues，可以直觀的看出當前的開發(fā)進度

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容