乌龟Git - 拉后导致冲突失败 [英] Tortoise Git - lost commits after a pull resulted in conflicts

问题描述

这个SO问题完美地描述了我们的情况：
当Git或TortoiseGit存在冲突时，提交/推送的正确方法是什么？

在上述问题上没有答案（至少没有被接受）。

这似乎是其中一个解决方案：
https://stackoverflow.com/a/12171221/172396

然而我认为这是一个矫枉过正的问题。我失去了对同事的承诺。 Git是一个分布式的VCS，我认为如果我们建议同事进行本地提交，然后每天推送一次或两次到中央回购站，那就没关系。大多数时候，他们正在单独的模块上工作，并且不会导致冲突。在偶尔发生的冲突中，我认为我们总是可以在本地解决问题，然后再进行本地提交和远程推送。

现在，一位同事在本地犯了一个错误，并试图推动导致冲突。她拉了下来，解决了冲突，然后只是推送她更改的文件。远程repo有另一个提交说合并分支与一些文件，有效地撤消我的提交更早。

这是预期吗？我们应该如何在本地工作，然后偶尔重新同步一次。
如果我已经在本地提交，并且随后的pull会导致冲突，那么我如何确保我正确合并，因此我不会撤销远程repo上的以前提交。

解决方案

我会逐行解决您的问题：
$ b

偶尔冲突，我认为我们总是可以在本地解决，然后使
成为本地提交和远程推送。

是的，这是正确的。

现在，一位同事在当地犯下了一个错误，并试图推动造成
的冲突。她拉了下来，解决了冲突，然后只是推送她更改的文件。
远程仓库有另一个提交声明合并分支，有些文件是
有效地撤销我的提交。这是预期的吗？

是的，这是预期的（即我并不感到惊讶），但这并不意味着
你的同事做的是正确的。 你的同事基本上扔掉了你之前用这个mege commit进行的所有工作。 我会解释一下。当$ g $检测到冲突时它无法弄清楚如何在
期间尝试合并时自动解析，它在中途中止合并， 将未冲突的文件
添加到暂存区域中 ，并在您的工作副本中留下冲突的文件与冲突
标记 取消暂存 。

例如，这是导致冲突的合并，看起来像是从
命令行：

  git status 
 
在分支主机上
您有未合并的路径。 
（修复冲突并运行git commit）
 
要提交的更改：
 
修改：hello.txt 
 
未合并路径：
（使用git add< file> ...来标记分辨率）
 
都已修改：foo.txt 
  

请注意，git已经自动分阶段执行 hello.txt ，因为它
没有有任何冲突。我在1.5年以上没有使用过TortoiseGit，但是如果我的记忆正确地为我服务，
， staged文件在TortoiseGit
中用复选框表示 这意味着您想提交这些文件。

取消选中自动执行的复选框不正确 ，在这个
的情况下。它基本上意味着你不想提交那些你刚刚从其他分支合并的
文件更改（或者你的情况，从上游的
remote /原点）。它本质上是抛弃了对这些
文件所做的工作。

在这种情况下，合并的正确方法是解决冲突的
文件，然后将它们添加到临时区域以提交， 以及所有
已经存在的其他文件更改 ，即使您是而不是
原本负责这些更改。

我们应该如何在本地工作，然后偶尔重新同步一次。

这取决于您和您的团队如何组织您的工作流程。

< blockquote>

如果我已经在本地提交，并且随后的pull会导致冲突，那么
如何确保我正确合并，因此我不会撤消远程
上的先前提交

除非您有充足的理由不像我已经说过的那样，您通常希望
提交所有的文件，即使你不是最初的最终负责向他们转换
。不这样做基本上意味着你实际上并不想保留
这些变化。

This SO question perfectly describes our situation: What is the right way to commit/push when there are conflicts in Git or TortoiseGit?

There is no answer (atleast not one that is accepted) on the above question.

This seems to be one of the solutions: https://stackoverflow.com/a/12171221/172396

However I think that's an overkill. I just lost a commit to my colleagues. Git being a distributed VCS, I thought it would be okay if we advise colleagues to make local commits and then push to a central repo once or twice a day. Most of the time, they are working on separate modules, and won't cause a conflict. On occasional conflicts, I thought we can always resolve locally and then make another local commit and remote push.

Now a colleague committed locally and was trying to push resulting in a conflict. She pulled, resolved conflicts and then ONLY pushed her changed files. The remote repo had another commit saying merge branch with some files that is effectively undoing my commits earlier.

Is this expected? How are we supposed to work locally and then re-sync once in a while. If I have committed locally, and a subsequent pull results in a conflict, how do I ensure I merge correctly so I don't undo previous commits on the remote repo.

解决方案

I'm going to address your questions line by line:

On occasional conflicts, I thought we can always resolve locally and then make another local commit and remote push.

Yes, that's correct.

Now a colleague committed locally and was trying to push resulting in a conflict. She pulled, resolved conflicts and then ONLY pushed her changed files. The remote repo had another commit saying merge branch with some files that is effectively undoing my commits earlier. Is this expected?

Yes, it's expected (i.e. I'm not surprised), though that doesn't mean that what your coworker did was correct. Your coworker basically threw away all the work you did previously with that mege commit. I shall explain.

When git detects conflicts that it can't figure out how to auto-resolve during an attempted merge, it aborts the merge midway, leaving un-conflicted files added to your staging area, and leaving conflicted files with conflict markers un-staged in your working copy.

For example, this is what a merge that results in conflicts looks like from the command line:

git status

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

        modified:   hello.txt

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      foo.txt

Notice that git has automatically staged hello.txt to be committed, because it doesn't have any conflicts. I haven't used TortoiseGit in over 1.5+ years, but if my memory serves me correctly, staged files are represented in TortoiseGit with checked-checkboxes, which means you want to commit those files.

Un-checking those automatically-staged checkboxes is incorrect, in this case. It basically means that you don't want to commit those file changes that you've just merged in from the other branch (or in your case, from the upstream remote/origin). It's essentially throwing away the work that was done on those files.

The correct way to merge, in this case, would be to resolve the conflicted files, and then add them to the staging area to be committed, along with all the other file changes that are already there, even if you were not originally responsible for those changes.

How are we supposed to work locally and then re-sync once in a while.

That's up to how you and your team want to organize your workflow.

If I have committed locally, and a subsequent pull results in a conflict, how do I ensure I merge correctly so I don't undo previous commits on the remote repo.

Unless you have a good reason not to, as I've already said, you usually want to commit all the files, even if you weren't originally reponsible for the changes to them. Not doing so essentially means that you don't actually want to keep those changes.

这篇关于乌龟Git - 拉后导致冲突失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！