Just do it

如果你在剛剛的提交中，提交了一些錯(cuò)誤的信息，改如何處理它呢？

如果你的提交歷史十分混亂，又改如何讓它變得整潔一些呢？

如果你也有上述的麻煩要解決，這篇文章就是為你而寫的， 這篇文章中提到了一系列進(jìn)階的git使用方法用于處理這些問題，如果學(xué)會(huì)了這些，應(yīng)該就算得上是一個(gè)小git專家了吧。

如果你還不知道 git 的基本使用方法，可以點(diǎn)擊這里通過我的博客進(jìn)行了解， 了解基本的git使用方法可以幫助你更好的理解本文的內(nèi)容。

我進(jìn)行了一次錯(cuò)誤的提交，我該怎么辦呢？

場(chǎng)景一

如果你提交了一部分文件和修改，但是編寫的提交信息并不能很好的描述本次提交的內(nèi)容，如果你想要修改提交信息，該怎么辦呢，這個(gè)時(shí)候你可以使用 git commit --amend

git commit --amend -m "New commit message"

場(chǎng)景二

如果你在這次提交中總共修改了6個(gè)文件，但是你在提交的時(shí)候卻只提交了5個(gè)，這個(gè)時(shí)候你可能會(huì)想，我再提交一次，把這個(gè)文件加進(jìn)去不就可以了嗎。
這樣的處理方法并沒有什么問題，不過如果你在意一個(gè)整潔的提交歷史的話，為什么不想辦法，把這個(gè)文件添加到上次提交的內(nèi)容里面呢？通過使用git commit --amend你可以做到這個(gè)效果：

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

場(chǎng)景三

無論你在什么時(shí)候進(jìn)行提交，提交記錄中都會(huì)有你的名字和email信息， 通常情況下，在你第一次使用git的時(shí)候，你會(huì)進(jìn)行這些全局設(shè)置，不用擔(dān)心每次提交的時(shí)候都要進(jìn)行處理。

這也就是說，如果有一個(gè)特殊的項(xiàng)目你想在在提交的時(shí)候使用一個(gè)不同的email ID。 你需要在這個(gè)項(xiàng)目的git中進(jìn)行如下的配置：

git config user.email "your new email id"

假如，你忘記在這個(gè)特殊的項(xiàng)目里面進(jìn)行email ID 的修改，然后進(jìn)行了第一次提交。這個(gè)時(shí)候你可以使用Amend 修改你上次提交的作者。 你可以通過如下的命令來實(shí)現(xiàn)修改：

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

特別提醒： 使用amend命令只能在你的本地倉庫中使用，使用在遠(yuǎn)程庫上會(huì)導(dǎo)致一些奇怪的問題

我的提交歷史很是混亂，我改如何處理它呢？

比如說，現(xiàn)在你正在實(shí)現(xiàn)一個(gè)功能，你知道這個(gè)功能大概要十天的時(shí)間才能完成。 你從遠(yuǎn)程主分支開了一個(gè)新的分支來編寫這個(gè)功能。在這十天里面不停的會(huì)有同事將其他的代碼提交到遠(yuǎn)程主分支上。

為了保持你的分支代碼和主分支代碼是同一個(gè)進(jìn)度，你需要合并遠(yuǎn)程主分支到你的分支上，如果你在最后一天進(jìn)行合并，大量的修改可能會(huì)引發(fā)大量的沖突，一次性修改大量的沖突簡(jiǎn)直讓人發(fā)狂。所以你決定每?jī)商爝M(jìn)行一次分支合并以更新代碼。

每次你從遠(yuǎn)程主分支合并代碼到本地分支，都會(huì)創(chuàng)建一個(gè)新的提交。這意味著你的本地提交歷史會(huì)摻雜著非常多的合并提交記錄，這會(huì)讓review你代碼的人感覺提交非常的混亂。

混亂的合并提交記錄

那該如何讓提交歷史變得更整潔呢？

這個(gè)時(shí)候就該rebase粉墨登場(chǎng)了

什么是 rebasing ?

讓我通過一個(gè)例子來進(jìn)行解釋。

這幅圖顯示了遠(yuǎn)程主分支和你的功能分支的關(guān)系

