git pul出错_如何使用Git出错-以及如何做。

git pul出错

I am not able to commit to the remote repository, let me do a force push.

我无法提交到远程存储库，请强制执行。

Let me run rebase on the remote repository, to make the commit history neater.

让我在远程存储库上运行rebase，以使提交历史记录更整洁。

Let me amend my previous commit which is in the remote repository.

让我修改远程存储库中的上一次提交。

The points mentioned above are some of the things to avoid doing in Git.

上面提到的几点是在Git中要避免的一些事情。

In my previous posts I covered Git basics and Git amend and rebase. Click on the links to know more about them.

在我以前的文章中，我介绍了Git的基础知识以及Git的修改和调整 。 单击链接以了解更多信息。

Git has amazing features and is very helpful for developers. But mistakes still happen while using Git. Here I will be mentioning some of the things to avoid while using Git and also explain why you should avoid them.

Git具有惊人的功能，对开发人员非常有帮助。 但是使用Git时仍然会发生错误。 在这里，我将提到使用Git时要避免的一些事情，并说明为什么要避免使用它们。

强制推送到远程存储库 (Force push to remote repository)

Let’s say two developers are working on a single branch. Developer 2 is a beginner to Git.

假设有两个开发人员在一个分支上工作。 开发人员2是Git的初学者。

1. Developer 1 has finished their changes and pushed the code to the remote repository.
   开发人员1已完成更改，并将代码推送到远程存储库。
2. Now Developer 2 has finished their changes, but is unable to push the code to the remote repository.
   现在，Developer 2已经完成了更改，但是无法将代码推送到远程存储库。

3. Developer 2 does a quick google search and finds out about force push command and uses it. The command is git push -f

   开发人员2进行了快速的Google搜索，并找到了有关强制推送命令的信息并使用了它。 命令是git push -f

4. Developer 1 checks the remote repository only to find out the code they wrote has completely disappeared.
   开发人员1仅检查远程存储库以发现他们编写的代码已完全消失。

This is because force push overrides the code in the remote repository and, hence, the existing code in remote repository gets lost.

这是因为强制推送会覆盖远程存储库中的代码，因此，远程存储库中的现有代码会丢失。

处理这种情况的理想方法 (Ideal way of handling this scenario)

Developer 2 needs to pull the latest code changes from the remote repository and rebase the code changes into the local repository. Once the rebase is done successfully, Developer 2 can push the code into the Remote repository. Here we are talking about rebase from remote to local repo in the same branch.

开发人员2需要从远程存储库中提取最新的代码更改，并将代码更改重新存储到本地存储库中。 一旦成功完成了基础，开发人员2即可将代码推送到远程存储库中。 在这里，我们谈论的是从同一分支中的远程仓库到本地仓库的重新部署。

Avoid force push unless absolutely necessary. Use it only as a last resort if there is no other way to handle a situation. But remember that force push will override the code in the remote repository.

除非绝对必要，否则避免强行推动 。 如果没有其他方法可以处理这种情况，请仅将其用作最后的选择。 但是请记住，强制推送将覆盖远程存储库中的代码。

In fact if you are using a user interface like source tree, by default force push is disabled. You will have to manually enable it to use it.

实际上，如果您正在使用诸如源代码树之类的用户界面，则默认情况下禁用强制推送。 您必须手动启用它才能使用它。

Also if the right Git workflows are used, each developer will have their own feature branches, and such a scenario would not even occur.

同样，如果使用正确的Git工作流程 ，每个开发人员都将拥有自己的功能分支，甚至不会发生这种情况。

尝试重新建立远程存储库的基础 (Trying to rebase the remote repository)

Let’s say two developers are working on a feature branch.

假设有两个开发人员正在开发功能分支。

1. Developer 1 has done a bunch of commits and pushed it to the remote feature branch.
   开发人员1完成了一堆提交并将其推送到远程功能分支。
2. Developer 2 takes the latest changes from the remote feature branch into the local feature branch.
   开发人员2将最新的更改从远程功能分支转移到本地功能分支。
3. Developer 2 adds a bunch of commits to the local feature branch.
   开发人员2将一堆提交添加到本地功能分支。

4. But Developer 2 also wants to ensure that the latest changes from the release branch are rebased into the feature repository. So Developer 2 rebases the release branch onto the local feature branch. This is the rebase done from remote to local repo of different branches.

   但是开发人员2还希望确保将release分支中的最新更改重新构建到功能部件存储库中。 因此，Developer 2将发布分支重新定位到本地功能分支。 这是从不同分支的远程仓库到本地仓库的基础 。

5. Now Developer 2 tries to push the code to the remote feature branch. Git won’t allow you since the commit history has changed. So Developer 2 would do a force push.
   现在，开发人员2尝试将代码推送到远程功能分支。 由于提交历史记录已更改，因此Git不允许您使用。 因此，开发人员2会强制执行。
