作者：joymufeng
起源：https://my.oschina.net/joymuf…
咱们在日常应用 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 养成良好习惯
为了尽量避免抵触产生，倡议养成如下开发习惯：
- 编码前先更新
- 提交前先更新
- 提交前查看是否有编译谬误
- 提交粒度尽可能小，形容尽可能精确
- 批改了公共文件，尽早告诉其余成员更新
- 最初一条，也是最重要的，团队分工要明确
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！