git 代理 git_如何成為Git專家

git 代理 git

I made a mistake in my commit, how do I fix it ?

我在提交中犯了一個錯誤，該如何解決？

My commit history is a mess, how do I make it neater?

我的提交歷史是一團糟，我如何使其更整潔？

If you have ever had the above questions, then this post is for you. This post covers a list of topics which will make you a Git expert.

如果您曾經遇到上述問題，那么這篇文章適合您。這篇文章涵蓋了一個主題列表，這些主題將使您成為Git專家。

If you do not know Git basics, click here to check out my blog on Git basics. It is necessary that you know basics of Git to make the best use of this article.

如果您不了解Git基礎知識，請單擊此處查看有關Git基礎知識的博客。為了充分利用本文，有必要了解Git的基礎知識。

我犯了一個錯誤。我該怎么辦？ (I made a mistake in my commit. What should I do?)

場景1 (Scenario 1)

Let’s say that you have committed a bunch of files and realised that the commit message you entered is actually not clear. Now you want to change the commit message. In order to do this you can use git commit --amend

假設您已經提交了一堆文件，并且意識到您輸入的提交消息實際上并不清晰。現在您要更改提交消息。為此，您可以使用git commit --amend

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

方案2 (Scenario 2)

Let’s say that you wanted to commit six files but, by mistake, you end up committing only five files. You may think that you can create a new commit and add the 6th file to that commit.

假設您要提交六個文件，但是由于錯誤，您最終只能提交五個文件。您可能認為您可以創建一個新的提交并將第六個文件添加到該提交中。

There is nothing wrong with this approach. But, to maintain a neat commit history, wouldn’t it be nicer if you could actually somehow add this file to your previous commit itself? This can be done through git commit --amend as well:

這種方法沒有錯。但是，為了保持簡潔的提交歷史記錄，如果您實際上可以以某種方式將此文件添加到以前的提交本身中，會不會更好？這也可以通過git commit --amend來完成：

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

--no-edit means that the commit message does not change.

--no-edit表示提交消息不會更改。

場景3 (Scenario 3)

Whenever you do a commit in Git, the commit has an author name and author email tied to it. Generally, when you set up Git for the first time, you set up the author name and email. You don’t need to worry about the author details for every commit.

每當您在Git中進行提交時，該提交都會帶有作者姓名和作者電子郵件。通常，首次設置Git時，需要設置作者姓名和電子郵件。您無需擔心每次提交的作者詳細信息。

That said, it’s possible that for a particular project you want to use a different email ID. You need to configure the email id for that project with the command:

也就是說，對于特定項目，您可能想要使用其他電子郵件ID。您需要使用以下命令為該項目配置電子郵件ID：

git config user.email "your email id"

Let’s say that you forgot to configure the email and already did your first commit. Amend can be used to change the author of your previous commit as well. The author of the commit can be changed using the following command:

假設您忘記配置電子郵件，并且已經進行了第一次提交。 Amend也可以用于更改您先前提交的作者。可以使用以下命令來更改提交的作者：

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

注意事項 (Point to note)

Use the amend command only in your local repository. Using amend for the remote repository can create a lot of confusion.

僅在本地存儲庫中使用amend命令。對遠程存儲庫使用amend可能會造成很多混亂。

我的提交歷史是一團糟。我該如何處理？ (My Commit history is a mess. How do I handle it?)

Let’s say that you are working on a piece of code. You know that the code is going to take approximately ten days to complete. Within those ten days, the other developers will also be committing code to the remote repository.

假設您正在編寫一段代碼。您知道該代碼大約需要十天才能完成。在這十天內，其他開發人員還將把代碼提交到遠程存儲庫。

It is a good practise to keep your local repository code up-to-date with the code in the remote repository. This avoids a lot of merge conflicts later when you raise a pull request. So you decide that you will pull the changes from the remote repository once every two days.

這是一個很好的做法 ，讓您的本地倉庫代碼上最新與遠程存儲庫中的代碼。這樣可以避免以后引發拉取請求時發生很多合并沖突。因此，您決定每兩天從遠程存儲庫中提取一次更改。

Every time you pull the code from the remote repository to the local repository a new merge commit is created in your local repository. This means that your local commit history is going to have a lot of merge commits which can make things look confusing to the reviewer.

每次將代碼從遠程存儲庫拉到本地存儲庫時，都會在本地存儲庫中創建一個新的合并提交。這意味著您的本地提交歷史記錄將包含很多合并提交，這會使審閱者感到困惑。

您如何使提交歷史看起來更整潔？ (How do you make the commit history look neater?)

This is where rebase comes to the rescue.

這是底墊就派上用場了。

什么是變基？ (What is rebasing?)

Let me explain this through an example.

讓我通過一個例子對此進行解釋。