1. 我們可以看到在 Release 分支上有3個(gè)提交記錄：Rcommit1, Rcommit2 和 Rconmit3。
2. 你在 Release 分支只有一個(gè) Rcommit1 提交的時(shí)候，創(chuàng)建了一個(gè)新的 Feature 分支。
3. 你隨后在 Feature 分支上進(jìn)行了兩次提交，分別是：Fcommit1 和 Fcommit2.
4. 你的目標(biāo)是將 Release 分支上的提交合并到你的 Feature 分支上。
5. 現(xiàn)在你可以使用rebase來實(shí)現(xiàn)它。
6. 我們假設(shè) Release 分支的名字就是release 而 Feature 分支的名字就是feature。
7. 我們通過rebase進(jìn)行如下指令進(jìn)行處理

git checkout feature
git rebase release

Rebasing

當(dāng)你進(jìn)行Rebasing的時(shí)候，你的目標(biāo)時(shí)保證你的 Feature 分支能夠更新到來自于 Release 分支上最新的代碼。

Rebasing 嘗試添加所有的提交，一個(gè)一個(gè)的添加，然后處理出現(xiàn)的沖突，是不是聽的有些困惑？

讓我通過一幅圖片來給你解釋。這展示了 rebasing 內(nèi)部進(jìn)行的實(shí)際操作。

Rebase流程圖

Step 1

1. 在你執(zhí)行命令的一瞬間，F(xiàn)eature 分支就定位到 Release 分支的頭部。
2. 現(xiàn)在 Feature 分支有三個(gè)提交記錄：Rcommit1， Rcommit2 和 Rcommit3。
3. 你可能驚訝在 Fcommit1 和 Fcommit 上發(fā)生了什么。
4. 這些提交實(shí)際還在這里，在接下的步驟里將會(huì)出現(xiàn)。

Step 2

1. 現(xiàn)在 Git 嘗試添加 Fcommit1 到 Feature 分支當(dāng)中。
2. 如果在 Fcommit1 添加到 Rcommit3 之后沒有發(fā)生沖突，就繼續(xù)
3. 如果發(fā)生了沖突，Git 將會(huì)提示你，然后必須手動(dòng)解決這些沖突。當(dāng)所有的沖突被解決以后，你可以使用如下命令恢復(fù) rebasing。

git add fixedfile
git rebase --continue

Step 3

1. 一旦 Fcommit1 被添加，Git 會(huì)嘗試添加 Fcommit2.
2. 同樣的，如果在 Fcommit2 被添加到 Fcommit1 以后沒有沖突發(fā)生則 rebase 成功。
3. 如果發(fā)生了沖突，Git 會(huì)提示你，你需要手動(dòng)解決這些沖突，然后重復(fù) Step 2的方法來恢復(fù) rebasing.
4. 當(dāng)所有的 rebase 完成以后，你發(fā)現(xiàn) Feature 分支上有所有的5個(gè)提交。

要點(diǎn)注意：

1. 無論是Rebase 還是 Merge 都是Git中強(qiáng)有力的工具，沒有孰好孰壞之說。
2. 如果使用 Merge 你會(huì)多一個(gè)合并提交記錄， 如果使用 Rebase 就不會(huì)出現(xiàn)一個(gè)多余的合并提交記錄。
3. 最好的實(shí)踐方法就是因情況而異，如果你想要從一個(gè)遠(yuǎn)程主分支合并最新的代碼到你的本地分支上，你可以選擇rebase。 如果你是要將你的本地分支重新合并會(huì)遠(yuǎn)程主分支，這個(gè)時(shí)候你可以選擇 merge。
4. 使用 Rebase 修改提交歷史可以讓它看起來更整潔。但是也可能會(huì)產(chǎn)生一些風(fēng)險(xiǎn)，所以，我們要確保一定不要在遠(yuǎn)程分支上使用rebase，通常我們只會(huì)去寫改本地分支的提交歷史。
5. 如果在遠(yuǎn)程分支上使用了rebase，當(dāng)其他的開發(fā)者試圖從遠(yuǎn)程分支上拉取代碼的時(shí)候會(huì)產(chǎn)生一些問題。所以重要的事情要說三遍，不要用在遠(yuǎn)程分支上，不要用在遠(yuǎn)程分支上，不要用在遠(yuǎn)程分支上。

恭喜你?。?！

現(xiàn)在，你已經(jīng)是一個(gè)Git專家了??

在這篇文章里你學(xué)會(huì)了：

• 修改錯(cuò)誤提交
• rebase

上述都是一些特別有用的技巧和觀點(diǎn)。接下來，讓我們繼續(xù)去探索 Git 世界，去學(xué)習(xí)更多實(shí)用的用法吧。

翻譯于 How to become a Git expert