中国科学院计算机所研究生实习,在中科院计算所实习的一年(更新中。。)

周六就要开学去怀柔了,开始一年的集中学习的生活。细算起来,从去年七月份来到计算所,已经一年多了,这一年经历了很多、成长了很多,想在这里把这一年实习的经历和感受都记录下来,为已经保研成功的小伙伴做一个参考。

在写的过程中,这一年的一幕幕在脑海中像过电影一般,有很多的遗憾,很多的不舍,去了怀柔,暂时离开这个小家庭,开始新的生活~

工作篇 && 学习篇

很多人比较担心,现在啥都不会,导师直接让去干活,不会干怎么办。感觉这个问题就不是一个问题,每个保研的小伙伴能走到这一步,学习能力都差不到哪里去的,老师选择了你,很大的程度,也是看中了你的学习能力,所以这个根本就不是一个坎。

去年7月中旬,参加完计算所的夏令营定下来在这里读直博后,就没再回家,直接留在所里开始干活了。

夏令营结束后,我就跑去问B老师我要做什么呢,他就把我领到一个师兄的工位旁边(当时师兄不在位置上),说“哎呀,他不在,你以后就跟着他做OpenStack吧,你接触过这些吗?”赶紧说听过一些(其实心里好紧张,我真的只是听过!!!)。

正好赶上所里的高温假,这两周正好可以恶补知识,给自己缓冲一下。师兄当时正在处在找工作的焦灼期,把我叫到会议室,从头到尾给我讲了一遍现在这个项目是干嘛的,做什么,现在有什么,其实当时真的啥都听不懂,只是懵懵的记住了一些组件的名称,师兄给我讲的时候我弱弱的问了一句,有多少人在参与这个项目呢,师兄很淡定的说,在你来之前是他自己,现在我来了就两个人了。

当时一脸懵逼啊,和华为合作的那么大的一个项目,居然现在加上我就两个人在做,CC师兄在找工作,一下子就觉得压力好大好大。但是说白了压力就是动力嘛,高温假的那两周,基本上没有出去玩,每天在啃CC师兄给的资料,自己学着装OpenStack,师兄帮忙调Bug,学习Python(OpenStack整个是用python写的),各种查资料学习各个组件的工作流,因为我的工作就是直接在OpenStack上改,增加功能。

说实在,这两周的我跟开了挂一样,高温假结束之后,就已经能开始开始写功能了,第一次参加组会老大也是蛮惊讶的,居然已经能开始写了(当时心里偷偷高兴了好久),但是路漫漫啊~ 后面的路还很长很长。

所以高温假两周的恶补,也给我带来了非常大的信心,日后再遇到什么坎回头想一下曾经的我只用了两周时间就能在openstack上改了,还有啥过不去的坎呢?真的不要质疑自己的学习能力,相信自己。

在干活之余,也不要忘记多去学习,来到所里后真的发现,一切的一切真的是靠自己,没有集中地学习(现在是实习,等入学后有一年的集中学习时间),完全的靠自己,不停的在补知识,感觉身边的师兄师姐都是那么的厉害,学会去读论文等等。

说起读论文真的是太记忆犹新了,当时B老师面试我时,就给了我一篇论文+10天时间去看,写一篇概括,当时真的是硬着头皮在看,感觉啥都不懂,现查资料,然后翻过去继续理解,感谢B老师不嫌弃我笨,面试的当天还给我讲了我一直没搞懂的尾延迟问题,超耐心~~

来到所里后,每周组里都会有一次论文讨论班,一个人负责过摘要(一般是相关主题的2-3个session,大概7-8篇论文的摘要)、两个人负责讲论文(真的是很仔细的讲论文,大家都会问问题的),组里会有一个讲论文和摘要的了列表,当时很庆幸自己刚来不用讲论文,但总有那么一天(感谢师姐能提前一个月告诉我这个消息~)。当时的我,蠢萌一只,不知道我这个领域应该关注什么会议(说白了我当时连有啥会议都不知道、连session是啥意思都不知道),感谢CC师兄帮我找了一篇论文,ASPLOS 2016的HCloud,第一次在组会上讲论文,第一次花那么大的功夫去读一篇论文(我读的太慢了 T T….),也是因为那篇论文和当时做的工作,让我慢慢走上了这条“不归路“,基本上之后看的文章,了解的工作都是云平台相关的了。

