Git 边边角角
2019-11-11 软件开发工具
命令一览
三棵树
Fast Forward
“快进式合并”（fast-farward merge），会直接将 master 分支指向合并的分支，这种模式下进行分支合并会丢失分支信息，也就不能在分支历史上看出分支信息。
可以在合并时加上 –no-ff 参数来禁用 Fast forward 模式，并且加上 -m 参数让合并时产生一个新的 commit。
$ git merge --no-ff -m "merge with no-ff" dev
Stashing
在一个分支上操作之后，如果还没有将修改提交到分支上，此时进行切换分支，那么另一个分支上也能看到新的修改。这是因为所有分支都共用一个工作区的缘故。
可以使用 git stash 将当前分支的修改储藏起来，此时当前工作区的所有修改都会被存到栈中，也就是说当前工作区是干净的，没有任何未提交的修改。此时就可以安全的切换到其它分支上了。
$ git stash
Saved working directory and index state \ "WIP on master: 049d078 added the index file"
HEAD is now at 049d078 added the index file (To restore them type "git stash apply")
该功能可以用于 bug 分支的实现。如果当前正在 dev 分支上进行开发，但是此时 master 上有个 bug 需要修复，但是 dev 分支上的开发还未完成，不想立即提交。在新建 bug 分支并切换到 bug 分支之前就需要使用 git stash 将 dev 分支的未提交修改储藏起来。
Git 钩子列表
- applypatch-msg
- post-merge
- pre-auto-gc
- prepare-commit-msgcommit-msg
- post-receive
- pre-commit
- push-to-checkoutpost-applypatch
- post-rewrite
- pre-push
- updatepost-checkout
- post-update
- pre-rebasepost-commit
- pre-applypatch
- pre-receive
git merge & git rebase
| git merge master | git rebase master |
|---|---|
| 合并 master 的记录到分支，合并之后的所有 commit 会按提交时间从新到旧排列 | 当前分支的 HEAD 会移动到 master 的结尾，但会变成一个新的 commit |
| 用 git log –graph 查看的话，会看到交叉线 | git log –graph 是一条漂亮的直线 |
| 保持了所有 commit 的连贯性 | commit 历史被修改了，3b36f32 被修改成了 a018520 |
什么时候用 rebase，什么时候用 merge？
- 用
merge来把分支合并到主干 - 如果你的分支要跟别人共享，不建议 用
rebase，因为rebase会创建不一致的提交历史 - 如果只有你个人开发推荐使用
rebase - 如果想保留完整的提交历史，推荐使用
merge，merge保留历史 而rebase重写历史 rebase还可以压缩、简化历史，通过git rebase -i可以在分支合并到主干前，整理自己分支的提交历史，把很多细碎的commit整理成一条详细的commitrebase一次只处理一个冲突，merge则一次处理全部冲突。处理冲突rebase更方便，但如果有很多冲突的话，撤销一个rebase会比merge更复杂，merge只需要撤销一次
