⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://my.oschina.net/joymufeng/blog/3005221 「沐风」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

我们在日常使用Git的过程中经常会发生一些意外情况，如果处理不当，则可能会出现代码丢失的假象。本文将针对IDEA&Git日常开发中的一些场景，为你层层拨开迷雾，解析常见的错误及其发生原因，让你从此不再惧怕代码冲突或丢失问题。

为简化问题，本文假设所有团队成员均在同一分支上开发。文中更新操作是指在IDEA中单击菜单VCS-Update Project...。

1. 常见工作流程

通常当你早上到公司打开电脑，首先执行更新操作(单击IDEA菜单VCS-Update Project...)，然后开始愉快地编码。编码完成后通常要执行以下几个操作：

更新操作
创建本次提交
推送远程分支

1.1 更新操作

为了保证Git拥有一个简洁的提交历史，在提交之前需要先执行更新操作，即在IDEA中依次单击菜单VCS-Update Project...，或者按下Ctrl+T，弹出如下窗口：

窗口左侧选择更新类型(Update Type)：

Merge：更新时执行合并操作。等价于执行git fetch && git merge或者git pull --no-rebase。
Rebase：更新时执行rebase操作。等价于执行git fetch && git rebase或者git pull --rebase。
Branch Default：在.git/config文件中指定不同分支的更新类型。

窗口右侧选择在更新前工作目录(Working Directory)的清理方式：

Using Stash：使用git stash储藏本地修改。
Using Shelve：使用IDEA内置的Shelve功能储藏本地修改。

通常选择Merge和Using Stash即可，单击OK后，IDEA执行步骤如下：

第1步：使用git stash储藏本地修改
第2步：执行git fetch && git merge拉取远程分支并合并
第3步：执行git stash pop恢复储藏

有些同学可能更习惯先创建本地提交，然后在执行更新操作，这样会导致Git自动生成一个合并提交，导致提交历史不够简洁。

1.2 创建本次提交

更新完成后，在IDEA中单击菜单VCS-Commit...创建本次提交。

1.3 推送远程分支

然后单击VCS-Git-Push...推送至远程分支。

2. 常见问题分析

在上面的3步执行步骤中，第2步和第3步发生意外的风险最高，最常见的两种意外情况是冲突和文件占用，下面我们分别讨论。

2.1 合并远程分支冲突

如果在执行更新操作之前，你的本地分支已经创建过提交，并且尚未推送至远程分支，则在第2步执行git merge时很可能会发生冲突。

此时关闭上面的冲突窗口，Version Control工具窗口显示内容如下：

窗口右下角原本显示分支名称的位置变成了Merging master，表示本地分支master目前处于正在合并状态。单击左侧红框内Resolve按钮可以再次调出处理冲突窗口。基于IDEA的图形界面手动解决冲突后，IDEA会自动将该文件加入暂存区(加入暂存区即表示冲突解决完成)，最后执行一次提交便可以完成冲突处理。

2.2 恢复储藏冲突

在更新操作的第3步执行git stash pop恢复储藏时，储藏内容可能与刚更新的内容发生冲突。

恢复储藏时发生的冲突跟上面的合并冲突稍微有些区别，首先是右下角的分支名称没有Merging字样，另外会在右下角额外弹出一个小窗提示恢复储藏失败，并且告诉你不用担心，所有的修改都在stash列表中，并没有丢失。查看stash列表的方式为单击菜单VCS-Git-UnStash Changes...:

选中列表最上面的条目，然后单击Apply Stash，之前的修改就会重新回到工作目录。我们继续回到冲突问题，手动解决冲突后执行一次提交就可以了。如果在解决冲突过程中发生了误操作，可以右击Default Changelist-Revert...清空当前工作目录内容，重新执行一次Apply Stash，然后重复解决冲突过程。

2.3 文件占用错误

在执行第2步git merge时，可能会因为文件被占用导致执行失败。例如项目可能引入了一些jar文件，这些jar文件在本地已经被JVM动态加载了，如果有其它人更新了该jar文件并且推送到了远程分支，当你更新时便会遇到上述问题。

对于这种错误的解决方法很简单，首先解除文件的占用状态，例如终止本地JVM进程，然后再次点击VCS-Update。

在执行第3步git stash pop时，也会因为文件被占用导致执行失败。例如你更新了某个jar文件，当恢复储藏时可能因为该jar文件被占用导致恢复失败。

对于这种错误，你需要首先解除文件占用状态，然后手动执行unstash操作。

3. 先提交还是先更新？是个问题！

3.1 先提交后更新导致的问题

3.1.1 发生冲突时难以处理

如果先提交，但是在更新时却发生了冲突，这就意味着你刚刚创建的提交其实是有问题的，通常是团队沟通或是分工出了问题，但是不管这么说，别人已经抢先一步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命令后，

$ git checkout dev
$ git rebase master

执行结果为：

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

3.2 推荐先更新后提交

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

3.3 养成良好习惯

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

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

芋道源码 —— 纯源码解析博客

Git 代码防丢指南