“time-lapse photography of man standing beside road and bridge during daytime” by Ahsan Avi on Unsplash

我在提交中犯了一個(gè)錯(cuò)誤，我該如何解決？

我的提交歷史很糟糕，我該如何讓它更整潔？

如果你有過(guò)上述問(wèn)題，那么這篇文章適合你。這篇文章涵蓋了一系列主題，這些主題將使您成為Git專家。

如果您不了解Git基礎(chǔ)知識(shí)，請(qǐng)單擊此處查看我的Git基礎(chǔ)知識(shí)博客。您必須了解Git的基礎(chǔ)知識(shí)才能充分利用本文。

我的提交中犯了一個(gè)錯(cuò)誤。我該怎么辦？

場(chǎng)景1

假設(shè)您已經(jīng)提交了一堆文件并意識(shí)到您輸入的提交說(shuō)明跟實(shí)際上并不清楚?，F(xiàn)在您要更改提交說(shuō)明。為此，您可以使用git commit --amend

git commit --amend -m “New commit message”

情景2

假設(shè)您想提交六個(gè)文件，但是，錯(cuò)誤地，您最終只提交了五個(gè)文件。您可能認(rèn)為可以創(chuàng)建新提交并將第6個(gè)文件添加到該提交。

這種方法沒(méi)有錯(cuò)。但是，為了保持一個(gè)整潔的提交歷史，如果你真的能以某種方式將這個(gè)文件添加到你之前的提交本身，那不是更好嗎？這也可以通過(guò)以下方式完成git commit --amend：

git add file6
git commit --amend --no-edit

--no-edit 表示提交說(shuō)明不會(huì)更改。

場(chǎng)景3

無(wú)論何時(shí)在Git中進(jìn)行提交，提交都會(huì)附上作者姓名和作者電子郵件。通常，當(dāng)您第一次設(shè)置Git時(shí)，您需要設(shè)置作者姓名和電子郵件。您無(wú)需擔(dān)心每次提交的作者詳細(xì)信息。

也就是說(shuō)，對(duì)于特定項(xiàng)目，您可能希望使用不同的電子郵件ID。您需要使用以下命令為該項(xiàng)目配置電子郵件ID：

git config user.email “your email id”

假設(shè)您忘記配置電子郵件，并且已經(jīng)完成了第一次提交。Amend也可用于更改先前提交的作者?？梢允褂靡韵旅罡奶峤坏淖髡撸?/p>

git commit --amend --author "Author Name <Author Email>"

要點(diǎn)注意

只在本地存儲(chǔ)庫(kù)中使用modify命令。對(duì)遠(yuǎn)程存儲(chǔ)庫(kù)使用modify可能會(huì)造成很多混淆。

我的提交歷史是一團(tuán)糟。我該如何處理？

假設(shè)您正在處理一段代碼。您知道代碼大約需要十天才能完成。在這十天內(nèi)，其他開(kāi)發(fā)人員也將提交代碼到遠(yuǎn)程存儲(chǔ)庫(kù)。

將本地存儲(chǔ)庫(kù)代碼與遠(yuǎn)程存儲(chǔ)庫(kù)中的代碼保持同步是一種很好的做法。這會(huì)在您提出拉取請(qǐng)求時(shí)避免很多合并沖突。因此，您決定每?jī)商鞆倪h(yuǎn)程存儲(chǔ)庫(kù)中提取一次更改。

每次將代碼從遠(yuǎn)程存儲(chǔ)庫(kù)提取到本地存儲(chǔ)庫(kù)時(shí)，都會(huì)在本地存儲(chǔ)庫(kù)中創(chuàng)建新的合并提交。這意味著您的本地提交歷史將有大量的合并提交，這可能會(huì)使審閱者感到困惑。

以下是提交歷史記錄在本地存儲(chǔ)庫(kù)中的顯示方式。

如何使提交歷史更整潔？

這就需要rebase來(lái)處理。

什么是rebase？

讓我通過(guò)一個(gè)例子解釋一下。

此圖顯示了發(fā)布分支和功能分支中的提交