The Release branch has three commits: Rcommit1, Rcommit2, and Rcommit3.
Release分支具有三個提交：Rcommit1，Rcommit2和Rcommit3。
You created your Feature branch from the Release branch when it had only one commit, which is Rcommit1.
在只有一個提交(即Rcommit1)的情況下，您從Release分支創建了Feature分支。
You have added two commits to the Feature branch. They are Fcommit1 and Fcommit2.
您已向Feature分支添加了兩個提交。它們是Fcommit1和Fcommit2。
Your goal is to get the commits from the Release branch into your Feature branch.
您的目標是使發布從Release分支到Feature分支。
You are going to use rebase to do this.
您將使用rebase來執行此操作。
Let the name of the Release branch be release and the name of the Feature branch be feature.
假設Release分支的名稱為release ，而Feature分支的名稱為feature 。
Rebasing can be done using the following commands:
可以使用以下命令來完成基礎調整：

git checkout feature
git rebase release

變基 (Rebasing)

While rebasing, your goal is to ensure the Feature branch gets the latest code from the Release branch.

在重新定基時，您的目標是確保Feature分支從Release分支獲取最新代碼。

Rebasing tries to add each commit, one by one, and checks for conflicts. Does that sound confusing?

變基嘗試逐個添加每個提交，并檢查是否存在沖突。這聽起來令人困惑嗎？

Let me explain with the help of a diagram.

讓我借助圖表進行說明。

This shows what rebasing actually does internally:

這顯示了變基在內部實際執行的操作：

第1步 (Step 1)

The moment you run the command, the Feature branch is pointed to the head of Release branch.
運行命令后，Feature分支便指向Release分支的頭部。
Now the Feature branch has three commits: Rcommit1, Rcommit2, and Rcommit3.
現在，Feature分支具有三個提交：Rcommit1，Rcommit2和Rcommit3。
You may be wondering what happened to Fcommit1 and Fcommit2.
您可能想知道Fcommit1和Fcommit2發生了什么。
The commits are still there and will be used in the steps below.
提交仍然存在，將在以下步驟中使用。

第2步 (Step 2)

Now Git tries to add Fcommit1 to the Feature branch.
現在，Git嘗試將Fcommit1添加到Feature分支。
If there is no conflict Fcommit1 is added after Rcommit3
如果沒有沖突，則在Rcommit3之后添加Fcommit1
If there is a conflict, Git will notify you, and you will have to resolve the conflict manually. After the conflict is resolved use the following commands to continue rebasing
如果存在沖突，Git將通知您，您將必須手動解決沖突。解決沖突后，使用以下命令繼續進行基礎調整

git add fixedfile
git rebase --continue

第三步 (Step 3)

Once Fcommit1 is added, Git will try to add Fcommit2.
添加Fcommit1后，Git將嘗試添加Fcommit2。
Again, if there is no conflict Fcommit2 is added after Fcommit1 and the rebase is successful.
同樣，如果不存在沖突，則在Fcommit1之后添加Fcommit2，并且成功進行重新設置基準。
If there is a conflict, Git will notify you, and you will have to resolve it manually. Use the same commands mentioned in Step 2 after resolving conflicts
如果有沖突，Git將通知您，您必須手動解決它。解決沖突后，請使用步驟2中提到的相同命令
After the entire rebase is done, you will notice that the Feature branch has Rcommit1, Rcommit2, Rcommit3 , Fcommit1, and Fcommit2.
完成整個基準后，您將注意到Feature分支具有Rcommit1，Rcommit2，Rcommit3，Fcommit1和Fcommit2。

注意事項 (Points to note)

Both Rebase and Merge are useful in Git. One is not better than the other.
Rebase和Merge在Git中都非常有用。一個并不比另一個更好。
In the case of a merge you will have a merge commit. In the case of a rebase there is no extra commit like a merge commit.
在合并的情況下，您將有一個合并提交。在進行rebase的情況下，沒有像合并提交這樣的額外提交。
One best practise is to use the commands at different points. Use rebase when you are updating your local code repository with the latest code from the remote repository. Use merge when you are dealing with pull requests to merge the Feature branch back with the Release or Master branch.
一種最佳實踐是在不同位置使用命令。使用遠程存儲庫中的最新代碼更新本地代碼存儲庫時，請使用rebase。處理合并請求時，請使用合并將Feature分支與Release或Master分支合并。
Using Rebase alters the commit history ( it makes it neater) . But that being said, altering the commit history has it’s risks. So ensure you never use rebase on a code that is there in the remote repository. Always use rebase only to alter the commit history of your local repo code.
使用Rebase會更改提交歷史記錄(使其更整潔)。話雖這么說，改變提交歷史還是有風險的。因此，請確保永遠不要在遠程存儲庫中的代碼上使用rebase。始終僅使用rebase來更改本地存儲庫代碼的提交歷史記錄。
If rebase is done to a remote repository it can create a lot of confusion since other developers will not recognise the new history.
如果對遠程存儲庫進行了基礎更改，則可能會造成很多混亂，因為其他開發人員將無法識別新的歷史記錄。
Also if rebase is done on the remote repository, it can create issues when other developers try to pull the latest code from remote repository. So I repeat again, always use rebase only for the local repository ?
同樣，如果在遠程存儲庫上完成了重新設置基準，則當其他開發人員嘗試從遠程存儲庫中獲取最新代碼時，它也會造成問題。所以我再說一遍，總是只對本地存儲庫使用rebase嗎？