vivo TWS Air開箱體驗(yàn)：真輕 臻好聽
在vivo S15系列新機(jī)的發(fā)布會(huì)上，vivo的最新款真無線藍(lán)牙耳機(jī)vivo TWS Air也一同發(fā)布，本次就這款耳機(jī)新品給大家?guī)硪粋€(gè)簡(jiǎn)單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產(chǎn)
作為一個(gè)新時(shí)代的開發(fā)者，想必大家在工作中，有一樣?xùn)|西是和大家「形影不離」的。那就是git。(當(dāng)然，這里也有個(gè)例，如果大家項(xiàng)目還停留在svn階段，就算我剛才的話唐突了)。
無論大家平時(shí)是喜歡在命令行中手搓git命令，還是利用git可視化工具(SourceTree)進(jìn)行代碼管理。終究都逃不過，add/commit/merge/push等命令的支配。所以，今天我們來聊聊，在進(jìn)行這些命令的時(shí)候，在最底層到底發(fā)生了啥。
還有一點(diǎn)，也算是一個(gè)認(rèn)知提升吧。需要和大家嘮叨一下，以后遇到比較棘手的問題，可以往這方面來靠攏
所有軟件的底層實(shí)現(xiàn)都是「操作和管理數(shù)據(jù)」。
無論是我們平時(shí)用到的桌面程序，亦或是在命令行中進(jìn)行敲敲打打處理一些特定的操作，還有就是我們熟悉的編程開發(fā)中，無論是前端的開發(fā)過程中，使用原生也好，各種框架也罷，最后的根結(jié)都是數(shù)據(jù)的羅列和排布;還是后端就更明顯了，有SQL的操作，那就更是再「玩弄」數(shù)據(jù)。 之所以我們看到的現(xiàn)象有些不同，無非就是數(shù)據(jù)的表現(xiàn)形式和處理方式的不同。可以說，在編程界，--「萬物皆數(shù)據(jù)」。
這里簡(jiǎn)單舉一個(gè)例子，日歷大家都見過哇。
如果，給我們一個(gè)需求，要讓我們實(shí)現(xiàn)一個(gè)飛書日歷或者google 日歷的開發(fā)任務(wù)，我們是不是一時(shí)感覺到無法下手。
那我們往「萬物皆數(shù)據(jù)」這個(gè)定論上靠，那是不是每一個(gè)「日程」（無論是簡(jiǎn)單日程還是重復(fù)日程），它們本質(zhì)上就是在每個(gè)小格子上展示。無非就是有的日程在單個(gè)格子上，有的日程是跨格子。 而針對(duì)這種情況，是不是就是在當(dāng)前視圖中，我們需要維護(hù)一個(gè)數(shù)組，而這個(gè)數(shù)組中的項(xiàng)就是每個(gè)格子的示例。(針對(duì)月視圖/周視圖/日視圖的數(shù)據(jù)，其實(shí)都是一套，只不過在框架內(nèi)部為我們提供了各自的展示邏輯)
這是一個(gè)開源的日歷庫(FullCalendar)。
圖片
而下面的events就是我們?cè)谌諝v上顯示的日程信息。
圖片
好了，天不早了，干點(diǎn)正事哇。
「前置知識(shí)點(diǎn)」，只是做一個(gè)概念的介紹，不會(huì)做深度解釋。因?yàn)椋@些概念在下面文章中會(huì)有出現(xiàn)，為了讓行文更加的順暢，所以將本該在文內(nèi)的概念解釋放到前面來。「如果大家對(duì)這些概念熟悉，可以直接忽略」同時(shí)，由于閱讀我文章的群體有很多，所以有些知識(shí)點(diǎn)可能「我視之若珍寶，爾視只如草芥，棄之如敝履」。以下知識(shí)點(diǎn)，請(qǐng)「酌情使用」。
Git是一種用于源代碼管理的工具。它是一個(gè)免費(fèi)且開源的版本控制系統(tǒng)，用于高效地處理從小型到非常大型的項(xiàng)目。Git用于跟蹤源代碼的更改，使多個(gè)開發(fā)人員能夠共同在非線性開發(fā)中合作。Git是由Linus Torvalds于2005年為L(zhǎng)inux內(nèi)核的開發(fā)而創(chuàng)建的。
在使用Git之前在維護(hù)代碼之前，團(tuán)隊(duì)合作的模式如下：
圖片
它的典型代表為SVN
圖片
毋庸置疑，git是這方面的王者。
git commit -m “xxx” 就是「將 index 里的內(nèi)容提交到本地倉庫中」
remote repository：是「遠(yuǎn)程倉庫」，當(dāng)我們使用git push命令時(shí)就會(huì)將本地倉庫的代碼上傳至遠(yuǎn)程倉庫，完成整個(gè)代碼的上傳工作
圖片
git init --bare 和 git init 是兩種不同的Git初始化命令，它們用于創(chuàng)建不同類型的Git倉庫。
下面是它們之間的主要區(qū)別：
git init 默認(rèn)創(chuàng)建一個(gè)帶有master分支的工作目錄倉庫。
git init --bare 默認(rèn)不創(chuàng)建分支，因?yàn)槁銈}庫不包含工作目錄。我們需要手動(dòng)創(chuàng)建和設(shè)置分支。
一般情況下，如果我們需要?jiǎng)?chuàng)建一個(gè)新的Git倉庫用于開發(fā)和維護(hù)代碼，我們應(yīng)該使用 git init。如果我們需要?jiǎng)?chuàng)建一個(gè)中央版本庫用于團(tuán)隊(duì)協(xié)作和共享代碼，我們可以考慮使用 git init --bare。
鉤子（Hooks）是一種通用概念，通常用于「在特定事件發(fā)生時(shí)觸發(fā)自定義代碼」。雖然不是編程語言本身的一部分，但編程語言和開發(fā)工具通常提供一些機(jī)制來支持編寫和使用鉤子。
下面我們簡(jiǎn)單介紹幾種大家比較常見的利用Hook概念的技術(shù)。
名稱 | 描述 | 示例語法 |
Git Hooks | Git 允許在代碼倉庫的特定事件上運(yùn)行自定義腳本。事件包括提交、推送、合并等。 | 使用 Bash 腳本編寫，如 |
JavaScript Hooks | JavaScript 用于前端和后端開發(fā)，事件處理程序在特定事件發(fā)生時(shí)執(zhí)行自定義 JavaScript 代碼。 | 前端中，事件處理程序如事件監(jiān)聽器。后端中，使用 EventEmitter 模塊。 |
React Lifecycle Hooks | React 用于構(gòu)建用戶界面，包括生命周期方法，允許在組件的不同生命周期階段運(yùn)行自定義代碼。 | 生命周期方法如 當(dāng)然，還有甚囂塵上的針對(duì)函數(shù)組件的 |
GitHub Webhooks | GitHub 提供 Webhooks，是 HTTP 回調(diào)，用于在存儲(chǔ)庫的特定事件上觸發(fā)自定義操作。 | 開發(fā)者編寫 Webhook 處理程序響應(yīng)事件，配置 Webhook URL。 |
Jenkins Pipeline Hooks | Jenkins 是一個(gè)持續(xù)集成工具，允許創(chuàng)建自定義流水線腳本。使用鉤子定義流水線的階段和操作。 | 鉤子嵌入到 Jenkinsfile 中以定義流水線。 |
Git Hook是一種非常強(qiáng)大的Git自定義「腳本系統(tǒng)」，它允許我們?cè)贕it版本控制過程的不同階段執(zhí)行自定義操作。這些操作可以是自動(dòng)化測(cè)試、代碼格式化、驗(yàn)證提交消息格式、預(yù)防性錯(cuò)誤檢查等等。Git hooks是一種強(qiáng)大的自定義工具，可以提高代碼質(zhì)量和協(xié)作效率。
「pre-commit」：在執(zhí)行實(shí)際提交之前運(yùn)行，用于執(zhí)行「預(yù)提交檢查」。
「pre-push」：在執(zhí)行實(shí)際推送之前運(yùn)行，用于「驗(yàn)證推送到遠(yuǎn)程倉庫的內(nèi)容」。
「pre-receive」：在接收端執(zhí)行，通常用于「驗(yàn)證推送到遠(yuǎn)程倉庫的提交」。
「post-receive」：在接收端執(zhí)行，通常用于「通知或自動(dòng)化部署」。
git diff命令后通常需要跟兩個(gè)參數(shù)，參數(shù)1是要比較的舊代碼，參數(shù)2是要比較的新代碼。如果只寫一個(gè)參數(shù)，表示默認(rèn)跟 workspace 中的代碼作比較。
?
git diff 顯示的結(jié)果為「第二個(gè)參數(shù)所指的代碼在第一個(gè)參數(shù)所指代碼基礎(chǔ)上的修改」
?
HEAD 指向的是 local repository 中的代碼最新提交版本
在Git中，別名（Git Aliases）是一種機(jī)制，允許我們?yōu)槌Ｓ玫腉it命令或命令序列創(chuàng)建簡(jiǎn)短的自定義命令。別名使我們可以用更短、更易記的名稱來執(zhí)行常用的Git操作，提高工作效率。
「1. 創(chuàng)建別名：」 我們可以使用git config命令來創(chuàng)建Git別名。
git config --global alias.<alias-name> <git-command-or-sequence>「2. 例子：」 以下是一些Git別名的例子：
git config --global alias.co checkout # 創(chuàng)建 'co' 別名來代替 'checkout'git config --global alias.br branch # 創(chuàng)建 'br' 別名來代替 'branch'git config --global alias.ci commit # 創(chuàng)建 'ci' 別名來代替 'commit'git config --global alias.st status # 創(chuàng)建 'st' 別名來代替 'status'git config --global alias.unstage 'reset HEAD --' # 創(chuàng)建 'unstage' 別名來取消暫存「3. 使用別名：」 創(chuàng)建別名后，我們可以在命令行中使用它們。例如，使用上面的例子，我們可以這樣執(zhí)行命令：
git co my-branch # 等同于 'git checkout my-branch'git br -a # 等同于 'git branch -a'git ci -m "Message" # 等同于 'git commit -m "Message"'git st # 等同于 'git status'git unstage file.txt # 等同于 'git reset HEAD -- file.txt'從基本層面上說，Git只是一堆「通過文件名相互關(guān)聯(lián)的文本文件」。
還有一點(diǎn)需要提前聲明，如果大家也在自己的電腦中進(jìn)行實(shí)驗(yàn)，下面文章中出現(xiàn)的各種hash值，都是和內(nèi)容有關(guān)系。所以，大家要和自己的內(nèi)容對(duì)號(hào)入座，不要和本文中的hash值比較。
為了演示方便，我們?cè)诒镜氐暮线m的文件夾中新建了一個(gè)dot_git的項(xiàng)目。
mkdir dot_git與此同時(shí)通過git init來初始化項(xiàng)目。
圖片
現(xiàn)在讓我們來看看.git文件夾中有什么內(nèi)容。
我們使用erd來查看文件結(jié)構(gòu)。
erd -y inverted .git文檔結(jié)構(gòu)如下
圖片
看起來它創(chuàng)建了一堆文件和文件夾。讓我們挑幾個(gè)重要的來解釋一下：
根據(jù)我們?cè)O(shè)置的“默認(rèn)”分支是什么（git config --global init.defaultBranch <分支名稱>），它將是refs/heads/master(默認(rèn))，refs/heads/main，或者我們?cè)O(shè)置的其他分支名稱。
圖片
「它指向了refs/heads文件夾」，并指向一個(gè)叫做master的文件，這個(gè)文件在我們進(jìn)行第一次提交之前是不存在的。
這個(gè)master文件「只會(huì)在我們進(jìn)行第一次提交后出現(xiàn)」。
如果我們查看它，我們會(huì)看到一些關(guān)于我們的倉庫的基本設(shè)置，比如是否bare、文件模式等。
objects包含了Git對(duì)象，也就是關(guān)于倉庫中文件、提交等的「數(shù)據(jù)」。（這個(gè)狠最重要，狠重要）
refs，存儲(chǔ)引用（指針）的地方。
refs/heads包含分支的指針
refs/tags包含標(biāo)簽的指針
現(xiàn)在，我們已經(jīng)了解了.git目錄中初始文件的情況，讓我們執(zhí)行第一個(gè)將內(nèi)容添加到.git目錄的操作。我們將創(chuàng)建一個(gè)文件并將其添加到暫存區(qū)（但還沒有提交）。
echo 'hello,789' > filegit add file我們繼續(xù)使用erd -y inverted .git來查看文件變化。
圖片
git add file這會(huì)引起兩個(gè)主要的更改。
我們使用file來查看一下內(nèi)容是何方神圣。
file .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa: zlib compressed data結(jié)果顯示這是經(jīng)過zlib壓縮的數(shù)據(jù)。這就很讓人抓馬。「你有張良計(jì),我有過墻梯」，我們可以使用zlib庫對(duì)其解壓處理。
zlib-flate -uncompress < .git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aablob 10hello,789結(jié)果顯示它包含了文件名為file的文件的類型、大小和數(shù)據(jù)。
也就是說，/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa表示它是一個(gè)大小為10的blob，內(nèi)容是hello,789的數(shù)據(jù)。（只不過是被zlib處理了）
上面提到的/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa這是Git對(duì)象的一部分，用于存儲(chǔ)文件內(nèi)容。
注意，此時(shí)我們用到了zlib庫，我們可以通過brew install zlib下載該庫。(我是Mac環(huán)境，其他環(huán)境大家自行尋找解決方案)
文件名來自內(nèi)容的SHA-1 hash值。
如果我們將zlib壓縮的數(shù)據(jù)通過sha1sum命令處理，我們會(huì)得到文件名。
$ zlib-flate -uncompress <.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa | sha1sumc3dc8e6cf3e1117a8d9731ddde9916da644296aaGit使用內(nèi)容的SHA-1散列值，取「前兩個(gè)字符」（在這種情況下是c3），創(chuàng)建一個(gè)文件夾，然后將剩余部分用作文件名。Git從前兩個(gè)字符創(chuàng)建文件夾，以確保我們不會(huì)在單個(gè)objects文件夾下有太多文件。
在Mac環(huán)境下，我們需要通過brew install md5sha1sum
由于objects的內(nèi)容在Git中比較重要，Git還特意提供了一個(gè)名為git cat-file的命令，用于查看git對(duì)象的內(nèi)容。 使用git cat-file命令
git cat-file -t c3dc8e6cf3e1117a8d9731ddde9916da644296aablobgit cat-file -s c3dc8e6cf3e1117a8d9731ddde9916da644296aa10git cat-file -p c3dc8e6cf3e1117a8d9731ddde9916da644296aahello,789既然，已經(jīng)將內(nèi)容通過git add 添加到Index（暫存區(qū)），接下來我們就需要將內(nèi)容commit到local repository：(本地倉庫)
前面講過，下面的ci等同于commit。
git ci -m '首次提交'繼續(xù)使用erd -y inverted .git 來查看目錄結(jié)構(gòu)
圖片
嚯，一下多了很多文件。讓我們來解讀一下。
首先是一個(gè)新文件COMMIT_EDITMSG，它包含了（最新的）提交消息。
如果我們運(yùn)行g(shù)it ci命令而沒有使用-m標(biāo)志，那么Git獲取提交消息的方式是打開一個(gè)文本編輯器，使用COMMIT_EDITMSG文件來讓用戶編輯提交消息。一旦用戶更新了消息并退出編輯器，Git就會(huì)使用該文件的內(nèi)容作為提交消息。
它還添加了一個(gè)全新的logs文件夾。這是Git用來「記錄倉庫中所有提交更改的一種方式」。我們將能夠「在這里看到所有refs和HEAD的提交更改」。
在refs/heads目錄，其中新增了一個(gè)名為master的文件。這是對(duì)主分支（master）的引用。
使用cat查看對(duì)于的內(nèi)容信息。
cat .git/refs/heads/masterfe010b33df5078cdbd96f2397aad60ec5f42a967看起來它指向了其中一個(gè)新對(duì)象。我們用內(nèi)置命令cat-file查看內(nèi)容。
$ git cat-file -t fe010b33df5078cdbd96f2397aad60ec5f42a967commit$ git cat-file -p fe010b33df5078cdbd96f2397aad60ec5f42a967tree 658524b859ae78d902597253a3b68b4da3b70466author xxx <xxx@simple> 1697178492 +0800committer xxx <xxx@xxx> 1697178492 +0800首次提交我們也可以使用以下命令查看該引用的類型：git cat-file -t refs/heads/master
看起來這是一種新的對(duì)象類型，似乎是一個(gè)「提交對(duì)象」（commit object）。提交對(duì)象的內(nèi)容告訴我們，它包含一個(gè)哈希為658524b859ae78d902597253a3b68b4da3b70466的「樹對(duì)象」（tree object），這看起來就像我們?cè)谔峤粫r(shí)添加的另一個(gè)對(duì)象。提交對(duì)象還包含了作者和提交者的信息。最后，它還顯示了這個(gè)提交的提交消息是什么。
我們繼續(xù)來看看樹對(duì)象包含了什么內(nèi)容。
git cat-file -t 658524b859ae78d902597253a3b68b4da3b70466treegit cat-file -p 658524b859ae78d902597253a3b68b4da3b70466100644 blob c3dc8e6cf3e1117a8d9731ddde9916da644296aa file我們會(huì)發(fā)現(xiàn)該文件指向了在我們執(zhí)行g(shù)it add file時(shí)添加的原始對(duì)象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。
圖片
樹對(duì)象內(nèi)部使用更多的樹對(duì)象來表示文件夾，這些樹對(duì)象與提交對(duì)象相連，用于表示目錄結(jié)構(gòu)。
讓我們對(duì)文件進(jìn)行更改并查看它是如何工作的。
echo 'git,hello,789' > filegit ci -am "修改文件內(nèi)容"還是利用erd查看文檔目錄
圖片
一個(gè)包含文件新內(nèi)容的blob對(duì)象
一個(gè)是一個(gè)樹對(duì)象
最后一個(gè)是一個(gè)提交對(duì)象
讓我們?cè)俅螐腍EAD或refs/heads/master開始跟蹤它們。
git cat-file -p refs/heads/mastertree 02185c57f2040abcaa0c67dfd7026464d916da2bparent fe010b33df5078cdbd96f2397aad60ec5f42a967author 789 <789@xx> 1697179597 +0800committer 789 <789@xxx> 1697179597 +0800修改文件內(nèi)容git cat-file -p 02185c57f2040abcaa0c67dfd7026464d916da2b100644 blob 1f9224976e282aa9e32398a5bca0cec08041f1dc filegit cat-file -p 1f9224976e282aa9e32398a5bca0cec08041f1dcgit,hello,789提交對(duì)象現(xiàn)在有一個(gè)額外的屬性，名為parent，它鏈接到「前一個(gè)提交」，因?yàn)檫@個(gè)提交是建立在前一個(gè)提交之上的。
這是Git中的提交歷史的關(guān)鍵概念，
每個(gè)提交都有一個(gè)或多個(gè)父提交，形成一個(gè)提交鏈。
是時(shí)候創(chuàng)建一個(gè)分支了。讓我們使用git br fix-text命令創(chuàng)建一個(gè)名為fix-text的分支。
前面講過，下面的br等同于branch。
圖片
這將在refs/heads文件夾下創(chuàng)建一個(gè)新文件，文件名為分支名稱，文件內(nèi)容為最新提交的ID。
我們首先用git log查看提交記錄
圖片
發(fā)現(xiàn)最新的提交記錄為efa223e697c6452a393963887f9926ea0662c923
cat .git/refs/heads/fix-textefa223e697c6452a393963887f9926ea0662c923在Git中，分支是非常輕量級(jí)的。標(biāo)簽（Tags）的行為也類似，只不過它們是創(chuàng)建在refs/tags下的。
還會(huì)在logs目錄下添加一個(gè)文件，用于存儲(chǔ)與主分支類似的提交歷史數(shù)據(jù)。這有助于跟蹤各個(gè)分支的提交歷史。Git的分支和標(biāo)簽是非常有用的版本控制工具，可以幫助我們管理項(xiàng)目的不同狀態(tài)和版本。
在Git中，檢出（checkout）操作是獲取「提交」的樹對(duì)象，并將working tree中的文件更新為與樹對(duì)象記錄的狀態(tài)相匹配。
圖片
在這種情況下，因?yàn)槲覀儚膍aster切換到fix-text，而這兩個(gè)分支「都指向相同的提交和底層樹對(duì)象」，Git在working tree中沒有任何事情要處理。
前面講過，下面的co等同于checkout。
git co fix-text在.git目錄內(nèi)執(zhí)行co操作時(shí)，唯一的變化是.git/HEAD文件現(xiàn)在將指向fix-text。
cat .git/HEADref: refs/heads/fix-text另外，讓我進(jìn)行一次提交。
echo 'hello,git' > filegit ci -am "更換文本內(nèi)容"這將在fix-text分支上創(chuàng)建一個(gè)新的commit，將文件file中的內(nèi)容更改為hello,git。
合并（merging）有主要三種方式。
在這種情況下，我們首先逐個(gè)將我們的更改應(yīng)用到主分支（main或master）當(dāng)前指向的每個(gè)提交，然后執(zhí)行類似于快進(jìn)合并的操作。
最后一種方式是通過創(chuàng)建一個(gè)獨(dú)立的合并提交來合并兩個(gè)分支。
這在于它將在其提交對(duì)象中有兩個(gè)父節(jié)點(diǎn)（parent entries）。
首先，讓我們看看在合并之前圖形是什么樣子。(先將分支切換回master(git co master))
git log --graph --oneline --all* 4359ab4 (fix-text) 更換文本內(nèi)容* efa223e (HEAD -> master) 修改文件內(nèi)容* fe010b3 首次提交執(zhí)行合并操作
git merge fix-text更新 efa223e..4359ab4Fast-forward file | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)上面的操作，將一個(gè)master分支的引用（指向的哈希值）更新為fix-text分支的引用指向的哈希值。
git log --graph --oneline --all* 4359ab4 (HEAD -> master, fix-text) 更換文本內(nèi)容* efa223e 修改文件內(nèi)容* fe010b3 首次提交為了演示這一點(diǎn)，首先讓我創(chuàng)建另一個(gè)Git倉庫，它可以作為這個(gè)倉庫的遠(yuǎn)程倉庫。
新建一個(gè)「裸」倉庫
$ mkdir fake_git_remote$ cd fake_git_remote && git init --bare切換到我們dot_git項(xiàng)目中，為倉庫設(shè)置remote
git remote add origin ../fake_git_remote順便說一下，添加一個(gè)新的遠(yuǎn)程倉庫是一項(xiàng)配置更改，我們可以在.git/config文件中查看這個(gè)更改。我會(huì)讓我們自己去查看這個(gè)更改是什么。
圖片
現(xiàn)在讓我們進(jìn)行推送操作。
git push origin master讓我們看看我們的本地倉庫中發(fā)生了什么變化。
圖片
它添加了一個(gè)新的refs/remotes，用于存儲(chǔ)有關(guān)不同遠(yuǎn)程倉庫中的所有可用內(nèi)容的信息。
但是發(fā)送到另一個(gè)Git倉庫的是什么呢？實(shí)際上，
發(fā)送的內(nèi)容就是.git/objects目錄中的所有對(duì)象，以及我們顯式推送的refs下的所有分支和標(biāo)簽。
這就是另一個(gè)Git倉庫需要獲取我們的完整Git歷史記錄所需的一切內(nèi)容。
圖片
本文鏈接：http://www.www897cc.com/showinfo-26-14703-0.html您有一篇Git 原理，請(qǐng)注意查收
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)