前言

hello大家好！本人前段時間在某站看了個歪嘴戰神的視頻，視頻中提到一包裝三年工作經驗的程序員，因進公司第一天不會使用git拉項目，第二天被開除。想想挺可怕的，學完這篇文章，我相信你會get到很多。好了，話不多說，come on！

正片

先介紹一下git是什么？

Git是一個開源的分布式版本控制系統，可以有效、高速地處理從很小到非常大的項目版本管理。

Git 是 Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。

1 基本配置

1.1 用戶信息

開發人員的用戶信息請使用中文拼音全拼寫法，比如“Zhang San”、“Li Si”這樣的，注意姓和名首字母大寫，中間留一空格，電子郵件地址統一填寫公司郵箱，比如“zhangsan@company.cn”。 命令行如下：

git config --global user.email "郵箱" git config --global user.name "用戶信息"

1.2 環境配置

Windows 由于權限系統和 macOS 有差異，換行也有所不同，所以對于 Windows 平臺使用 Git 需要進行下列配置：

git config --global core.filemode false git config --global core.autocrlf false

如果是 macOS 系統，則只需要執行：

git config --global core.autocrlf false

修改完成后可以通過 git config --global -l 查看是否改動成功，請注意一下。

在項目開發中，如果改變了文件或文件夾名稱的大小寫，默認情況下 git 是無法檢測到的，請各位執行以下命令關閉大小寫忽略。

git config --global core.ignorecae false

2 關于Git分支

分支功能是 git 最為強大的功能之一，它能夠讓你并發地在多個場景下進行開發。并且可以讓你同時開發不同功能而不沖突，用于區分功能或版本

長期分支：

master：主分支 可發布的穩定版分支，存放對外發布的版本，任何時候在這個分支拿到的，都是穩定的發布版本

develop：開發分支用于日常開發，存放最新的開發版

公共的開發主線分支，feature 功能分支的代碼開發完成后，經過 code review 后會合并到此分支

臨時分支：一旦完成開發，它們就會被合并進develop或master，然后被刪除。

feature branch：功能分支 一般是從 develop 開發分支上檢出(checkout)

hotfix branch：補丁分支 緊急修復，一般是用于修復上線后的生產環境的問題

release branch：預發分支 測試、發布主線，此分支是從 develop 分支上檢出(checkout), 一般是提測階段會使用該分支的代碼

2.1 主分支和開發分支

主分支命名為master，有且只有一個分支，所有正式版本都必須從master分支發布，并且又相關發布的Tag，master分支只能從其它分支合并，不能在這個分支上修改，禁止直接向 master 分支 Push 代碼；

日常開發分支命名為 develop，有且只有一個分支，原則上并行開發的時候，develop 分支承擔改動最大的方向，比如進行大規模的代碼重構、界面框架替換、大版本升級或者日常常規迭代升級等等。

2.2 臨時分支之功能分支

對于較大的功能版本升級，劃分不同的功能分支feature進行管理，一方面便于功能測試，另外一方面便于需求變更對應的代碼變更調整。【當前僅使用在本地分支，不要上傳到服務器，減少代碼沖突帶來的工作量】

