git stash
暂时保存 非提交。也不是git add.

• git stash 会保存 工作目录的当前状态。
• 更新HEAD到最近提交。
• 工作目录变为“干净状态”（也就是同步于最近提交）
• 因此我们可以进行分支切换（干净的变换工作目录）

（否则就必须要提交未完成的“脏内容”，额外增加一个无意义的提交） 比如你正在开发你的代码，代码尚处于错误或者未完成状态。这时同事想让你看一下他的代码。

git stash list 查看 stash 列表

stash apply 恢复暂存的修改

另外注意：stash apply 默认恢复工作目录之前的修改。但是不会应用 “暂存” 也就是之前保存时那些暂存状态的文件，将会变为修改未暂存。 如果想回复暂存区 需要加上 index 参数，如下：
git stash apply –index

git stash drop 用来删除一个存储。

git stash pop 最常用 应用 stash 并且立即 删除他。

stash 条件 && 冲突

注意：恢复暂存的条件应该是：当前分支为，暂存匹配的分支 切 当前分支为干净状态。。但这并不是必要条件。 如果在 非 匹配分支应用暂存。依然可以，但类似合并文件，可能造成文件的冲突。

不是储存，而是移除某些不需要的文件。比如：

1. 从其他地方拷贝过来的文件，（未跟踪的文件）
2. 移除程序运行所产生的临时文件。否则 git add . 会暂存 随后可能加入版本库。
3. 为了进行一次重新的构建。比如react ，或者c语言重新编译。

git clean          清理未跟踪的文件
git clean -d     清理未跟踪的文件包含目录
git clean -f      强制清理
git clean -n      -n 尝试清理  
git clean -x     未跟踪，且.gitignore 中有忽略的 比如 react 执行 npm install 的时候，要删除 node_moudules

代码整合：merge 和 rebase 一个是合并，一个叫“变基”
通过图片来看什么是变基：

两个分支合并的提交历史。 通过变基。变成线性的提交历史。 （上图例子）

变基的原理：临时保存一个分支的提交差异。 然后调整当前分支，最后再逐个应用差异。 参考： https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

变基的应用场景： 像别人维护的项目贡献代码时

1. 自己首先在自己本地进行各种分支操作开发。
2. 开发完毕，变基到origin/master 然后提交。

否则你的 ease 分支将会是很多分支合并的结果。包含了很多枝节。通过变基，则你只会推送上去一个线性的记录。管理者也方便进行查看应用你的修改。

（限于篇幅，还是考虑省掉了这个例子） git rebase –onto master server client 选中 在 client 分支上的修改，并且不在 server 做处的修改（c3） 基于master 变基。 注意这里的关键是 选中的修改 是 server 和 client 的差异。 参考：https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

案例 ：两个分支都修改了同一行代码。 然后进行变基操作。

....
冲突（内容）：合并冲突于 f1.py
error: 无法合并变更。
打补丁失败于 0001 f1 444
失败的补丁文件副本位于：.git/rebase-apply/patch

当您解决了此问题后，执行 "git rebase --continue"。 注意之前先 git add .
如果您想跳过此补丁，则执行 "git rebase --skip"。
要恢复原分支并停止变基，执行 "git rebase --abort"。

变基应用领域，通常是为了给比人贡献代码的时候，整理代码用的。

原则：

变基的仓库只此一份,如果这个仓库有其他副本。比如有和其他人分享代码。那么不要进行变基操作。总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。(多人协作时将会造成混乱) 除非所有人都：git pull –rebase 如果已经有问题，这是缓解之道。但不能彻底解决问题。（不建议！）

为了给某一个提交版本打上标签 以示重要，明确记录位置。

列出标签

git tag
git tag -l "v1.5*" # 列出特定模式的标签

创建标签：

附注标签： 包含创建者的相关信息，日期，电子邮件，备注信息等。是个完整的对象。 永久性的标签，建议使用附注标签

git tag -a v1.4 -m 'my version 1.4'

轻量标签： 只是一个 名称引用一个提交。

git tag v1.4.0909

后期打标签：

git log --pretty=oneline 查看历史 以及 hash
$ git tag -a v1.2 9fceb02 补打标签

共享标签:

git push origin v1.5 推送特定标签
git push origin --tags 推送所有标签

检出标签:

标签不像分支，不能移动。因此：

git checkout -b version2 v2.0.0 检出标签 到建新分支上