Git 与 SVN区别：
a、存储方式不一样
Git按照元数据的方式将文件的一个版本存入了一个类似与K/V数据库，而SVN是按照文件的方式进行一个存储。
b、使用方式不一样
从本地把文件推送到远程服务，SVN只需要commit而Git需要add、commit、push三个步骤。
使用SVN开发者只要把文件修改了，只要commit其他开发人员就可以直接checkout下来。c、管理模式不一样
Git是一个分布式的管理系统，而SVN是远程集中式的管理系统。
git log
- git log --online --number 每个log只显示一行，显示number条
- git log --online --graph 图形化表示合并历史
- git log branchname 特定分支
- git log --grep=keywords
- git log --author=xxx
git reflog
git reflog 可以查看所有分支的所有操作记录（包括（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录
reflog 是git 用来记录引用变化的一种机制（如：分支变化或HEAD引用变化）
HEAD变化记录路径是.git/logs/HEAD，分支的reflog记录路径是.git/logs/refs
HEAD@{0} HEAD当前值
Staging area: 暂存区
git add 可以放入新添加的文件或改动，commit时提交的改动是上一次加入到暂存区中的改动
git diff
- git diff --cached 暂存和上一次提交时的快照间的差异
- git diff HEAD 比较working directory和上一次提交之间所有的变动
HEAD是指当前分支最末最新的一次提交
git commit
- git commit -m “the commit message”
- git commit --amend 增补提交
git reset：回滚某次提交
git reset --soft id
HEAD改变（提交记录改变），暂存区内容不变，在git reset mixed之后，实际上又做了一次git add，取消了commit的内容
（HEAD改变，add（暂存区）没变，commit取消）
git reset --mixed id
HEAD改变（提交记录改变），本地文件没有改变，取消了commit和add的内容
（HEAD改变，add（暂存区）取消，commit取消）
git reset --hard id
HEAD = INDEX = Working copy，重置HEAD指向，文件被更改
（HEAD改变，add（暂存区）跟着改变，commit改变）
soft（影响commit） < mixed （影响 commit + add）< hard（影响 commit + add + local working）
举例：
git reset –soft HEAD~1
- 回退一个版本,不清空暂存区,将已提交的内容恢复到暂存区,不影响原来本地的文件(未提交的也不受响)
git reset (–mixed) HEAD~1
- 回退一个版本,且会将暂存区的内容和本地已提交的内容全部恢复到未暂存的状态,不影响原来本地文件(未提交的也不受影响)
git reset –hard HEAD~1
- 回退一个版本,清空暂存区,将已提交的内容的版本恢复到本地,本地的文件也将被恢复的版本替换
git revert：放弃某次提交
- git revert HEAD 撤销最近一次提交
Revert 撤销一个提交的同时会创建一个新的提交。这是一个安全的方法，因为它不会重写提交历史。
相比 git reset，它不会改变现在的提交历史。因此，git revert 可以用在公共分支上，git reset 应该用在私有分支上。
| 命令 | 作用域 | 常用情景 |
|---|---|---|
| git reset | 提交层面 | 在私有分支上舍弃一些没有提交的更改 |
| git reset | 文件层面 | 将文件从缓存区中移除 |
| git checkout | 提交层面 | 切换分支或查看旧版本 |
| git checkout | 文件层面 | 舍弃工作目录中的更改 |
| git revert | 提交层面 | 在公共分支上回滚更改 |
| git revert | 文件层面 | （然而并没有） |
git 删除
git reset回滚某次提交 revert 只会让 commit 继续往前
git revert放弃某次提交 用于做整段 commits 的还原，如果想回退到某次提交时候
git rebase 重建提交顺序 假如想要抽掉某个 commit 又不想留下记录, rebase -i 就很好用了
git rm
命令用于从工作区和索引中删除文件。
git stash
当你在一个分支上在进行开发时，临时需要切换到另一个分支解决一些比较紧急的事情，问题是你才工作了一般，你不想回不到这个工作点，这时就需要用git stash命令了。
把当前的改动压入一个栈，留给用户一个clean的工作状态，即处于上一次最新提交处
- git stash list 显示这个栈的list
- git stash apply 取出stash中的上一个项目，并应用于当前的工作目录
- git stash drop
- git stash clear
-
git stash（这个） 保存当前的工作进度。会分别对暂存区和工作区的状态进行保存。
-
git stash save “message…” 这条命令实际上是第一条 git stash 命令的完整版。
-
git stash list 显示进度列表。此命令显然暗示了git stash 可以多次保存工作进度，并用在恢复时候进行选择。
-
git stash pop（这个） 如果不使用任何参数，会恢复最新保存的工作进度，并将恢复的工作进度从存储的工作进度列表中清除。
-
git stash apply 除了不删除恢复的进度之外，其余和 git stash pop 命令一样。
-
git stash clear 删除所有存储的进度。
git branch
- git branch -v 可以看见每一个分支的最后一次提交
- git branch
- git branch -d 删除一个分支
git tag
和commit 的commit-sha1有些相似，其实就是给当前的版本做个标记，以便回退到此版本。如果使用commit-sha1,大家都记不住那条冗长的sha1码，所以用tag标签来做记录
发布一个版本时，我们通常先在版本库中打一个标签（tag)
- git tag -a 标签内容 -m 标签标号 建立标签
- git push origin -tags 提交标签到远程仓库
- git tag -d version 删除标签
- git push origin :refs/tags/version 删除远程标签
- git tag 或 git tag -l 查看标签
git fetch 取下来不合并
git pull = fetch + merge
自己的分支为了同步develop或master新的提交信息到自己本地分支，要用到 merge & rebase
git merge：自动创建一个新的commit，如果合并遇到冲突，仅需要修改后重新commit
优点：记录真实的commit情况，包括每个分支的详情
缺点：每次merge会自动产生一个merge commit，commit比较频繁时，会看到分支很混乱
git rebase：重建提交顺序
rebase：变基（找公共祖先）
优点：得到更简洁的项目历史，去掉了merge commit
缺点：如果合并出现代码问题不容易定位，因为重写了history
作用：（1）合并多个commits为一个commit （2）分支合并
会将本地本地所有的提交临时保存为补丁（patch）,放在“.git/rebase”目录中，将当前分支更新到最新的分支顶端，然后把保存的补丁应用到分支上（rebase 将所有master的commit移动到你的feature 的顶端）
- git rebase --continue 继续打余下补丁
- git rebase --abort 终止rebase，分支切回到rebase之前的状态
https://blog.csdn.net/victorzzzz/article/details/104192325
如果你想要一个干净的，没有merge commit的线性历史树，那么你应该选择git rebase
如果你想保留完整的历史记录，并且想要避免重写commit history的风险，你应该选择使用git merge
参考：git rebase 和 git merge 的区别 - 简书
特殊符号：
- ^ 父提交（^n 第n个父提交）
- ~<n> 连续<n>个^
1202
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
