Git 代码防丢指南

如果先提交，但是在更新时却发生了冲突，这就意味着你刚刚创建的提交其实是有问题的，通常是团队沟通或是分工出了问题，但是不管这么说，别人已经抢先一步push了，你的提交便会被拒之门外。即便是手动解决了冲突，这个提交保留在历史中也会成为隐患，如果有其他人reset回这个提交继续工作，则在合并其它分支内容时发生冲突的概率会大大增加，所以最好处理方式是先撤销这个提交(reset --soft HEAD~)，然后更新并解决冲突，最后创建一个新的提交。

3.1.2 错误的处理冲突方式

在发生冲突后，有些同学可能会想到下面的处理方式：

• 清空当前工作空间
• 调整冲突部分的代码
• 然后再次执行更新操作

上面的处理方式很明显是不可行的，因为你调整的代码首选会被IDEA储藏(stash)起来，然后在更新的第2步中仍然会发生冲突，并且发生冲突时，你的修改尚未恢复储藏(unstash)，导致看起来你调整的代码不见了，让人摸不着头脑。

3.1.3 Rebase会改写提交历史

如果在IDEA的更新窗口选择更新类型为Rebase，则等价于手动执行git fetch && git rebase或者git pull --rebase命令。这样的好处是不会生成一个自动合并提交，保持简洁的提交历史。但是需要注意的是，Rebase之后，你的本地提交会被改写，虽然提交信息一样，但是commit hash已经改变了，如下图所示：

在执行完如下的Rebase命令后，

执行结果为：

请注意，结果中的v4和v5提交已经被改写了。

3.2 推荐先更新后提交

如果你事先知道会发生冲突，相信你一定不会选择先提交代码，但是冲突是不可避免的，这就要求我们平时养成良好的开发习惯。与其解决提交后的冲突，不如尽早地解决冲突然后提交，这样不仅可以减少一个无意义的自动合并提交，而且可以在冲突发生时简化处理过程。

3.3 养成良好习惯

为了尽量避免冲突发生，建议养成如下开发习惯：

• 编码前先更新
• 提交前先更新
• 提交前检查是否有编译错误
• 提交粒度尽可能小，描述尽可能准确
• 修改了公共文件，尽早通知其他成员更新
• 最后一条，也是最重要的，团队分工要明确

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!