6. Now, when Developer 1 wants to pull the latest code from the remote feature branch, it is a tough job since the commit history has changed. So Developer 1 will need to take care of a lot of code conflicts — even redundant code conflicts which were already taken care of by Developer 2.
   现在，当开发人员1要从远程功能分支中提取最新代码时，这是一项艰巨的工作，因为提交历史已更改。 因此，开发人员1将需要处理很多代码冲突-甚至是开发人员2已经解决的冗余代码冲突。

Rebasing the remote repository will alter the commit history and will create issues when other developers try to pull the latest code from the remote repository.

重新建立远程存储库的基础将更改提交历史记录，并且当其他开发人员尝试从远程存储库中获取最新代码时会产生问题。

处理这种情况的理想方法 (Ideal way of handling this scenario)

The ideal way of handling this situation is to always rebase only the local repository. None of the commits in the local repo should have already been pushed to the remote repo.

处理这种情况的理想方法是始终仅对本地存储库进行基础调整。 本地存储库中的所有提交都不应该已经被推送到远程存储库。

If any of the commits have already been pushed to the remote feature branch, then its better to do a merge with the release branch rather than a rebase since merge would not alter the commit history.

如果任何提交都已经被推送到远程功能分支，那么最好与release分支进行合并而不是重新设置，因为合并不会更改提交历史记录。

Also if the right Git workflows are used, only one person would work on one feature branch, and this issue would not even occur.

同样，如果使用正确的Git工作流程，则只有一个人可以在一个功能分支上工作，并且甚至不会发生此问题。

If only one person works on the feature branch and a rebase is done on the remote feature branch, then there is no issue — no other developers are pulling code from the same remote feature branch. But it is best to avoid rebasing a remote repository.

如果只有一个人在功能部件分支上工作，并且在远程功能部件分支上完成了重新建立基础，那么就没有问题-没有其他开发人员从同一远程功能部件分支中提取代码。 但是最好避免重新建立远程存储库。

Rebase is a very powerful feature, but use it carefully.

Rebase是一项非常强大的功能，但请谨慎使用。

修改远程存储库中的提交 (Amending commits in the remote repository)

Let’s say two developers are working on a feature branch.

假设有两个开发人员正在开发功能分支。

1. Developer 1 has done a commit and pushed it to the remote feature branch. Lets call this “commit old.”
   开发人员1完成了提交并将其推送到远程功能分支。 让我们称之为“过时”。
2. Developer 2 pulls the latest code from the remote feature branch into the local feature branch
   开发人员2将最新的代码从远程功能分支提取到本地功能分支
3. Developer 2 is working on the code in the local repository and has not pushed any code to the remote repository yet.
   开发人员2正在处理本地存储库中的代码，并且尚未将任何代码推送到远程存储库。
4. Developer 1 realises there was a mistake in the commit, and amends the commit in the local repo. Let’s call this “commit new.”
   开发人员1意识到提交中存在错误，并在本地存储库中修改了提交。 我们称其为“提交新内容”。
5. Developer 1 tries to push the amended commit to the remote feature branch. But Git would not allow this since there is a change in commit history. So Developer 1 does a force push.
   开发人员1尝试将修订的提交推送到远程功能分支。 但是Git不允许这样做，因为提交历史发生了变化。 因此，开发人员1会强制执行。
6. Now, when Developer 2 wants to pull the latest code from the remote feature branch, Git will notice the difference in commit histories and create a merge commit. When Developer 2 goes over the commit history in the local repo, Developer 2 will notice both “commit new” and “commit old”. This destroys the whole point of amending a commit.
   现在，当开发人员2要从远程功能分支中提取最新代码时，Git将注意到提交历史记录中的差异并创建合并提交。 当开发人员2遍历本地存储库中的提交历史记录时，开发人员2将同时注意到“新提交”和“旧提交”。 这破坏了修改提交的全部要点。
7. Even if Developer 2 does a rebase from remote branch to the local branch, “commit old” will still be present in Developer 2’s local. So it will still be a part of the commit history.
   即使Developer 2进行了从远程分支到本地分支的重新定位，“ commit old”仍将出现在Developer 2的本地中。 因此，它仍将是提交历史记录的一部分。

Amending a commit changes the commit history. So amending a commit in the remote repository will create confusion when other developers try to pull the latest code from the remote repository

修改提交会更改提交历史记录。 因此，当其他开发人员尝试从远程存储库中获取最新代码时，修改远程存储库中的提交会造成混乱。

处理这种情况的理想方法 (Ideal way of handling this scenario)

Best practise is to amend commits only in the local repository. Once the commit is there in the remote repository, it is best not to do any amends.

最佳实践是仅在本地存储库中修改提交。 一旦提交位于远程存储库中，最好不要进行任何修改。

Also, if the right Git workflows are used, only one person would work on one feature branch and this issue would not even occur. In this case, amending a remote repository would not create any issues, since no other developers are pulling code from the same remote feature branch.

另外，如果使用正确的Git工作流程，则只有一个人可以在一个功能分支上工作，甚至不会发生此问题。 在这种情况下，修改远程存储库不会造成任何问题，因为没有其他开发人员从同一远程功能分支中提取代码。

硬重置 (Hard reset)

1. Hard reset is done by using git reset --hard

   硬重置通过使用git reset --hard