1. Release分支有三個(gè)提交：Rcommit1，Rcommit2和Rcommit3。
2. 您只在一次提交時(shí)從Release分支創(chuàng)建了Feature分支，即Rcommit1。
3. 您已向Feature分支添加了兩個(gè)提交。它們是Fcommit1和Fcommit2。
4. 您的目標(biāo)是從Release分支到您的Feature分支的提交。
5. 你將使用rebase來(lái)做到這一點(diǎn)。
6. 讓Release分支的名稱release ，F(xiàn)eature分支的名稱是feature。
7. 可以使用以下命令重新進(jìn)行重新定位：

git checkout feature
git rebase release

Rebasing

在重新定位時(shí)，您的目標(biāo)是確保功能分支從Release分支獲取最新代碼。

重新嘗試嘗試逐個(gè)添加每個(gè)提交，并檢查沖突。這聽(tīng)起來(lái)有點(diǎn)令人困惑嗎？

讓我在圖表的幫助下解釋。

這顯示了內(nèi)部實(shí)際的變革：

步驟1

1. 運(yùn)行該命令的那一刻，F(xiàn)eature分支指向Release分支的頭部。
2. 現(xiàn)在，F(xiàn)eature分支有三個(gè)提交：Rcommit1，Rcommit2和Rcommit3。
3. 您可能想知道Fcommit1和Fcommit2發(fā)生了什么。
4. 提交仍然存在，將在下面的步驟中使用。

第2步

1. 現(xiàn)在Git嘗試將Fcommit1添加到Feature分支。
2. 如果沒(méi)有沖突，則在Rcommit3之后添加Fcommit1
3. 如果存在沖突，Git會(huì)通知您，您必須手動(dòng)解決沖突。解決沖突后，使用以下命令繼續(xù)重新綁定

git add fixedfile
git rebase --continue

第3步

1. 一旦添加了Fcommit1，Git將嘗試添加Fcommit2。
2. 同樣，如果沒(méi)有沖突，則在Fcommit1之后添加Fcommit2并且rebase成功。
3. 如果存在沖突，Git會(huì)通知您，您必須手動(dòng)解決。解決沖突后，請(qǐng)使用步驟2中提到的相同命令
4. 整個(gè)rebase完成后，您會(huì)注意到Feature分支有Rcommit1，Rcommit2，Rcommit3，F(xiàn)commit1和Fcommit2。

注意事項(xiàng)

1. Rebase和Merge在Git中都很有用。Rebase并不比Merge好。
2. 在合并的情況下，您將進(jìn)行合并提交。在rebase的情況下，沒(méi)有像合并提交那樣的額外提交。
3. 一種最佳實(shí)踐是在不同點(diǎn)使用命令。使用遠(yuǎn)程存儲(chǔ)庫(kù)中的最新代碼更新本地代碼存儲(chǔ)庫(kù)時(shí)，請(qǐng)使用rebase。在處理pull請(qǐng)求以將Feature分支與Release或Master分支合并時(shí)，請(qǐng)使用merge。
4. 使用Rebase會(huì)改變提交歷史記錄（使其更整潔）。但話雖如此，改變提交歷史存在風(fēng)險(xiǎn)。因此，請(qǐng)確保永遠(yuǎn)不要對(duì)遠(yuǎn)程存儲(chǔ)庫(kù)中的代碼使用rebase。始終只使用rebase來(lái)更改本地倉(cāng)庫(kù)代碼的提交歷史記錄。
5. 如果對(duì)遠(yuǎn)程存儲(chǔ)庫(kù)進(jìn)行了rebase，則會(huì)產(chǎn)生很多混淆，因?yàn)槠渌_(kāi)發(fā)人員無(wú)法識(shí)別新的歷史記錄。
6. 此外，如果在遠(yuǎn)程存儲(chǔ)庫(kù)上完成rebase，則當(dāng)其他開(kāi)發(fā)人員嘗試從遠(yuǎn)程存儲(chǔ)庫(kù)中提取最新代碼時(shí)，它可能會(huì)產(chǎn)生問(wèn)題。所以我再說(shuō)一遍，總是只為本地存儲(chǔ)庫(kù)使用rebase??

恭喜

你現(xiàn)在是Git專家??