后端开发教程 - Java、Spring Boot 实战 - msg200.com
使用 git 时可能会遇到哪些错误
强制推送到远程存储库
尝试重新设置远程存储库
修改远程存储库中的提交
硬重置
如何知道使用 git 时有哪些不良做法？
最初发表于adityasridhar.com
我无法提交到远程存储库，让我进行强制推送。
让我在远程存储库上运行 Rebase，以使提交历史更整洁。
让我修改远程存储库中之前的提交。
上面提到的几点是 Git 中应避免做的一些事情。
在我之前的文章中，我介绍了git 基础知识以及git amend 和 rebase。点击链接了解更多信息。
Git 功能强大，对开发者非常有帮助。但使用 Git 时仍然难免会犯错。本文我将介绍一些使用 Git 时应避免的事项，并解释为什么应该避免这些事项。
强制推送到远程存储库
- 假设有两个开发人员在同一个分支上工作。
- 开发人员 1 已完成更改并将代码推送到远程存储库。
- 现在，开发人员 2 已完成修改，但无法将代码推送到远程仓库。此外，开发人员 2 也是 Git 新手。
- 开发人员 2 快速谷歌搜索了一下，找到了强制推送命令并使用它。该命令是
git push -f - 开发人员 1 检查远程存储库，却发现开发人员 1 编写的代码已经完全消失了。
这是因为强制推送会覆盖远程存储库中的代码，因此远程存储库中的现有代码会丢失。
处理上述场景的理想方法是，开发人员 2 需要从远程仓库拉取最新的代码更改，并将代码更改 rebase 到本地仓库。rebase 成功完成后，开发人员 2 就可以将代码推送到远程仓库。这里我们讨论的是在同一分支中从远程仓库 rebase 到本地仓库。
除非绝对必要，否则请避免使用强制推送。只有在别无选择的情况下，才应将其作为最后的手段。但请记住，强制推送会覆盖远程仓库中的代码。
事实上，如果您使用的是类似源代码树的用户界面，则默认情况下强制推送是禁用的。您必须手动启用它才能使用它。
此外，如果使用正确的git 工作流程，每个开发人员都会拥有自己的功能分支，这种情况甚至不会发生。
尝试重新设置远程存储库
- 假设有两个开发人员正在开发一个功能分支。
- 开发人员 1 已完成大量提交并将其推送到远程功能分支。
- 开发人员 2 将远程功能分支中的最新更改带到本地功能分支。
- 开发人员 2 向本地功能分支添加了一堆提交。
- 但是开发人员 2 也希望确保发布分支的最新更改已 rebase 到功能代码库中。因此，开发人员 2 将发布分支 rebase 到本地功能分支。这就是从远程代码库到本地代码库的不同分支的 rebase。
- 现在，开发人员 2 尝试将代码推送到远程功能分支。由于提交历史记录已更改，Git 不允许你这么做。因此，开发人员 2 会执行强制推送。
- 现在，当开发人员 1 想要从远程功能分支拉取最新代码时，由于提交历史已经改变，这项工作变得非常棘手。因此，开发人员 1 需要处理大量的代码冲突（甚至一些冗余的代码冲突，这些冲突开发人员 2 已经处理好了）。
变基远程仓库会更改提交历史记录，当其他开发者尝试从远程仓库拉取最新代码时，可能会引发问题。
处理这种情况的理想方法是始终只变基本地仓库。本地仓库中的所有提交都不应已推送到远程仓库。
如果任何提交已被推送到远程功能分支，那么最好与发布分支进行合并而不是重新定基，因为合并不会改变提交历史。
另外，如果使用正确的 git 工作流程，只有一个人在同一个功能分支上工作，这个问题就不会发生。
如果只有一个人在功能分支上工作，并且在远程功能分支上进行了 rebase，那么就不会出现问题，因为没有其他开发人员从同一个远程功能分支拉取代码。但最好避免对远程仓库进行 rebase。
Rebase 是一个非常强大的功能，但请谨慎使用。
修改远程存储库中的提交
- 假设有两个开发人员正在开发一个功能分支。
- 开发人员 1 完成了一次提交并将其推送到远程功能分支。我们称之为“旧提交”。
- 开发人员2将远程功能分支中的最新代码拉取到本地功能分支
- 开发人员 2 正在处理本地存储库中的代码，尚未将任何代码推送到远程存储库。
- 开发人员 1 意识到提交中存在错误，并在本地仓库中修改了该提交。我们称之为“新提交”。
- 开发人员 1 尝试将修改后的提交推送到远程功能分支。但由于提交历史记录已更改，git 不允许这样做。因此，开发人员 1 执行了强制推送
- 现在，当开发人员 2 想要从远程功能分支拉取最新代码时，git 会注意到提交历史记录的差异，并创建一个合并提交。现在，当开发人员 2 查看本地仓库中的提交历史记录时，他会同时注意到“提交旧”和“提交新”。这彻底破坏了修改提交的意义。
- 即使开发人员 2 从远程分支 rebase 到本地分支，“旧提交”仍会存在于开发人员 2 的本地分支中。因此，它仍然是提交历史记录的一部分。
修改提交会更改提交历史记录。因此，修改远程存储库中的提交会导致其他开发人员尝试从远程存储库拉取最新代码时出现混乱。
最佳实践是仅在本地仓库中修改提交。一旦提交已存在于远程仓库，最好不要进行任何修改。
此外，如果使用正确的 Git 工作流程，只有一个人在一个功能分支上工作，这个问题就不会发生。在这种情况下，修改远程仓库不会产生任何问题，因为没有其他开发人员从同一个远程功能分支拉取代码。
硬重置
- 硬重置通过使用
git reset --hard - 还有其他类型的重置，例如，
--soft它们--mixed不像硬重置那么危险 - 假设开发人员 1 正在处理功能分支，并且已在本地仓库中完成 5 次提交。
- 另外，开发人员 1 目前正在处理 2 个尚未提交的文件。
- 如果开发人员 1 运行，
git reset --hard <commit4hash>将会发生以下事情。 - 功能分支中的最新提交现在将是提交 4，而提交 5 已丢失。
- 开发人员 1 正在处理的 2 个未提交的文件也丢失了
提交 5 仍然在 git 内部，但对它的引用丢失了。我们可以使用 恢复提交 5。git reflog但话虽如此，使用硬重置仍然非常危险。
在 git 中使用重置命令时务必小心。在某些情况下，你可能不得不使用重置命令，但在进行硬重置之前，请务必全面评估实际情况。
如何知道使用 git 时有哪些不良做法？
我上面提到的列表并没有涵盖所有内容。它只是列出了使用 git 时可能出现的一些问题。
那么，您如何知道在使用 git 时一般要注意什么呢？
- 您可能在上面的列表中观察到一个常见问题：当多个人在同一分支上工作时，就会出现问题。因此，使用正确的 git 工作流程可以确保同一时间只有一个人在一个功能分支上工作。发布分支将由技术主管或高级开发人员负责。这种工作流程可以防止一些重大问题的发生。
- 另一个常见的情况是，Git 会到处使用强制推送。默认情况下，Git 会确保你无法对远程仓库进行任何破坏性的更改。但强制推送会覆盖 Git 的默认行为。
- 所以，当你不得不使用强制推送时，请将其作为最后的手段。同时，请评估是否有其他方法可以在不使用强制推送的情况下实现你的目标。
- 任何修改远程仓库提交历史的操作都可能很危险。请仅在本地仓库中修改提交历史。即使在本地仓库中使用硬重置也需谨慎。
- 在非常小的项目中，使用 Git 工作流可能有点过度。因此，在这些项目中，多个开发人员会在同一个分支上工作。但在对远程存储库进行任何重大更改之前，最好先评估一下这是否会影响其他开发人员。
以上几点主要针对多人协作的项目。如果你使用 git 作为业余项目的备份，那么应该不会有问题。
强制推送和硬重置等功能是 Git 的功能。它们在某些情况下非常有用。但最好在使用前进行评估。