现在大部分开发工具都可以直接进行菜鸟下面说的大部分操作，具体见：

接上一篇的观点是。

1. git 中容易遗忘的点 💥💥💥

bug分支

软件开发中，bug就像家常便饭一样。按理说，有了bug就需要修复，在Git中，由于分支是如此的强大。所以每个bug都可以通过一个新的临时分支来修复，修复后合并分支，接下来将临时分支删除。

当你接到一个修复bug的任务时很自然地，你想创建一个分支issue1来修复它，但是等等。当前正在dev上进行的工作还没有提交：

$ git status
On branch dev
Changes not staged for commit:
modified: readme.txt

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。不过，必须在两个小时内修复该bug怎么办？

保存工作现场 stash

幸好Git提供了stash功能！让你把当前工作现场“储藏”起来：

$ git stash
Saved working directory and index state WIP on dev: c116d82 remove text

• 必须记住哪个分支有未完成的工作需要储藏！老实说，否则找不到...
• 储藏后记得及时恢复！否则过几天可能自己都忘记...
• 多次储藏要小心混淆顺序！是团队协作时...

恢复工作现场

"我记得我储藏过...但哪去了？"

• 问题1：不知道stash列表怎么查看 → 输入$ git stash list
• 问题2：恢复后发现不对劲 → 因为用了apply而非pop导致stash内容残留!
• 问题3：多次储藏混乱 → 找不到需要恢复的那个版本!

$ git stash list # 查看所有储藏列表
stash@{0}: WIP on dev: c116d82 remove text
# 恢复方法对比:
$ git stash pop # 推荐!自动删除原stash内容
$ git stash apply # 不推荐!需手动删除
$ git stash apply stash@{0} # 指定恢复某个版本

cherry-pick😱😱😱

在master修完bug后,要同步到dev?大多数人会:

# 错误操作!git checkout dev && git merge master # 引入所有master变更!不过，# 正确做法:
git cherry-pick 

注意⚠️⚠️⚠️

cherry-pick不要去操作merge步骤!会让你永远卡住:

说到fatal，You have not concluded your cherry-pick...
Please。
commit your changes before you merge.

关键痛点这方面。

• 不理解cherry-pick底层机制 → 随意使用导致冲突无法处理!
• 合并历史太长 → 查找commit hash变成噩梦!
• 多人协作时同步改动极其麻烦!说起来，

至于案例警告。