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吗？