git操作與分支管理規范

一、git操作規范

git操作流程數據流圖

Remote：遠程主倉庫

Repository：本地倉庫

Index：Git追蹤樹，暫存區

workspace：本地工作區

代碼正常的提交流程

// 工作區

git status // 查看狀態

git add . // 將所有修改修改加入暫存區

git commit -m "提交描述" // 將代碼提交到本地倉庫

git pull origin // 拉取共同開發的遠程分支，并合并到本地分支

git push // 將本地倉庫代碼更新到遠程倉庫

git add 進階

• 場景1：工作區

當改動了工作區的某個文件時，想恢復修改前，用命令 git checkout --

• 場景2：暫存區

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

git commit 進階

• 場景1：更改 commit 信息

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

• 場景2：漏提交

git add?git commit -m "提交信息" // git上會出現兩次 commit

git add?git commit --amend --no-edit // --no-edit 表示提交消息不會更改，在 git 上僅為一次提交

• 場景3：提交了錯誤文件，則需要 git reset或 git revert

git reset

刪除指定的 commit

--mixed 默認選項，會把暫存區里的東西重置到指定的提交狀態，并且指針指向這個提交。

git reset --soft HEAD~1

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

git reset --hard HEAD~1?

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

git reset --hard commit_id?

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

git revert

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

git revert HEAD?

撤銷前一次 commit?

git revert HEAD^?

撤銷前前一次 commit?

git revert commit-id?

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

git branch

git branch?，git checkout -b [namenewbranch]?

查看,創建并查看項目分支。?

git branch -d [name_branch]?

刪除分支。

git checkout [branch-name]?

切換分支。?

git merge [your_branch]?

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

git diff [branch] [branch]?

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

git branch -m [branch] [newnamebranch]

重命名branch

git stash

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

• git stash save

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

• git stash list

查看當前 stash列表中的內容

• git stash pop

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

• git stash apply

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

• git stash drop

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

• git stash clear

清除堆棧中的所有內容。

• git stash show

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

• git stash branch

從最新的 stash 創建分支，可用于解決 stash 中的內容和當前工作區內容沖突。

遠程remote

git remote add origin [git_address]?

添加遠程地址?

git pull?

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

git push origin master?

分支推送到遠程的版本?

優化操作

• 拉取代碼 git pull --rebase

假設提交線圖在執行 pull 前是這樣的：
如果是執行 git pull 后，提交線圖會變成這樣：
結果多出了 H 這個沒必要的提交記錄。如果是執行 git pull --rebase 的話，提交線圖就會變成這樣：
F G 兩個提交通過 rebase 方式重新拼接在 C 之后，多余的分叉去掉了，目的達到。

• tip：rebase 在 git 中，算得上是『危險行為』

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

• 注意：

git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase

二、git分支管理規范

git 分支管理數據流圖

各主分支介紹

master 分支

• master 分支為主分支，具有穩定性，代碼是經過測試的且已具備部署生產環境的條件；

• master 分支一般由 develop 分支或者 hotfix 分支合并，禁止直接對 master 分支進行直接修改。

develop 分支

• develop 分支為開發分支，可以作為合入 master 分支的備選分支，此分支保存最新完成開發的功能以及經過測試后 bug 已被修復的代碼；

• 一般開發新功能時，都是基于 develop 分支創建新的 feature 分支；

• 從 develop 分支總能獲得項目最新開發進展的代碼。

feature 分支

• feature 分支用于開發一個獨立的新的功能，基于 develop 分支創建；

• 開發新的功能需要創建新的功能分支，命名格式可以以 feature- 或 feature/ 作為開頭，如 feature-login 或者 feature/login，不過最好在同一項目中統一開頭命名格式；

• feature 分支最終也歸于 develop 分支或者被刪除。

release 分支

• release 分支基于 develop 分支創建，為預上線分支，在發布前的提測階段，會以 release 分支代碼為基準提測；

• release 最終歸于 develop 分支或 master 分支。分支命名可以以 relseae- 開頭；

• release 分支可以用來做版本號等元素的準備工作、bug的修復、發布前的準備，創建 release 分支最好的時機是 develop 分支已完成對應版本的功能開發，新功能 feature 分支已合入 develop 分支且基本達到預期狀態。若在測試過程中存在 bug 需要修復，則可直接基于 release 分支修復并提交，此過程不做新功能的加入，新功能依舊基于 develop 分支開發；

• 當測試完成并驗證再無新 bug 后，將 release 分支合并進 master 分支和 develop 分支，此時 master 分支為具備上線條件的分支。

hotfix 分支

• hotfix 分支基于 master 分支創建，用于處理項目上線后發現的緊急的非預期 bug;

• hotfix 分支最終歸于 develop 分支或 master 分支，分支命名可以以 hoxfix- 開頭；

• 設立 hotfix 分支的原因，是為了避免開發新功能的排期受到線上 bug 的影響。

操作規范

commit messages 規范

項目當中好的 commit messages 規范編寫有助于多人維護項目和 review 項目，作為一名開發人員，也應該是一名項目的協作者，編寫規范的 commit messages 是基本的要求。
Angular 團隊的代碼 commit messages 規范是社區中比較合理且系統化的，如下圖：
Angular Git Commit Guidelines
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具體格式為

<type>(<scope>): <subject>

<BLANK LINE>

<body>

<BLANK LINE>

<footer>

• type: 本次 commit 的類型，諸如 bugfix docs style 等

• scope: 本次 commit 波及的范圍

• subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調了幾點：

使用祈使句，是不是很熟悉又陌生的一個詞

首字母不要大寫

結尾無需添加標點

• body: 同樣使用祈使句，在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |

• footer: 描述與之關聯的 issue 或 break change，如 Closes #123 可關閉對應的 issue，詳情可見

Closing issues using keywords
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一次 commit 的過程當中，type 和 subject 為必須描述的信息，其他信息可以根據本次提交改動的規模進行選擇描述。

type 的類型說明

• feat: 添加新特性

• fix: 修復bug

• docs: 僅僅修改了文檔

• style: 僅僅修改了空格、格式縮進、逗號等等，不改變代碼邏輯

• refactor: 代碼重構，沒有加新功能或者修復bug

• perf: 增加代碼進行性能測試

• test: 增加測試用例

• chore: 改變構建流程、或者增加依賴庫、工具等

利用 Gitlab 平臺的能力

Merge Request && Code Review

合并遠程分支代碼時，使用 gitlab 平臺上的 New merge request

選擇 Source branch 和 Target branch

填寫合并信息和選擇Assignee

Merge操作與Code Review

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

暫時忘記對方的代碼，如果讓你來實現這個需求，你會如何設計，跟對方的設計思路一致么？差異在哪里？誰的更優？

暫時忘記具體的需求(或者你原本就不知道需求)，看著對方的代碼，是否能夠理解他想完成一件什么事情么？他理解需求了么？他完成的好么？

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

PipeLines

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

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

Issues

Issues 可以有兩個作用

團隊在需求評審之后，把各個功能模塊進行拆分，每個模塊都可以創建一個 issue，并填寫該 issue 的相關信息，最后指定 Assignee 對該模塊進行開發可配合 git 的 commit 信息進行相關操作，當該模塊開發完成，在 commit 可以指定相關 issue 進行關閉；

當需求開發完成并進行提測后，測試會測試出一些 bug，如果 bug 比較多且是多人名下的，開發團隊的管理可以把每個 bug 記錄為一個 issue，完成一個 bug 的修復便可自行 close 對應的 issue。

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

總結

以上是生活随笔為你收集整理的git stash 强制恢复_git操作与分支管理规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。