翻译—How to become a Git expert

原文链接：https://medium.freecodecamp.org/how-to-become-a-git-expert-e7c38bf54826

---

我在提交代码的时候发生了错误，我该怎么样解决它呢？

我提交代码的日志记录一片混乱，我该怎么样让他看着整洁一点呢？

如果你曾经有过以上的困惑，这篇文章将为你提供帮助。本篇文章包括了一些列主题，使你变成一名使用Git的专家。

如果你一点Git的基础都没有，可以点击这里在我的博客上了解关于Git的基础知识。知道Git的一些基础知识很非常必要的，会让这篇文章发挥最大价值。

提交的时候发生错误怎么办？

“broken ceramic plate on floor” by chuttersnap on Unsplash

情境一

比如说你提交了一堆文件并且意识到你提交的备注信息并不很清晰，然后你想要改一下提交信息。你可以使用git commit --amend命令：

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

情境二

如果你想要提交6个文件，但是你搞错了，你只提交了5个。你可以觉着你可以在重新提交一次，把第6个文件提交了。

这个方法没毛病！但是，为了保持清晰的提交历史，如果你真的可以以某种方式讲文件添加到之前的提交上面不是更好吗？你可以通过git commit --amend命令：

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

--no-edit的意思是提交信息不用修改。

情境三

无论何时Git提交，提交都会附上作者的姓名和作者的邮箱。通常当你第一次开始使用Git时，你都会设置你的姓名和邮箱。你不用关心每次提交的作者的详细信息。

也就是说，对于特殊的项目你可以使用不同的邮箱账号。你需要使用下面的命令配置邮箱账号到本地项目上：

git config user.email “your email id”

如果说你忘了配置邮箱并且已经完成了第一次提交，Amend可以用来修改你之前提交的作者。使用下面的命令：

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

有一点需要注意

Amend命令只能在你的本地仓库上使用。使用这个命令在远程仓库上的话，会产生大量的冲突。

我的提交历史很杂乱怎么办？

假如你现在只处理一个模块代码。你知道代码大约需要十天才能完成。在这十天内，其他的开发人员也提交了代码到你的远程仓库。

经常保持你的本地仓库和远程仓库代码的同步是一个很好的做法。这样避免了当你最后只拉取一次时候产生的大量的合并冲突。所以你决定每两天从远程仓库中拉取一次。

每次将代码从远程仓库拉取到本地的时候都会创建新的合并提交。这意味着你的本地提交历史记录会进行大量的合并提交，这会使得查阅者感觉疑惑。

Here is how the commit history would look in your local repository.

那怎么样可以使得提交历史看着更清晰呢？

可以使用rebase来拯救。

什么事rebasing？

比如说一下例子。

This diagram shows the commits in the release branch and your feature branch

1.Release分支有3个提交：Rcommit1，Rcommit2，Rcommit3。

2.在Release分支提交(Rcommit1)一次后，你创建了Feature分支。

3.你在Feature分支又增加了2此提交：Fcommit1，Fcommit2。

4.你的目标是从Release分支提交到Feature分支。

5.你打算使用rebase来做。

6.Release分支的名字叫release，Feature分支的名字叫feature。

7.Rebasing可是使用一下的命令来做：

git checkout feature
git rebase release

Rebasing

在rebasing的时候，你的目标是确保Feature分支可以在Release分支上的最后一次提交。

Rebasing会尝试添加每一次提交，一个接一个，然后检查冲突。这听起来很奇怪吗？

让我在图表的帮助下解释。

下面图展示了Rebasing的内部原理：

image.png

Step 1

1.运行命令的那一刻，Feature分支只想Release分支的头部。

2.现在Feature分支有3个提交：Rcommit1，Rcommit2，Rcommit3。

3.你可能想知道Fcommit1和Fommit2发生了什么。

4.提交仍然存在，并将在下一部中使用。

Step 2

1.现在Git尝试添加Fcommit1到Feature分支。

2.如果没有冲突Fcommit1会成功添加到Rcommit3后面。

3.如果有冲突，Git会通知你，你必须手动解决冲突。在冲突解决后，使用下面的命令继续Rebasing：

git add fixedfile
git rebase --continue

Step 3

1.一旦Fommit1被添加后，Git会试图添加Fcommit2。

2.再一次检查，如果没有冲突Fcommit2会被添加到Fcommit1之后并rebase成功。

3.如果有冲突，步骤如Step 2。

4.在所有的rebase都做完后，你会注意到Feature分支现在有了Rcommit1，Rcommit2，Rcommit3，Fcommit1和Fcommit2。

需要注意的地方

1.Rebase和Merge对于Git都很好用，这两个分不清哪个更好用。

2.在merge的情况下，你将进行merge提交。在rebase的情况下将没有想merge提交那样额外的提交。

3.一个最佳实践是在不同的点使用命令。当你从远程仓库上更新最新的代码到本地时候使用rebase命令。在处理拉取请求将Feature分支和Release或Master分支合并的时候使用merge。

4.使用Rebase使得提交历史更加清晰。但话虽如此，改变提交历史是有风险的 。所以要确保你绝不能在远程仓库上rebase代码。仅仅在想要修改你本地的提交历史的时候使用Rebase。

5.如果你在远程仓库上使用了Rebase命令，会变得很混乱。因为别的开发人员无法识别Rebase后新的历史记录。

6.如果rebase使用到了远程仓库上，它会在其他开发人员试图拉取最新代码块的时候造成很多问题。所以我再次强调，请只在本地仓库上使用rebase命令。😃