Github使用过程中的一些总结（非专业）
1. 部分名词解释
a. Untracked，未被追踪的，指的是新建的但还没加入到暂存区的文件/文件夹(新建的但从来没有被git add 过的)
b. not staged，未加入到暂存区的，指的是已经被追踪过，但是没有加入到暂存区(已经执行过git add/commit的，但是这次修改后还没有git add)
2. 场景，主分支为master，此时在dev分支开发一个新功能，突然需要master紧急修复一个bug。
a. 在dev分支上，使用 git stash 保存当前工作现场。如果有创建的文件或者文件夹，需要先 git add file，如果不这么操作，使用 git stash，之后切换到master分支，也会看到新创建的文件/文件夹，这样导致bug的修改代码也提交不了。 如果 创建了新文件/文件夹，又不想使用git add file，可以使用 git stash -a，这个命令使用后，新创建的文件或者文件夹会暂时不可见。
b. 切换到主分支， git switch master （需要修复哪个分支，就从哪个分支创建临时分支，例子中是修复master分支）
c. 创建临时bug修复分支，git checkout -b issue-1
d. 修复bug，之后add和commit（此时处于临时分支issue-1上）
f. 修复完成后，切换到master分支，并完成合并，最后删除issue-1分支。 切换: git switch master、合并: git merge --no-ff -m "xxx" issue-1、删除: git branch issue-1
g. 因为dev分支是在master上修复bug之前创建的，因此该bug在dev上也存在，如何将修改同步到dev分支上？重复操作1次，再提交？当然也行，但是有更简单的办法：同样的bug，在dev上修复，只需要把修改issue-1这个提交所做的修改复制到dev分支（注意，只复制issue-1这个修改，而不是把整个master merge过来），为了方便操作，git专门提供了一个cherry-pick命令。 切换: git switch dev、同步bug: git cherry-pick commit-id -m 1。这里的commit-id是修复issue-1的那个id，此时需要在master分支上才能看到，至于-m参数，有些教程中不需要，我在操作过程中需要这个参数，-m后的数字表示修改来自于哪个分区，1表示来自于master，至于其他数字没尝试。
h. 继续去完成dev未完成的工作，此时git status，发现工作区是干净的，刚才保存的工作现场去哪了?可使用git stash list 查看；
恢复工作现场：只有单个现场--git stash apply、如果多个现场--git stash apply stash@{xxx}；
删除stash内容： 恢复后，git stash list的内容不会删除，使用git stash drop删除（可使用git stash pop，恢复的同时自动删除stash内容）