生活篇

说实话,这一年的实习生活过的挺滋润的,组里的师兄师姐们都非常的nice,大家经常一起聚餐、聚众聊天,这一年可是实实在在把我养胖了N斤,更大的原因还是运动少了很多。

更新中。。。

<think>好的,用户遇到了Git合并时本地更改会被覆盖的问题,需要解决方案。根据之前的引用资料,解决方法主要有commit、stash和revert三种。首先,我得确认用户的具体情况,比如他们的本地更改是否已经完成,是否需要保留,或者是否可以丢弃。用户可能不太清楚这三种方法的适用场景,需要详细解释每个选项的步骤和优缺点。比如,commit适用于需要保留更改的情况,stash适合临时保存以便后续恢复,而revert则是直接撤销更改,适用于不需要保留的情况。需要结构清晰,分点说明,每个方法都给出操作步骤和适用场景,帮助用户理解哪种情况最适合他们。还要注意使用中文,避免技术术语过于复杂,让用户容易理解。同时,生成相关问题,可能涉及如何恢复stash的内容,或者如何避免频繁冲突等,扩展用户的知识点。另外,要确保LaTeX格式正确,但在这个问题中可能用不上数学公式,所以主要关注代码块和引用标识。检查引用是否正确,比如引用[^1]和[^2]的来源是否相关,用户提供的引用内容是否准确对应解决方案。 最后,确保回答真实可靠,操作步骤准确无误,避免误导用户。可能还需要提醒用户根据具体情况选择方法,比如如果有未完成的实验性代码,stash可能是更好的选择,而如果是确定要保留的修改,则应该commit。</think>要解决Git合并时本地更改被覆盖的问题,可根据不同场景选择以下三种方法: ### 一、提交本地更改(commit) **适用场景**:当本地更改已测试通过且需要保留到版本历史中。 **操作步骤**: 1. 将改动添加到暂存区: ```bash git add . # 添加所有文件 # 或指定文件 git add file1.txt file2.py ``` 2. 提交更改并添加描述: ```bash git commit -m "完成用户登录模块优化" ``` 3. 执行合并操作: ```bash git merge origin/main ``` **优点**:保留完整的开发记录,便于后续追溯[^1]。 ### 二、暂存更改(stash) **适用场景**:需要临时保存未完成的修改(如调试代码),优先处理合并操作。 **操作步骤**: 1. 保存当前工作状态: ```bash git stash # 可选添加备注 git stash save "用户登录模块调试代码" ``` 2. 查看暂存记录列表: ```bash git stash list ``` 3. 合并远程分支: ```bash git merge origin/main ``` 4. 恢复暂存内容: ```bash git stash pop # 恢复并删除最近一次暂存 # 或指定特定暂存 git stash apply stash@{1} ``` **优点**:保持工作目录整洁,特别适合处理紧急合并任务[^2]。 ### 三、撤销本地更改(revert) **适用场景**:本地修改可丢弃(如实验性代码或错误修改)。 **操作步骤**: 1. 撤销所有未提交的修改: ```bash git checkout -- . # 全部文件 # 或指定文件 git checkout -- file1.txt ``` 2. 执行合并操作: ```bash git merge origin/main ``` **风险提示**:此操作不可逆,需确认文件无需保留。 --- ### 对比决策表 | 方法 | 保留记录 | 可恢复性 | 适用阶段 | |---------|----------|----------|------------------| | commit | ✅ | ✅ | 功能开发完成时 | | stash | ❌ | ✅ | 开发中途临时切换 | | revert | ❌ | ❌ | 放弃无效修改 | ### 扩展应用场景 - 当存在多个暂存时,可用`git stash list`查看记录,通过`git stash apply stash@{n}`精准恢复 - 合并后出现冲突时,可使用`git mergetool`可视化工具解决冲突 - 长期分支开发推荐使用`git rebase`保持提交历史线性
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值