作者：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开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！