git操做與分支管理規範

時間  2020-11-10
標籤 javascript html java git github app ide 工具 gitlab 性能 欄目 Git 简体版
原文   原文鏈接

1、git操做規範

git操做流程數據流圖

image.png

  1. Remote：遠程主倉庫
  2. Repository：本地倉庫
  3. Index：Git追蹤樹，暫存區
  4. workspace：本地工做區

代碼正常的提交流程

// 工做區
git status                         // 查看狀態
git add .                          // 將全部修改修改加入暫存區
git commit -m "提交描述"            // 將代碼提交到本地倉庫
git pull origin <共同開發的遠程分支> // 拉取共同開發的遠程分支，併合併到本地分支
git push                            // 將本地倉庫代碼更新到遠程倉庫

git add 進階

  • 場景1：工做區

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

  • 場景2： 暫存區

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

git commit 進階

  • 場景1：更改 commit 信息

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

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

git reset

刪除指定的 commitgit

  1. --mixed 默認選項，會把暫存區裏的東西重置到指定的提交狀態，而且指針指向這個提交。
  2. git reset --soft HEAD~1

修改版本庫，保留暫存區，保留工做區；
將版本庫軟回退1個版本，軟回退表示將本地版本庫的頭指針所有重置到指定版本，且將此次提交以後的全部變動都移動到暫存區。 github

  1. git reset --hard HEAD~1 

修改版本庫，修改暫存區，修改工做區；
將版本庫回退1個版本，不只僅是將本地版本庫的頭指針所有重置到指定版本，也會重置暫存區，而且會將工做區代碼也回退到這個版本。app

  1. git reset --hard commit_id 

git版本回退，回退到特定的 commit_id 版本，能夠經過 git log 查看提交歷史，以便肯定要回退到哪一個版本( commit 以後的即爲 ID ) 
ide

git revert

撤銷某次操做，這次操做以前和以後的commit和history都會保留，而且把此次撤銷做爲一次最新的提交。  工具

  1. git revert HEAD 

撤銷前一次 commit gitlab

  1. git revert HEAD^ 

撤銷前前一次 commit 性能

  1. git revert commit-id 

撤銷指定的版本，撤銷也會做爲一次提交進行保存。 


git revert 是提交一個新的版本，將須要revert的版本的內容再反向修改回去， 版本會遞增，不影響以前提交的內容

git branch

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

查看,建立並查看項目分支。 

  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

可以將全部未提交的修改（工做區和暫存區）保存至堆棧中，用於後續恢復當前工做目錄。

  • 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_name> （如 stash@{1}）指定恢復哪一個 stash 到當前的工做目錄。

  • git stash drop <stash_name>

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

  • git stash clear

清除堆棧中的全部內容。

  • git stash show

查看堆棧中最新保存的 stash 和當前目錄的差別。
git stash show stash@{1} 查看指定的 stash 和當前目錄的差別。
能夠經過 git stash show -p 查看詳細的不一樣。

  • git stash branch

從最新的 stash 建立分支，可用於解決 stash 中的內容和當前工做區內容衝突。

遠程remote

  1. git remote add origin [git_address] 

添加遠程地址 

  1. git pull 

拉取遠程主機某分支的更新，再與本地的指定分支合併（至關與fetch加上了合併分支功能的操做） 

  1. git push origin master 

分支推送到遠程的版本 

優化操做

  • 拉取代碼 git pull --rebase

假設提交線圖在執行 pull 前是這樣的：
image.png
若是是執行 git pull 後，提交線圖會變成這樣：
image.png
結果多出了 H 這個不必的提交記錄。若是是執行 git pull --rebase 的話，提交線圖就會變成這樣：
image.png
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

2、git分支管理規範

git 分支管理數據流圖


bigpicture-git-branch-all.png

各主分支介紹

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 規範是社區中比較合理且系統化的，以下圖：
image.png
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 的主旨，在原文中特地強調了幾點：
  1. 使用祈使句，是否是很熟悉又陌生的一個詞
  2. 首字母不要大寫
  3. 結尾無需添加標點
  • 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
  1. 合併遠程分支代碼時，使用 gitlab 平臺上的 New merge request

image.png

  1. 選擇 Source branch 和 Target branch

image.png

  1. 填寫合併信息和選擇Assignee

image.png

  1. Merge操做與Code Review

image.png
若是對於 Changes 中的代碼有更好的方案，能夠添加評論而且暫不點擊 Merge 操做合併代碼，等待代碼優化後下次 push 代碼的時候會自動繼續走 Merge Request 的流程。
Code Review 不只僅是去看對方的代碼寫得規不規範、細節上有沒有小問題，更多的是：

  1. 暫時忘記對方的代碼，若是讓你來實現這個需求，你會如何設計，跟對方的設計思路一致麼？差別在哪裏？誰的更優？
  2. 暫時忘記具體的需求（或者你本來就不知道需求），看着對方的代碼，是否可以理解他想完成一件什麼事情麼？他理解需求了麼？他完成的好麼？

其實 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
http://www.javashuo.com/article/p-ttejewie-ev.html

Issues

image.png
Issues 能夠有兩個做用

  1. 團隊再需求評審以後，把各個功能模塊進行拆分，每一個模塊均可以建立一個 issue，並填寫該 issue 的相關信息，最後指定 Assignee 對該模塊進行開發可配合 git 的 commit 信息進行相關操做，當該模塊開發完成，在 commit 能夠指定相關 issue 進行關閉；
  2. 當需求開發完成並進行提測後，測試會測試出一些 bug，若是 bug 比較多且是多人名下的，開發團隊的管理能夠把每一個 bug 記錄爲一個 issue，完成一個 bug 的修復即可自行 close 對應的 issue。

總之， Issues 把每一個需求直接掛載對應人的名下，能夠直接看出該需求的責任人。而且經過觀察全部的 Issues，能夠直觀的看出當前的開發進度，

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程