共计 1548 个字符，预计需要花费 4 分钟才能阅读完成。
下面的内容都是我在平时工作中使用频率较高的场景以及对应的代码，分享和记录一下
基本操作
git init // 初始化 git 目录
git clone // 下载代码到本地
git add [file1] [file2] … // 添加指定文件到暂存区
git commit [file1] [file2] … // 提交暂存区的指定文件到仓库区
git pull // 从远程仓库拉取代码到本地
git push // 推送本地仓库到远程
创建分支并提交分支
git branch dev // 创建本地分支
git checkout dev // 切换本地分支
git push origin dev // 提交分支到远端
删除分支
git branch -d dev // 删除本地分支
git push origin –delete dev // 删除远程分支
合并分支
git merge xxx // 合并 xxx 到当前分支
代码写错分支
这个场景用到的挺多的，比如发现了一个 Bug，立马动手去改，却发现写到了 master 或其他分支上，这时候就需要把我们刚写的所有代码搞到对应的 bug 分支上去：
git add . // 把所有改动暂存
git stash // 把暂存的文件提交到 git 的暂存栈
git checkout // 本该提交代码的分支
git stash apply/pop // 将暂存栈中的代码放出来
查看 add 但没有 commit 的内容
git status
查看 commit 但没有 push 的内容
git diff origin/master
合并多次 commit 信息 (git rebase)
使用场景：可能我们写完了一些功能之后，git commit 到了本地仓库，之后发现有些地方需要修改或者补充一下，这时候就有了第二次提交，同时有可能出现第三次、第四次提交，这时候 git log 查看提交日志就会有无用的提交内容，看上去很不美观，这时候我们可以用 git rebase 来将多次提交合并为一个。
git log 查看多次提交的信息
// -i 交互式界面进行 rebase
git rebase -i 8afbeec // 8afbeec 是需要合并的分支的前一个分支的 point
或者 git rebase -i HEAD~3 // 从 HEAD 开始，需要合并的分支数
之后会出现待合并的提交信息和如下提示：
pick：保留该 commit（缩写:p）
reword：保留该 commit，但我需要修改该 commit 的注释（缩写:r）
edit：保留该 commit, 但我要停下来修改该提交 (不仅仅修改注释)（缩写:e）
squash：将该 commit 和前一个 commit 合并（缩写:s）
fixup：将该 commit 和前一个 commit 合并，但我不要保留该提交的注释信息（缩写:f）
exec：执行 shell 命令（缩写:x）
drop：我要丢弃该 commit（缩写:d）
将提交信息修改为
pick d2cf1f9 修改后的信息 111
squash 47971f6 修改后的信息 222
squash fb28c8d 修改后的信息 333
wq 保存修改
合并修改 commit message
wq
这时候我们之前提交的多次 commit 就会合并为一个
修改刚刚提交的 message
使用场景：提交之后，想要修改 commit 的 message
git commit –amend
git 回滚分支
使用场景：。。。
git log 查看提交历史 git reset –hard dbf8d691 // 回到指定的提交点
git 撤销回滚
git reflog 查看提交历史（包含已回滚的提交）git reset –hard dbf8d691 // 回到指定的提交点
查看指定分支是基于那个分支创建的
使用下边的命令，可以知道某个分支是基于那个分支 checkout 的，以防止 merge 的时候，把不需要的内容合并到测试或者正式环境。
git reflog –date=local | grep <branchname>
未完待续 …
