一、git操作規(guī)范

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

image.png

1. Remote：遠(yuǎn)程主倉(cāng)庫(kù)
2. Repository：本地倉(cāng)庫(kù)
3. Index：Git追蹤樹(shù)，暫存區(qū)
4. workspace：本地工作區(qū)

代碼正常的提交流程

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

git add 進(jìn)階

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

當(dāng)改動(dòng)了工作區(qū)的某個(gè)文件時(shí)，想恢復(fù)修改前，用命令 git checkout -- <filename>

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

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

git commit 進(jìn)階

• 場(chǎng)景1：更改 commit 信息

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

• 場(chǎng)景2：漏提交

1. git add <filename> git commit -m "提交信息" // git上會(huì)出現(xiàn)兩次 commit
2. git add <filename> git commit --amend --no-edit // --no-edit 表示提交消息不會(huì)更改，在 git 上僅為一次提交

• 場(chǎng)景3：提交了錯(cuò)誤文件，則需要 git reset或 git revert

git reset

刪除指定的 commit

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

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

3. git reset --hard HEAD~1

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

4. git reset --hard commit_id

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

git revert

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

1. git revert HEAD

撤銷(xiāo)前一次 commit

2. git revert HEAD^

撤銷(xiāo)前前一次 commit

3. git revert commit-id

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

git branch

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

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

2. git branch -d [name_branch]

刪除分支。

3. git checkout [branch-name]

切換分支。

4. git merge [your_branch]

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

5. git diff [branch] [branch]

分支比較。 比較兩個(gè)分支上最后 commit 的內(nèi)容的差別

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

重命名branch

git stash

能夠?qū)⑺形刺峤坏男薷模üぷ鲄^(qū)和暫存區(qū)）保存至堆棧中，用于后續(xù)恢復(fù)當(dāng)前工作目錄。

• git stash save

git stash save 和 git stash 的作用相同，區(qū)別在于前者可以加一個(gè)對(duì)應(yīng)stash的名稱(chēng)

• git stash list

查看當(dāng)前 stash列表中的內(nèi)容

• git stash pop

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

• git stash apply

將堆棧中的內(nèi)容應(yīng)用到當(dāng)前目錄，該命令不同于 git stash pop 會(huì)將內(nèi)容從堆棧中刪除。<br />可以使用 git stash apply <stash_name> （如 stash@{1}）指定恢復(fù)哪個(gè) stash 到當(dāng)前的工作目錄。

• git stash drop <stash_name>

從堆棧中移除某個(gè)指定的 stash。

• git stash clear

清除堆棧中的所有內(nèi)容。

• git stash show

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

• git stash branch

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

遠(yuǎn)程remote

1. git remote add origin [git_address]

添加遠(yuǎn)程地址

2. git pull

拉取遠(yuǎn)程主機(jī)某分支的更新，再與本地的指定分支合并（相當(dāng)與fetch加上了合并分支功能的操作）

3. git push origin master

分支推送到遠(yuǎn)程的版本

優(yōu)化操作

• 拉取代碼 git pull --rebase

image.png

image.png

image.png

• tip：rebase 在 git 中，算得上是『危險(xiǎn)行為』

使用 git pull --rebase 比直接 pull 容易導(dǎo)致沖突的產(chǎn)生，如果預(yù)期沖突比較多的話(huà)，建議還是直接 pull。

• 注意：

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

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

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

bigpicture-git-branch-all.png

各主分支介紹

master 分支

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

develop 分支

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

feature 分支

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

release 分支

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

hotfix 分支

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

操作規(guī)范

commit messages 規(guī)范

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

image.png

具體格式為

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

• type: 本次 commit 的類(lèi)型，諸如 bugfix docs style 等
• scope: 本次 commit 波及的范圍
• subject: 簡(jiǎn)明扼要的闡述下本次 commit 的主旨，在原文中特意強(qiáng)調(diào)了幾點(diǎn)：

1. 使用祈使句，是不是很熟悉又陌生的一個(gè)詞
2. 首字母不要大寫(xiě)
3. 結(jié)尾無(wú)需添加標(biāo)點(diǎn)

• body: 同樣使用祈使句，在主體內(nèi)容中我們需要把本次 commit 詳細(xì)的描述一下，比如此次變更的動(dòng)機(jī)，如需換行，則使用 |
• footer: 描述與之關(guān)聯(lián)的 issue 或 break change，如 Closes #123 可關(guān)閉對(duì)應(yīng)的 issue，詳情可見(jiàn)

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 時(shí)，我們?cè)?commit message 中可以填寫(xiě)其影響的JIRA_ID，若要開(kāi)啟該功能需要先打通 jira 與 gitlab。參考文檔：https://docs.gitlab.com/ee/user/project/integrations/jira.html<br />一次 commit 的過(guò)程當(dāng)中，type 和 subject 為必須描述的信息，其他信息可以根據(jù)本次提交改動(dòng)的規(guī)模進(jìn)行選擇描述。

type 的類(lèi)型說(shuō)明

• feat: 添加新特性
• fix: 修復(fù)bug
• docs: 僅僅修改了文檔
• style: 僅僅修改了空格、格式縮進(jìn)、都好等等，不改變代碼邏輯
• refactor: 代碼重構(gòu)，沒(méi)有加新功能或者修復(fù)bug
• perf: 增加代碼進(jìn)行性能測(cè)試
• test: 增加測(cè)試用例
• chore: 改變構(gòu)建流程、或者增加依賴(lài)庫(kù)、工具等

利用 Gitlab 平臺(tái)的能力

Merge Request && Code Review

1. 合并遠(yuǎn)程分支代碼時(shí)，使用 gitlab 平臺(tái)上的 New merge request

image.png

<br />

2. 選擇 Source branch 和 Target branch

image.png

<br />

3. 填寫(xiě)合并信息和選擇Assignee

image.png

<br />

4. Merge操作與Code Review

image.png

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

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

其實(shí) CR 就是對(duì)設(shè)計(jì)和實(shí)現(xiàn)的再次確認(rèn)，在反復(fù)較量的過(guò)程中，相互學(xué)習(xí)和成長(zhǎng)。如果以上兩個(gè)問(wèn)題存在否定的答案，那就有必要好好寫(xiě)寫(xiě) CR 評(píng)語(yǔ)了。

PipeLines

持續(xù)集成是一種軟件開(kāi)發(fā)實(shí)踐，即團(tuán)隊(duì)開(kāi)發(fā)成員經(jīng)常集成他們的工作，通常每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過(guò)自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測(cè)試)來(lái)驗(yàn)證，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過(guò)程可以大大減少集成的問(wèn)題，讓團(tuán)隊(duì)能夠更快的開(kāi)發(fā)內(nèi)聚的軟件。

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

Issues

image.png

<br />Issues 可以有兩個(gè)作用

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

總之， Issues 把每個(gè)需求直接掛載對(duì)應(yīng)人的名下，可以直接看出該需求的責(zé)任人。并且通過(guò)觀(guān)察所有的 Issues，可以直觀(guān)的看出當(dāng)前的開(kāi)發(fā)進(jìn)度