git branch
- 不带参数：列出所有本地分支，并且在当前分支的前面用"*"标记
git branch - 列出所有远端分支
git branch -r - 列出所有分支(本地和远端)
git branch -a - 创建新分支
git branch myNewBranch - 删除分支
git branch -d myBranch - 查看本地分支对应的远程分支
git branch -vv - 给分支重命名
git branch -m oldName newName后git push origin HEAD将新分支推送到远端
git checkout
- 1.操作分支
- 切换分支到master
git checkout master - 创建hotfix分支并切换到hotfix分支
git checkout -b hotfix(相当于git branch hotfix+git checkout hotfix)
- 切换分支到master
- 2.操作文件
- 放弃未暂存区单个文件的修改
git checkout filename - 放弃未暂存区当前目录下的修改
git checkout .
- 放弃未暂存区单个文件的修改
git reset
- 回退一个版本,且会将暂存区的内容和本地已提交的内容全部恢复到未暂存的状态,不影响原来本地文件(未提交的也
不受影响)
git reset (–mixed) HEAD~1 - 回退一个版本,不清空暂存区,将已提交的内容恢复到暂存区,不影响原来本地的文件(未提交的也不受影响)
git reset –soft HEAD~1 - 回退一个版本,清空暂存区,将已提交的内容的版本恢复到本地,本地的文件也将被恢复的版本替换
git reset –hard HEAD~1(git reset --hard(未跟踪的文件删除不掉)和git clean -df用来清除未跟踪的文件和目录，是一对好基友. 结合使用他们能让你的工作目录完全回退到最近一次commit的时候)
参考链接:https://www.cnblogs.com/instona/p/4243009.html
git tag
- 1.列出当前已有的tag：
git tag
v1.0.3
v1.0.4-201703081020
v1.0.5-201704141453
v1.0.6-201704151447
v2.3.1
- 列出要查看的tag匹配，可以
git tag -l v1.0.*
- 列出要查看的tag匹配，可以
v1.0.3
v1.0.4-201703081020
v1.0.5-201704141453
v1.0.6-201704151447
- 打tag:
git tag -a v2.3.2 -m '新上线内容说明'
- 打tag:
- 提交到远端:
git push origin v2.3.2
- 提交到远端:
git add
- git add -A 提交所有变化
- git add -u 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)
-
git add . 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件
git_version_1.0.jpg
git_version_2.0.jpg
参考文章:https://www.jianshu.com/p/65fb3fa62057
git status
查看文件状态
git diff
1） 工作区和暂存区比较
git diff
2）暂存区和HEAD比较
git diff --cached
3）工作区和HEAD比较
git diff HEAD
参考链接：https://www.cnblogs.com/lianghe01/p/5846525.html
git commit
git commit -m "message"git commit -a -m “message” 相当于git add -u + git commit -m "message"- 对上次提交不满意，继续修改生成一个新的commit替换上次的commit，也可以不加-m 参数 ，会弹出个框让编辑上次message，不修改代表直接使用上次的message
git commit -amend -m "message"
`
原文链接:https://blog.csdn.net/qianxuedegushi/article/details/80311358
git rebase
rebase之前需要保证工作区没有changes,否则会报如下错误
error: cannot rebase: Your index contains uncommitted changes.
error: Please commit or stash them.
- 1.rebase和merge区别
下图是各个分支所处的情况
git merge
git checkout mywork
git merge origin
git rebase
git checkout mywork
git rebase origin
rebase用于合并时小结
git rebase会先找到mywork和origin分支的共同祖先，然后将mywork分支共同祖先之后的commit保存为补丁，然后将当前分支代码更新带origin最新代码，然后在应用刚才保存的补丁
- rebase和merge优缺点对比
1.rebase可以保证commit线性，但是会打乱时间的排序，不产生新的commit,如果有冲突需要再解决完冲突后 git add . 然后
git rebase --continue继续或者git rebase --abort恢复或者git rebase --skip跳过，即使冲突也不会产生新commit,解决冲突的变动会在之前提交的commit里发生变化
2.merge会产生一个新的merge commit，commit结构由于不是线性看起来不是很友好，解决冲突，git add .,git commit -m message
原文链接：http://gitbook.liuhui998.com/4_2.html
2.rebase用于调整commit
代表调整最近4次提交,会出现交互界面 esc : wq后即可执行
git rebase -i HEAD~4
- 场景1 将后三次提交合并到第一次提交中,则改成如下(注意)
p f0ff319 第一次提交
s 2a1aa7c 第二次提交
s c9cc729 第三次提交
s 566e84e 第四次提交
修改每个commit id前面的pick值。如果改成squash则代表将此项合并到上个commit里，注意在现实的列表里，第一个commit不能用squash因为他已经是第一个了所以不能合并到上一个
- 场景2 将第三次提交合并到第二次提交上
p f0ff319 第一次提交
p 2a1aa7c 第二次提交
s c9cc729 第三次提交
p 566e84e 第四次提交
- 场景3 修改第二次提交的commit message但是文件改变不变
p f0ff319 第一次提交
r 2a1aa7c 第二次提交
p c9cc729 第三次提交
p 566e84e 第四次提交
- 场景4 修改第二次提交的文件变动，但是message仍然使用之前的message
p f0ff319 第一次提交
e 2a1aa7c 第二次提交
p c9cc729 第三次提交
p 566e84e 第四次提交
- 场景5 删除第二次提交
p f0ff319 第一次提交
d 2a1aa7c 第二次提交
p c9cc729 第三次提交
p 566e84e 第四次提交
git pull
git pull = git fetch + git merge fetch_header
git pull --rebase = git fetch + git rebase fetch_header
git push
git push时如果远端有改动，则会因为本地版本和远端版本不同报reject错误，所以每次push时不管有无变动都最好先pull
所以当远端有变动的时候产生了以下2种场景
- 场景1：提交完代码 ，pull代码如果远端有更新 ，还会产生一个merge commit，或者使用rebase 就不会有新的commit ，然后push
- 场景2：在提交之前，先pull，如果没有改动相同的文件，则pull不会报错，然后commit -> push一个完整的正常流程，如果在pull时远端有和你共同改动的文件，pull就会报错提示你本地的修改会被远端覆盖(因为pull就是fetch+merge)
- 场景2 有相同改动时报错解决方法
解决方法1：此时可以采用场景1的方式先commit在pull，然后push
解决方法2：贮藏(git stash)，然后在pull,git stash apply,git push
git stash
- 查看贮藏列表
git stash list - 应用最近一次贮藏
git stash apply - 应用指定贮藏(具体指定那个可以使用
git stash list查看)
git stash apply stash@{2}