命名為feature-*，后面的命名可以是小版本號，或者功能，或者較大任務的Jira ID號，feature-{[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gusCo6j6-1620444544764)(https://math.jianshu.com/math?formula=build_version_id%7D%EF%BC%8C%E6%88%96%E8%80%85%E6%98%AFfeature-%7B)]JiraID}，或是有命名意義的功能feature-{$featureName}如：feature-logedit，從develop分支拉出來處理。

處理完成后，代碼合并回develop分支一起提交服務器，合并后刪除該臨時分支。

2.3 臨時分支之補丁分支

對于正在主線上處理，但是需要臨時支援另外一個bug或者是另外事件觸發，可以單獨發布該分支。

命名為hotfix-*，命名可以是臨時處理的事件標識或者JiraID，如：hotfix-{[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-PX8rCXdN-1620444544766)(https://math.jianshu.com/math?formula=JiraID%7D%E3%80%81hotfix-%7B)]eventName}，需要從master分支拉出一個補丁分支臨時修改。

修改完后合并到release分支預發布以及master分支發布，合并完后刪除該臨時分支。

2.4 臨時分支之預發布分支

對于發布的版本，需要發布到預發布環境進行驗收，按版本號進行標識。

命名為release-*，命名需要根據版本，比如release-{[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-G2XIZ3Jm-1620444544768)(https://math.jianshu.com/math?formula=version_id%7D%EF%BC%8C%E6%88%96%E8%80%85%E6%98%AF%E4%B8%B4%E6%97%B6%E5%8F%91%E5%B8%83%E7%9A%84%E7%89%88%E6%9C%ACrelease-%7B)]version_id}-{$jiraID/eventName}，需要從其它分支（develop或hotfix）合并過來。

預發布后再進行master合并。

2.5 同一個代碼倉庫多個開發分支

對于多個服務共享一個代碼倉庫的情況，開發過程需要按服務分別拉分支開發，嚴禁都提交到Develop分支。

命名為“服務標識-dev”，當作Develop開發分支處理，最后發布頁需要合并到master分支。

2.6 各分支示意圖以及流程圖：

3 代碼提交

做完一件事情即可提交代碼，提交的備注文字盡量準確、簡潔，不要同時提交多件事情的代碼。

提交commit的注釋文字，需要簡單扼要，且充分考慮影響范圍，不要遺漏提交功能實現的描述。

Commit注釋規范，不同情形下區別：

以下是簡書上抄下來的，咱們重新規范下，按中文命名更容易記住：

• feat【新增】: Feature的縮寫, 新的功能或特性
• fix【bug修復】: bug的修復
• docs【文檔】: 文件修改, 比如修改應用了ngDoc的項目的ngDoc內容
• style【界面】: 格式修改. 比如改變縮進, 空格, 刪除多余的空行, 補上漏掉的分號. 總之, 就是不影響代碼含義和功能的修改
• refractor【重構】: 代碼重構. 一些不算修復bug也沒有加入新功能的代碼修改
• perf【優化】: Performance的縮寫, 提升代碼性能
• test【測試】: 測試文件的修改
• chore【其它】: 其他的小改動. 一般為僅僅一兩行的改動, 或者連續幾次提交的小改動屬于這種

如果有版本號，可增加版本號標識，整體更整潔 commit 模板 ps: 首字母小寫，并且結尾不加句號, 使用半角(英文)符號

git commit -m '<type>(<scope>): <subject> [<issue_id>]'git commit -m '新增(影響全局select組件UI樣式): 更改了select組件動畫效果 [issue-123]'

type: 分支行為

scope: 說明 commit 影響的范圍，比如數據層，控制層，視圖層等等，這個需要視具體場景與項目的不同而靈活變動

subject: 對于該 commit 目的的簡短描述

issue_id: 如果你的改動是針對git中的issue進行，請將issue_id添加到commit 記錄中

3.1 .gitignore文件

這個文件會配置忽略文件列表，請盡量放在工程的根目錄下，除了無需提交的臨時文件、編譯輸出等數據之外，本地用戶相關的一些配置也可以加入忽略列表。

3.2 每日構建

每日構建服務器一般會基于 release 分支進行，如果確定版本可以發布后，代碼會 merge 到 master 以及 develop 分支，然后通過 master 分支構建發布版本。

日常開發中也可以考慮開啟 develop 分支的每日構建，但原則上同一時間段只允許開啟一個分支的每日構建。

4 代碼發布

4.1 申請master分支合并：

從gitlab中可直接申請master合并，并由倉庫管理員負責合并；

4.2 申請版本發布：

在發布前的測試環境上，從對應的開發分支進行測試環境構建，至于測試環境規劃，另外篇章說明。【開發聯調與測試并行時候，需要考慮環境區分】

5 Git倉庫命名規范

項目名稱請用大寫，空間是部門命名，默認是CPStudio。

分類：

默認系統入口代碼，都以系統縮寫命名，比如CPStudio/EKP

前后端分離的api，以系統加_api命名，比如CPStudio/EKP_API

后端定時任務系統，以系統縮寫加_task，比如CPStudio/EKP_TASK

其它類別的子系統，以下劃線加有子系統含義的縮寫字母，比如CPStudio/EKP_RES，代表了EKP系統的模板庫資源。

6 便于 code review 的合作流程

在編寫代碼的時候，為了代碼的高質量與開發人員的知識共享，通常會加上代碼審查也就是 code review 環節。這個環節是借助 merge request 或者 pull request 來做到的，所以我們提交的 commit 記錄應該盡量保持為一個，這樣的好處有很多：

方便代碼審核者進行 code review，只需要看這一個 commit 記錄的邏輯即可, 萬一該 commit 的代碼導致出現問題，我們可以只針對這個 commit 進行快速回退。 一個功能保持一個 commit 記錄如果遇到需要對這個功能提前提交到某些環境比如生產環境上，我們可以快速用過 cherry-pick 命令，在對應的分支上"重現"該提交記錄，達到提前提交的目的。

也許你會有疑問，單個功能保持一個 commit 記錄與 commit 提交記錄盡量保持較細的粒度這一原則是否相悖，筆者覺得并沒有沖突，因為這兩個 git 協作要求是基于不同的角度來看待問題的，對于自己開發的分支上，我們需要保持每個提交的粒度在一個 commit 做一個修改，這樣有利于我們記錄工作內容與方便自己在本分支上做回滾，但是對于一個軟件開發的主分支來說，它上面的提交應該是以功能為單位的，而無需關心這個功能內開發人員開發這個功能做了多少次修改。

面對這種情況，我們會使用 rebase 命令，也就是衍合(變基)操作。所謂衍合就是將你此分支上的 commit 提交，按順序重新在某個分支上的某個基礎點重新"演繹"一次，而這個重新"演繹"重新提交的 commit 記錄與原來的 commit 提交會有些許不同，不同點在于 commit 的 HashId 會不同，但是提交內容是一樣的。

rebase 命令提供了交互式的界面，并且提供多種的命令讓你能夠將多個 commit 記錄合并為一個，從而達到我們單一功能保持一個 commit 記錄的目的，保持提交歷史的清爽。

7 git命令

Git 常用的是以下 6 個命令：git clone、git push、git add 、git commit、git checkout、git pull，當然還有很多命令，可以去官網查

• git clone：拷貝一份遠程倉庫，也就是下載一個項目。
• git push origin master：將文件給推到服務器上
• git add .：添加當前目錄的所有文件到暫存區
• git commit -m “提交文件信息”：提交暫存區到倉庫區
• git checkout [branch name]：切換到指定分支，并更新工作區
• git pull：本地與服務器端同步

8 SSH與HTTPS的區別

最后咱們回歸主題，對于 clone 項目，在管理Git項目上，很多時候都是直接使用https url克隆到本地，當然也有有些人使用SSH url克隆到本地。

這兩種方式的主要區別在于：

使用https url克隆對初學者來說會比較方便，復制https url然后到git Bash里面直接用clone命令克隆到本地就好了，但是每次fetch和push代碼都需要輸入賬號和密碼，這也是https方式的麻煩之處。

而使用SSH url克隆卻需要在克隆之前先配置和添加好SSH key，因此，如果你想要使用SSH url克隆的話，你必須是這個項目的擁有者。否則你是無法添加SSH key的，另外ssh默認是每次fetch和push代碼都不需要輸入賬號和密碼，如果你想要每次都輸入賬號密碼才能進行fetch和push也可以另外進行設置。

相關的文章
Git的官方站點，最新版本都可以從這里下載：git-scm.com/
Pro Git，一本全面介紹Git的圖書，非常詳細。
Git Magic，很通俗的一本介紹 Git 的書，比較短小精煉。

作者：Java斗帝之路
鏈接：https://www.jianshu.com/p/fd485dbea86a
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

總結

以上是生活随笔為你收集整理的进公司不会用 Git 拉项目！第二天被开除？的全部內容，希望文章能夠幫你解決所遇到的問題。

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