我已经使用SVN一段时间了，现在正在项目中使用Git。在我完成git pull之后解决冲突后，我不确定该做什么。顺便说一句，我正在使用GIT龟。
因此，在大多数情况下，我可以执行提交然后拉动它会自动合并，我可以继续推送。 但是如果发生冲突，它会要求我解决冲突。我使用tortoiseGit的内置工具来做到这一点。然后它要求我提交，并获得项目中每个修改过的文件的大清单。
现在，其中许多是本地更改永远不应该提交..但我读了这个git博客：http://randyfay.com/node/89，更具体：
Tortoise Git的一个用户会进行拉动，发生合并冲突，解决合并冲突，然后仔细查看他提交结果时要提交的文件列表。那里有很多文件，他知道合并冲突只涉及几个文件。对于他的提交，他取消选中他没有参与的所有其他文件更改，提交结果并推送提交。
我如何知道我必须选择和提交哪些文件，现在搞砸了git存储库的状态？
编辑： 这总结得很好，发生在我身上的事情，我们已经修好但我们需要了解如何在将来预防。
当几个人承诺......我把他们的工作拉进我的工作时， 默认情况下会发生自动合并。我必须推动合并 承诺，不要搞砸，或者事情变坏。
我所描述的情况发生在自动拉动时 合并发生了。大多数合并（通常发生）是成功的。 但有一点是矛盾的。冲突得到了解决。但在这种情况下 开发人员没有承诺所有其他事情（那是 成功合并并自动添加到索引中。）。他只 承诺了他已经解决的事情（他理解）。他 不知道他对所有其他合并的东西负责 已经成功合并并添加到他的索引中。那就是 这场灾难的故事。
答案 0 :(得分：1)
EDIT2：我想我已经赶上了。听起来像人们push他们的更改没有在本地首先进行回归测试，或者回归测试并且只是暂存最初有冲突的文件。那很不好。 git commit -a？
这听起来似乎没有足够的分支机构，而且当前的工作流程让每个人都对同一个仓库进行了非常不同的，非规范化的工作。如果您因错误合并而浪费时间，请配置项目，以便开发人员在必要时不进行交互。从您问题中链接的文章：
第二种选择由Github推广或承担，并被Linux Core项目广泛使用（Git来自）。在这种情况下，您不要让多个维护者推送到权威存储库上的重要分支。
所以也许我错过了什么。
This article on branching workflows可能是一本很好的读物。
编辑：啊，通过编辑，也许您正在争论基于fetch的工作流，而不是first commenter on your linked article ran into。
What is the difference between 'git pull' and 'git fetch'?
如果你说有时一个知情度很差的合并可能会无意中错误合并好的代码，那你就是对的。合并有时是一种很好的艺术，并且通常需要直接与其他开发人员进行交换以配对合并更改。 （我喜欢先查看git blame。）
答案 1 :(得分：0)
我想首先，你应该只提交你编辑过的文件，你应该知道它们是什么。
你可以看出哪些文件在上一次提交中已被修改，即使我不知道TortoiseGit可能有历史记录功能。
对于将来，我建议您在存储库的本地副本的基础上创建一个.gitignore文件，并列出您知道永远不会提交的所有文件（例如.project，.settings和类似的东西，包括.gitignore）。实际上，Git会扫描您的文件系统以了解哪个文件已更改，有时它无用。
如果您需要更多信息：http://www.kernel.org/pub/software/scm/git/docs/gitignore.html