2. There are other types of reset as well like--soft and --mixed which are not as dangerous as hard reset

   还有其他类型的重置，例如--soft和--mixed ，不像硬重置那样危险

Let’s say Developer 1 is working on a feature branch and has done five commits in the local repo.

假设开发人员1正在功能分支上，并在本地存储库中完成了5次提交。

1. Also, Developer 1 is currently working on two files which are not yet committed.
   另外，Developer 1当前正在处理两个尚未提交的文件。

2. If Developer 1 runs git reset --hard <commit4hash> the following things will happen.

   如果开发人员1运行git reset --hard <commit4hash> ，将发生以下情况。

3. The latest commit in feature branch will now be commit4 and commit5 is lost.
   现在，功能分支中的最新提交将为commit4，而commit5丢失。
4. The two uncommited files which Developer 1 was working on are also lost
   开发人员1正在处理的两个未提交的文件也将丢失

Commit5 is still there internally in Git but the reference to it is lost. We can get the commit5 back using git reflog. But, that being said, it is still very risky to use hard reset.

Commit5在Git内部仍然存在，但是对它的引用丢失了。 我们可以使用git reflog返回commit5。 但是，话虽如此，使用硬重置仍然非常冒险。

Be very careful when you are using reset commands in Git. You may have to use reset in some scenarios, but evaluate the situation completely before going ahead with hard reset.

在Git中使用reset命令时要非常小心。 在某些情况下，您可能必须使用reset，但是在继续进行硬重置之前，请先全面评估情况。

如何在使用Git时了解不良做法 (How to know the bad practises while using Git)

The list I have mentioned above does not cover everything. It just lists out some of the things that can go wrong while using Git.

我上面提到的列表没有涵盖所有内容。 它只是列出了使用Git时可能出错的一些事情。

So how do you know in general what to avoid while using Git?

那么，您通常如何知道在使用Git时应避免什么？

1. One common thing you would have observed in the above list is that issues occur when multiple people work on the same branch. So using the right Git workflows would ensure only one person works on one feature branch at a time. The release branch would be handled by the tech lead or a senior developer. This workflow can prevent some major issues from happening.
   在上面的列表中，您会观察到的一件事是当多个人在同一分支上工作时会发生问题。 因此，使用正确的Git工作流程将确保一次只有一个人在一个功能分支上工作。 发布分支将由技术负责人或高级开发人员处理。 此工作流程可以防止发生一些重大问题。
2. One other common thing you would observe is the use of force push everywhere. Git, by default, ensures that you cannot do any destructive change in the remote repository. But force push overrides the default behaviour of Git.
   您会观察到的另一件事是在各处使用推力。 默认情况下，Git确保您不能在远程存储库中进行任何破坏性的更改。 但是强制推送会覆盖Git的默认行为。
3. So, whenever you are in a position where you may need to use force push, use it only as a last resort. Also evaluate if there is any other way of achieving what you want without using force push.
   因此，只要您处于需要使用推力的位置，就只能将其用作最后的选择。 还要评估是否有其他方法可以在不使用强制推送的情况下实现所需的功能。
4. Any operation which alters the commit history in the remote repository can be dangerous. Alter the commit history only in your local repository. But even in the local repository be careful while using hard reset.
   更改远程存储库中的提交历史记录的任何操作都可能很危险。 仅在本地存储库中更改提交历史记录。 但是，即使在本地存储库中，使用硬重置时也要小心。
5. Using Git workflows may be overkill in very tiny projects. In these projects multiple developers will work on the same branch. But, before doing any major change in the remote repository, it is better to evaluate once if this will impact the other developers.
   在非常小的项目中，使用Git工作流程可能会过分杀伤。 在这些项目中，多个开发人员将在同一分支上工作。 但是，在对远程存储库进行任何重大更改之前，最好先评估一下是否会影响其他开发人员。

Hopefully this post gave some ideas about what can go wrong in Git and how to avoid it. ?

希望这篇文章对Git中可能出现的问题以及如何避免出现问题提供了一些想法。 ？

关于作者 (About the author)

I love technology and follow the advancements in the field. I also like helping others with my technology knowledge.

我热爱技术，并关注该领域的进步。 我也喜欢用我的技术知识来帮助他人。

Feel free to connect with me on my LinkedIn account https://www.linkedin.com/in/aditya1811/

随时使用我的LinkedIn帐户与我联系https://www.linkedin.com/in/aditya1811/

You can also follow me on twitter https://twitter.com/adityasridhar18

您也可以在Twitter上关注我https://twitter.com/adityasridhar18

My website: https://adityasridhar.com/

我的网站： https : //adityasridhar.com/

我的其他帖子 (Other posts by me)

An introduction to Git

Git简介

How to use Git efficiently

如何有效使用Git

How to become a git expert

如何成为git专家

Originally published at adityasridhar.com

最初发布在adityasridhar.com

翻译自: https://www.freecodecamp.org/news/how-you-can-go-wrong-with-git-and-what-to-do-instead-d80eeeff1d95/

git pul出错