分享一篇通俗易懂的可視化Git命令
戳藍(lán)字「TianTianUp」關(guān)注我們哦！
前言
今天分享一篇不錯(cuò)的文章，描述的內(nèi)容是Git Commands。展開(kāi)描述了一些使用的案例，來(lái)創(chuàng)建一些最常見(jiàn)和最有用的命令的可視化例子！
本文使用的是默認(rèn)的指令行為，不需要添加太多的配置，每個(gè)覆蓋的命令有很多的可選參數(shù)，你可以動(dòng)手來(lái)改變它們的行為。
一些指令
Merge
擁有多個(gè)分支是非常方便的，可以讓新的變更相互分離，并確保你不會(huì)意外地將未經(jīng)批準(zhǔn)或損壞的變更推送到生產(chǎn)中。一旦變更被批準(zhǔn)，我們就想把這些變更放到生產(chǎn)分支中去。
從一個(gè)分支到另一個(gè)分支的方法之一是執(zhí)行 git 合并。Git 可以執(zhí)行兩種類型的合并：一種是快進(jìn)，一種是不快進(jìn)。這可能現(xiàn)在還不是很明白，那我們就來(lái)看看兩者的區(qū)別吧!
Fast-forward (--ff)
快進(jìn)（--ff）
當(dāng)前分支與我們要合并的分支相比，沒(méi)有額外的提交時(shí)，就會(huì)發(fā)生快進(jìn)式合并。
Git 是個(gè)......懶惰的家伙，會(huì)先嘗試執(zhí)行最簡(jiǎn)單的選項(xiàng)：快進(jìn)！這種類型的合并并不創(chuàng)建新的提交，而是合并當(dāng)前分支上的提交。
這種類型的合并并不創(chuàng)建新的提交，而是將當(dāng)前分支上的提交合并到當(dāng)前分支上。
完美！我們現(xiàn)在已經(jīng)將開(kāi)發(fā)分支上的所有修改都放到了主分支上。現(xiàn)在，我們已經(jīng)將開(kāi)發(fā)分支上所做的所有改動(dòng)都放到了主分支上。那么，這個(gè) "不快進(jìn) "是怎么回事呢？
No-fast-foward (--no-ff)
如果你的當(dāng)前分支與你要合并的分支相比，沒(méi)有任何額外的提交，那是很好的，但不幸的是，這種情況很少！如果我們?cè)诋?dāng)前分支上提交了改動(dòng)，而我們要合并的分支卻沒(méi)有，那么git就會(huì)執(zhí)行不快進(jìn)式合并。如果我們?cè)诋?dāng)前分支上提交了一些變化，而我們要合并的分支卻沒(méi)有，那么 git 就會(huì)執(zhí)行不快進(jìn)合并。
在進(jìn)行無(wú)快進(jìn)合并時(shí)，Git 會(huì)在當(dāng)前分支上創(chuàng)建一個(gè)新的合并提交。該提交的父提交同時(shí)指向活動(dòng)分支和我們要合并的分支。
沒(méi)什么大不了的，一個(gè)完美的合并！主分支現(xiàn)在包含了我們?cè)陂_(kāi)發(fā)分支上的所有改動(dòng)。
Merge Conflicts
合并沖突也是我們?nèi)粘ｉ_(kāi)發(fā)中不可避免的一個(gè)過(guò)程。
雖然Git很擅長(zhǎng)決定如何合并分支和添加文件的修改，但它并不總是能自己做出決定。這可能發(fā)生在我們?cè)噲D合并的兩個(gè)分支在同一文件的同一行有修改，或者一個(gè)分支刪除了另一個(gè)分支修改的文件，等等。
在這種情況下，Git會(huì)讓你幫忙決定我們要保留這兩個(gè)選項(xiàng)中的哪一個(gè)! 假設(shè)在兩個(gè)分支中，我們都編輯了 README.md 中的第一行。
如果我們要把dev合并成master，這將最終導(dǎo)致合并沖突：你希望標(biāo)題是Hello?還是Hey？
當(dāng)嘗試合并分支時(shí)，Git會(huì)告訴你沖突發(fā)生在哪里。我們可以手動(dòng)刪除我們不想保留的改動(dòng)，保存改動(dòng)，再次添加改動(dòng)后的文件，然后提交這些改動(dòng):
這里圖片幀數(shù)太大了，上傳不了，可以復(fù)制鏈接:
雖然合并沖突往往很煩人，但它完全有道理。Git不應(yīng)該只是假設(shè)我們想保留哪一個(gè)變化。
Rebasing
開(kāi)發(fā)中，變基也是我們通常需要做的。
我們剛剛看到了如何通過(guò)執(zhí)行 git merge 將一個(gè)分支的更改應(yīng)用到另一個(gè)分支。另一種將一個(gè)分支的修改添加到另一個(gè)分支的方法是執(zhí)行 git rebase。
git rebase 會(huì)復(fù)制當(dāng)前分支的提交，并將這些復(fù)制后的提交放在指定分支之上。
很好，我們現(xiàn)在可以在開(kāi)發(fā)分支上看到所有在主分支上做的修改了！我們可以在開(kāi)發(fā)分支上看到所有在主分支上做的修改。
與合并相比，最大的不同是，Git不會(huì)試圖找出哪些文件要保留，哪些文件不要保留。我們要重新歸類的分支總是有我們想保留的最新改動(dòng)！這樣一來(lái)，就不會(huì)有任何合并沖突，而且還能保持良好的線性 Git 歷史。這樣一來(lái)，您不會(huì)遇到任何合并沖突，而且還能保持良好的線性 Git 歷史。
這個(gè)例子顯示了在主分支上的重歸類。然而，在大型項(xiàng)目中，你通常不希望這樣做。git重歸會(huì)改變項(xiàng)目的歷史，因?yàn)樾碌墓?huì)被創(chuàng)建在復(fù)制的提交上。
每當(dāng)你在一個(gè)功能分支上工作，而主分支已經(jīng)更新時(shí)，重命名是非常好的。你可以在你的分支上獲得所有的更新，這將防止未來(lái)的合并沖突!
Resetting
可能發(fā)生的情況是，我們提交了一些我們后來(lái)不想要的改動(dòng)。也許是一個(gè)WIP提交，或者是一個(gè)引入了bug的提交！在這種情況下，我們可以用一個(gè)新的方法來(lái)解決這個(gè)問(wèn)題。在這種情況下,我們需要使用 git reset。
git reset 重置可以擺脫所有當(dāng)前的階段性文件，并讓我們控制 HEAD 應(yīng)該指向哪里。
Soft reset
soft reset 將 HEAD 移動(dòng)到指定的提交（或與 HEAD 相比的提交索引），而不會(huì)刪除之后提交中引入的變化！這就是soft reset。
假設(shè)我們不想保留添加了style.css文件的提交9e78i，也不想保留添加了index.js文件的提交035cc。然而，我們確實(shí)想保留新添加的style.css和index.js文件。這是一個(gè)完美的軟復(fù)位案例。
當(dāng)輸入 git status 時(shí)，你會(huì)發(fā)現(xiàn)我們?nèi)匀豢梢栽L問(wèn)之前提交的所有更改。這很好，因?yàn)檫@意味著我們可以修正這些文件的內(nèi)容，并在以后再次提交！這也是我們的一個(gè)優(yōu)勢(shì)。
Hard reset
有時(shí)，我們不想保留某些提交所帶來(lái)的變化。與軟重置不同，我們不需要再訪問(wèn)它們。Git 應(yīng)該簡(jiǎn)單地將它的狀態(tài)重置回指定提交時(shí)的狀態(tài)：這甚至包括了工作目錄和暫存文件中的變化！而不是像軟重置一樣，我們不應(yīng)該再去訪問(wèn)它們。
Git 拋棄了在 9e78i 和 035cc 上引入的改動(dòng)，并將其狀態(tài)重置為提交 ec5be 時(shí)的狀態(tài)。
Reverting
另一種撤銷修改的方法是執(zhí)行 git revert。通過(guò)還原某個(gè)提交，我們創(chuàng)建了一個(gè)新的提交，其中包含了被還原的更改！這就是我們的方法。
比方說(shuō)，ec5be增加了一個(gè)index.js文件。后來(lái)，我們其實(shí)意識(shí)到我們不想要這個(gè)提交引入的這個(gè)變化了! 讓我們恢復(fù)ec5be的提交。
完美 提交 9e78i 還原了 ec5be 提交引入的修改。執(zhí)行 git revert 非常有用，可以在不修改分支歷史的情況下撤銷某個(gè)提交。
Cherry-picking
當(dāng)某個(gè)分支包含了我們需要在活動(dòng)分支上進(jìn)行修改的提交時(shí)，我們可以使用 cherry-pick 命令！
通過(guò) cherry-pick 命令，我們可以在活動(dòng)分支上創(chuàng)建一個(gè)包含 cherry-pick 提交的修改的新提交。
通過(guò)cherry-pick命令，我們?cè)诨顒?dòng)分支上創(chuàng)建了一個(gè)新的提交，該提交包含了cherry-pick提交所引入的變更。
假設(shè)在開(kāi)發(fā)分支上的提交76d12對(duì)index.js文件進(jìn)行了修改，而我們希望把它放在主分支上。我們不需要整個(gè)分支，我們只需要這一個(gè)提交。
這樣子操作過(guò)后，主干分支現(xiàn)在包含了76d12引入的變化!
Fetching
如果我們有一個(gè)遠(yuǎn)程 Git 分支，比如 Github 上的一個(gè)分支，可能會(huì)發(fā)生遠(yuǎn)程分支的提交內(nèi)容是當(dāng)前分支沒(méi)有的！可能是另一個(gè)分支合并了，你的同事推送了快速修復(fù)，等等。也許另一個(gè)分支被合并了，你的同事推送了一個(gè)快速修復(fù)，等等。
我們可以通過(guò)在遠(yuǎn)程分支上執(zhí)行 git fetch 來(lái)獲取這些變化！這不會(huì)影響你的本地分支：fetch 只是下載新數(shù)據(jù)。它不會(huì)以任何方式影響你的本地分支：獲取只是下載新數(shù)據(jù)。
現(xiàn)在，我們可以看到自上次推送以來(lái)所做的所有更改！我們可以決定如何處理新的數(shù)據(jù)。我們可以決定我們想對(duì)新數(shù)據(jù)做什么，現(xiàn)在我們已經(jīng)在本地?fù)碛辛怂?/p>
Pulling
雖然git fetch對(duì)于獲取分支的遠(yuǎn)程信息非常有用，但我們也可以執(zhí)行g(shù)it pull。
git pull實(shí)際上是兩個(gè)命令合一：
一個(gè)是git fetch。 一個(gè)是git merge。
當(dāng)我們從原點(diǎn)拉取變更時(shí)，我們首先要像git fetch那樣獲取所有數(shù)據(jù)，之后將最新的變更自動(dòng)合并到本地分支中。
太棒了，我們現(xiàn)在與遠(yuǎn)程分支完全同步了，并且有了所有最新的變化。
Reflog
每個(gè)人都會(huì)犯錯(cuò)，這完全沒(méi)問(wèn)題！有時(shí)候，你可能會(huì)覺(jué)得自己把git repo搞砸了，以至于想把它完全刪除。有時(shí)候，你可能會(huì)覺(jué)得自己把git repo搞砸了，以至于你想把它完全刪掉:
git reflog 是一個(gè)非常有用的命令，它可以顯示所有已經(jīng)進(jìn)行的操作的日志！這包括合并、重置、還原：基本上所有對(duì)分支的修改。這包括合并、重置、還原：基本上是對(duì)你的分支進(jìn)行的任何修改。
如果你犯了錯(cuò)誤，你可以根據(jù)reflog給我們的信息重新設(shè)置head，輕松重做!
假設(shè)我們其實(shí)并不想合并原生分支，那么當(dāng)我們執(zhí)行g(shù)it reflog命令時(shí)，會(huì)發(fā)現(xiàn)合并前的repo狀態(tài)是在HEAD@{1}。
當(dāng)我們執(zhí)行 git reflog 命令時(shí)，我們看到合并前 repo 的狀態(tài)是在 HEAD@{1}。
讓我們執(zhí)行 git 重置，把 HEAD 指向 HEAD@{1} 的位置吧!
我們可以看到，最新的行動(dòng)已經(jīng)被推到了重新登錄！
結(jié)束語(yǔ)
Git在團(tuán)隊(duì)開(kāi)發(fā)中還是很重要的，本篇文章分享了部分Git命令，還是挺容易懂的，推薦閱讀。
我是TianTian，我們下一期見(jiàn)！！！
END
“分享、點(diǎn)贊、在看” 支持一波 