• 近期将进行后台系统升级,如有访问不畅,请稍后再试!
  • 极客文库-知识库上线!
  • 极客文库小编@勤劳的小蚂蚁,为您推荐每日资讯,欢迎关注!
  • 每日更新优质编程文章!
  • 更多功能模块开发中。。。

Git 代码防丢指南

  • 1. 常见工作流程
    • 1.1 更新操作
    • 1.2 创建本次提交
    • 1.3 推送远程分支
  • 2. 常见问题分析
    • 2.1 合并远程分支冲突
    • 2.2 恢复储藏冲突
    • 2.3 文件占用错误
  • 3. 先提交还是先更新?是个问题!
    • 3.1 先提交后更新导致的问题
    • 3.2 推荐先更新后提交
    • 3.3 养成良好习惯

我们在日常使用Git的过程中经常会发生一些意外情况,如果处理不当,则可能会出现代码丢失的假象。本文将针对IDEA&Git日常开发中的一些场景,为你层层拨开迷雾,解析常见的错误及其发生原因,让你从此不再惧怕代码冲突或丢失问题。
为简化问题,本文假设所有团队成员均在同一分支上开发。
文中更新操作是指在IDEA中单击菜单VCSUpdate Project…

1. 常见工作流程

通常当你早上到公司打开电脑,首先执行更新操作(单击IDEA菜单VCSUpdate Project…),然后开始愉快地编码。编码完成后通常要执行以下几个操作:
  • 更新操作
  • 创建本次提交
  • 推送远程分支

1.1 更新操作

为了保证Git拥有一个简洁的提交历史,在提交之前需要先执行更新操作,即在 IDEA 中依次单击菜单VCSUpdate 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功能储藏本地修改。
通常选择MergeUsing Stash即可,单击OK后,IDEA 执行步骤如下:
  • 第 1 步:使用git stash储藏本地修改
  • 第 2 步:执行git fetch && git merge拉取远程分支并合并
  • 第 3 步:执行git stash pop恢复储藏
有些同学可能更习惯先创建本地提交,然后在执行更新操作,这样会导致Git自动生成一个合并提交,导致提交历史不够简洁。

1.2 创建本次提交

更新完成后,在 IDEA 中单击菜单VCSCommit…创建本次提交。

1.3 推送远程分支

然后单击VCSGitPush…推送至远程分支。

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列表的方式为单击菜单VCSGitUnStash Changes…:
选中列表最上面的条目,然后单击Apply Stash,之前的修改就会重新回到工作目录。
我们继续回到冲突问题,手动解决冲突后执行一次提交就可以了。如果在解决冲突过程中发生了误操作,可以右击Default ChangelistRevert…清空当前工作目录内容,重新执行一次Apply Stash,然后重复解决冲突过程。

2.3 文件占用错误

在执行第 2 步git merge时,可能会因为文件被占用导致执行失败。例如项目可能引入了一些 jar 文件,这些 jar 文件在本地已经被 JVM 动态加载了,如果有其它人更新了该 jar 文件并且推送到了远程分支,当你更新时便会遇到上述问题。
对于这种错误的解决方法很简单,首先解除文件的占用状态,例如终止本地 JVM 进程,然后再次点击VCSUpdate
在执行第 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
执行结果为:
请注意,结果中的v4v5提交已经被改写了。

3.2 推荐先更新后提交

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

3.3 养成良好习惯

为了尽量避免冲突发生,建议养成如下开发习惯:
  • 编码前先更新
  • 提交前先更新
  • 提交前检查是否有编译错误
  • 提交粒度尽可能小,描述尽可能准确
  • 修改了公共文件,尽早通知其他成员更新
  • 最后一条,也是最重要的,团队分工要明确

丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:Git 代码防丢指南
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

欢迎 注册账号 登录 发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00