关于git力推

我将一个存储库克隆到本地机器上。然后，我使用

git checkout-b dev/abc/test1

创建了一个新分支（从当前的

master

）。我是唯一在这个部门工作的人。我在这个分支上工作了几个小时，然后进行了提交、git push和pull请求。评论员对此请求发表了一些评论

在开始处理这些评论之前，我做了，

git checkout master

，然后，

git pull

更新

master

分支。后来，我想将这些更改（自上次更新以来，

master

中有很多更改）合并到我的分支

dev/abc/test1

因此，我做了

git签出dev/abc/test1

。然后我做了

git重置--hard origin/master

，然后

git merge origin/master

。所以，我从这个分支所做的所有更改都像预期的那样丢失了。我手动复制粘贴了从拉请求所做的更改。现在我开始处理那些审阅者的评论，并修复了所有这些评论，做了一个

git提交

，然后

git推送

，但只是为了看到消息

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

为了避免这种情况，我使用了

gitpush--force

---

这会有负面影响吗？我在这里看到一条评论说，，

“强迫”在大多数情况下（如果不是总是的话）都是错误的答案。我的方法是否会对存储库产生负面影响？（作为旁注，我是分支
dev/abc/test1
的唯一贡献者）
在这种情况下，您正在重写您的
dev/abc/test1
分支的历史记录。只要没有其他人在使用这个分支，它就应该可以了

我建议您使用以下工作流，这意味着您下次无需强制推送

git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push

这将在不重写历史记录的情况下产生相同的结果。
如果您处于GitHub pull请求审查过程中，则可以接受强制推送。这样做会自动更新拉取请求，GitHub会检测到发生了什么变化

审查流程的另一个常见工作流是只添加用于处理反馈的提交。所以你可以直接推它们（不用用力）。最后，通常是由负责合并的人员来压缩这些提交，以便在初始PR上的单个修复不会单独出现

强制推行通常是不受欢迎的，因为它通常意味着你在重写历史（重定基址就是这样做的）。而发布重写的历史记录是一个很好的方法，可以让你的团队成员陷入混乱，所以你应该不惜一切代价避免这种情况。然而，pull请求总是被认为处于流动状态（通常需要重定基址以匹配基础分支上正在进行的开发），因此人们不太可能期望它具有一致的历史记录。
当您执行git push--force

时，您强制重写了远程

dev/abc/test1

分支。这意味着以前的远程分支可能被永久删除。在您的案例中应该没有副作用，因为您是唯一使用分支的人。强制推送通常不好的原因是，通常远程分支一次由多个开发人员共享。重写远程分支的历史记录时，可能会对共享该分支的任何其他人造成严重破坏。当另一个人转到git pull时，他们将看到一个新的历史记录

请注意，也许具有讽刺意味的是，最好的做法是用远程分支替换

dev/abc/test1

的本地副本。因此，您可以通过以下方式对

dev/abc/test1

跟踪分支进行硬重置，而不是硬重置到

master

：

git reset --hard origin/dev/abc/test1

---

这将撤消您在本地执行的任何操作，这些操作可能会提示您重置为

master

，我想在这种情况下没有问题。对于单独在功能分支上工作的人，使用合并工作流没有任何好处。在这种情况下，强制推送功能分支是一种有效的重基工作流。是的，我同意，正如我在回答中所说的“只要没有其他人使用此分支，它就应该可以。”