2

我使用 SVN 已经有一段时间了,现在正在一个项目中使用 Git。在完成 git pull 后解决冲突后,我不确定该怎么做。顺便说一句,我正在使用乌龟 GIT。

所以在大多数情况下,我可以先提交,然后拉,它会自动合并,我可以继续推送。但是,如果有冲突,它会要求我解决冲突。我使用内置的 tortoiseGit 工具来做到这一点。然后它要求我提交,我得到项目中每个修改文件的大列表。

现在,其中许多是本地更改,永远不应该提交。但我读了这个 git 博客:http ://randyfay.com/node/89,更具体地说:

Tortoise Git 的一位用户会执行拉​​取操作,遇到合并冲突,解决合并冲突,然后在提交结果时仔细查看要提交的文件列表。那里有很多文件,他知道合并冲突只涉及几个文件。对于他的提交,他取消了他未参与的所有其他文件更改的检查,提交了结果并推送了提交。

我怎么知道我必须选择和提交哪些文件现在搞砸了 git 存储库的状态?

编辑:这很好地总结了它,发生在我身上的事情,我们修复了,但我们需要了解如何在未来预防。

当有几个人提交时......我将他们的工作放到我的工作中,默认情况下会自动合并。我必须把那个合并提交推回去,不要把它搞砸,否则事情会变糟。

我所描述的情况发生在发生自动合并的拉动时。大多数合并(通常会发生)是成功的。但是有一点矛盾。冲突得到了解决。但是在这种情况下,开发人员并没有提交所有其他的东西(成功合并并自动添加到索引中。)。他只承诺他已经解决的事情(他理解)。他不知道他对所有其他已成功合并并添加到他的索引的合并内容负责。这就是这场灾难的故事。

4

2 回答 2

1

EDIT2:我想我已经赶上了。听起来人们在push没有先在本地进行回归测试的情况下进行更改,或者进行回归测试并且只暂存最初有冲突的文件。那很不好。 git commit -a?

听起来也没有足够的分支,并且当前的工作流程让每个人都向同一个 repo 提交了非常不同的、非规范化的工作。如果您因错误的合并而浪费时间,请配置项目,以便开发人员在必要时不会进行交互。从您问题中链接的文章中:

第二种选择由 Github 推广或采用,并被 Linux Core 项目(Git 的来源)广泛使用。在这种情况下,您不会让多个维护者推送到权威存储库上的重要分支。

所以也许我错过了一些东西。

这篇关于分支工作流的文章可能是一本不错的读物。

编辑:啊,通过编辑,也许您正在争论基于fetching 的工作流程,因为您链接文章的第一个评论者遇到了.

“git pull”和“git fetch”有什么区别?

如果您说有时信息不充分的合并可能会无意中误合并好的代码,那么您是对的。合并有时是一门艺术,通常需要直接干扰其他开发人员以配对合并更改。(我喜欢先浏览git blame。)

于 2012-08-07T12:41:53.003 回答
0

我想首先,您应该只提交您编辑的文件,您可能应该知道它们是什么。

即使我不知道 TortoiseGit 可能有一个历史功能,您也可以确定哪些文件在上次提交中被修改。

对于将来,我建议您在存储库的本地副本的基础上创建一个 .gitignore 文件,并列出您知道永远不会提交的所有文件(例如 .project、.settings 和类似的东西,包括 . .gitignore)。事实上,Git 会扫描您的文件系统以了解哪个文件被更改,但有时它并没有用处。

如果您需要更多信息:http ://www.kernel.org/pub/software/scm/git/docs/gitignore.html

于 2012-08-07T12:40:25.127 回答