简单的示例，用藏匿和拉动演示git校长
假设我有One.txt和twe.txt在远程存储库中，我一直在本地进行一些工作，但没有上演。然后，我发现另一个团队成员对这两个文件进行了一些必要的更改，并将它们推到远程存储库。我需要他的更改，所以我去git stash，git pull，git stash pop。
但是，当我做stash pop时，我会得到2个合并冲突。一个.txt是自动合并的，必须手动完成两个.txt。对于手册，我在一个区域中说“ take tt兼”，另一个区域我保留了我的手册）。然后，我通过git add进行了合并的结果。
git状态现在显示两个文件都准备好。
我会在推动问题吗？换句话说，合并的检查（在藏匿/拉普/pop的上下文中）是否必须匹配同事推动的东西？另外，我应该在发生冲突之后/之后的藏匿处做点事吗？
当我推到远程存储库时，我正在尝试避免合并冲突，因此我担心进入怪异状态。
Say I have one.txt and two.txt in a remote repo and I've been doing some work locally and haven't staged them. Then I find out another team member made some necessary changes to those two files and pushed them to the remote repo. I need his changes, so I go git stash, git pull, git stash pop.
But I get 2 merge conflicts when I did the stash pop. one.txt was auto merged and two.txt had to be done manually. For the manual one, I said "take both" in one area, and the other I kept mine). Then I staged the result of the merge via git add.
git status now shows both files are ready to be committed.
Will I have a problem pushing? In other words, does the checking in of a merge (in the context of the stash/pull/pop) have to match what the co-worker pushed? Also, am I supposed to do something with the stash after/when there's a conflict?
I'm trying to avoid a merge conflict when I push to the remote repo, so I'm worried about getting into a weird state.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
假设您正确解决了合并冲突，并且自您上次拉取以来，其他开发人员没有为同一行代码推送更多代码，那么您在推送更改时应该不会遇到任何问题。
也就是说，在同一分支上与多个开发人员合作时，我不建议使用 git stash 来解决冲突。它非常容易出错，并且您最终可能会失去工作。
问题是，如果您在弹出存储后在冲突解决中犯了任何错误，您将无法回滚到之前的状态。
更安全的策略是使用 git pull --rebase< /a>.
您的示例案例中的步骤是：
git Push作为免责声明：最安全选择是始终将您的工作保留在自己的分支上，并在必要时将其合并到共享分支中。即便如此，这些类型的冲突还是会出现，当它们出现时，
git pull --rebase应该是您的默认策略。Assuming that you resolved the merge conflicts correctly, and another developer hasn't pushed more code for the same lines of code since you last pulled, you shouldn't have any issues pushing your changes.
That said, I don't recommend using
git stashfor conflict resolution when working with multiple developers on the same branch. It's highly error-prone, and you're likely to lose work eventually.The problem is that if you make any mistakes with your conflict resolution after popping the stash, you have no way of rolling back to the previous state.
A much safer strategy is to use git pull --rebase.
The steps in your example case would be:
git pull --rebasegit pushAs a disclaimer: the safest option is to always keep your work on its own branch, and merge it into the shared branch when necessary. Even so, these types of conflicts will come up, and when they do,
git pull --rebaseshould be your default strategy.推送不是合并，因此它不可能导致合并冲突。
事实上，如果推送需要合并（因为远程有您没有的提交），Git 将拒绝允许推送。
所以，推动不可能有什么坏事。如果推是可能的，那么推就完全没问题了。
A push is not a merge, so it cannot possibly result in a merge conflict.
In fact, if pushing would require a merge (because the remote has commits that you don't have), Git will refuse to permit the push.
So, pushing cannot possibly do anything bad. If pushing is possible at all, then pushing is perfectly fine.