git - 如何避免团队中的 git 冲突？

Question

我们是一些在同一个项目上工作的开发人员，我们在项目中使用 git。如果我们中的两个或更多人碰巧在同一个文件上工作，我们会收到难以处理的 git 冲突，有时当这些冲突发生时，一个开发人员所做的更改会丢失。

他们如何在团队中使用 git？为了避免 git 冲突，正确的流程应该是什么？

提前致谢。

Answer 1

在深入研究工作流程之前，在花费片刻时间或金钱重建沟通流程之前，请问您的团队三个问题:

1. 我们是否强制执行空格约定？
2. 如果我们使用 IDE，它们是否都使用相同的格式和关键字设置？例如，Eclipse 可以自动 finalize parameters .
3. 我们是否生成文本构建工件？例如，我们是缩小 js，从 .sass 或 .scss 文件生成 css 规则，还是即时构建 xml 配置？我们会检查他们吗？

经过多年在集中式工作流程中产生冲突并帮助他人解决这些冲突之后，我提出这三件事是造成我们集体冲突痛苦的主要原因:

在上图中，'!' slice 代表合法的 merge 冲突。 绝大多数 糟糕的 merge 来自懒惰的空白约定或过于激进的 IDE(或偶尔，过度重构的开发人员)。在你做任何其他事情之前，标准化你的 IDE 设置和空格约定。然后让每个人在他们的本地存储库中发出此命令:

# Enable the repository's stock pre-commit hook
mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

每次您发出 git commit 时，预提交 Hook 都会进行一系列检查，包括一个版本的 git diff --check，一个检查是否您提交的更改会引入空格错误。如果提交将被拒绝。如果您确实需要绕过它，您可以发出 git commit --no-verify，但不要这样做:空白错误就像版本控制的未爆炸弹药。它们是等待发生的 merge 冲突。

如果您想清理空白、重构文件以改进其缩进，或者进行大量纯粹的格式更改，请在孤立的提交中进行，并警告团队首先检查他们正在进行的冲突工作。

如果您进行代码审查，请将以下问题作为每个审查者提出的第一个问题:“此更改集是否触及了它不应该触及的任何？它是否清理了任何格式？它是否进行了不必要的重构一个方法？”如果是，则审核失败。或者，如果您不能，请确保这些更改与逻辑更改(即在不同的提交中)充分隔离，以使您的历史有用。

如果检入​​样式表语言、RequireJS 和 js 压缩器生成的目标，它们也会导致冲突。这些技术创建的文件是构建工件。您不会 checkin WAR 存档；不要 checkin SASS 编译的 CSS 文件。或者，如果您觉得必须，请使用 .gitattributes file让 git 将它们视为二进制文件。

如果在完成所有这些操作后，您仍然存在 merge 冲突，请改进工作流程。 Gary Fixler 的回答是绝对正确的:合理的 merge 冲突的产生是因为团队不能或没有很好地就他们的项目范围进行沟通。首先确保其格式规则没有执行不力。