git随便写写

/ 默认分类 / 没有评论 / 86浏览

本文是连载文,主要记录git常用命令和使用过程中的问题和方式:上次更新20181020

git reset使用

reset指令是git常用的命令之一,主要用于回滚和回溯文件使用。具体reset的产生的作用可以看下官方文档:reset重置

git reset  --soft <commit> 

仅仅是是把HEAD的指针指向commit处,暂存区和工作目录不会改动。此时commit以后的数据并没有丢失,可以通过 git reflog来看。如果想撤回,再次执行此命令,commit的是你想回到的值

git reset --mixed <commit>  //等同于git reset <commit>

这个命令同样回先执行--soft的操作,但同时会把暂存区的内容更新到此时HEAD的快照,差不多相当于暂存区的内容丢了。但是工作区的内容不会改变

git reset --hard HEAD  

这个命令会先执行到--mixed的结果,同时会把工作区的内容删除掉。更新到当前HEAD的内容。小心使用

git reset --merge #如果Git版本 >= 1.6.1
git merge --abort #如果Git版本 >= 1.7.4

如果merge冲突或者

git 设置推送流对应关系

git branch --set-upstream-to/-u  origin/branch [local_branch]

设置推送的流,local_branch如果不写,默认是当前分支。

--set-upstream 已经废弃,使用--track和--set-upstream-to/-u

git 推送

origin 是远程仓库的一个名字

git push origin master //推送master分支到远程origin master分支,如果远程不存在master则会创建.
git push origin :master //删除远程master分支.
git push //推送当前分支到远程的对应的分支,这里省略了远程仓库的名字表示只有一个远程仓库。省略分支名字表示,当前分支远程分支之间存在追踪关系.

git push 默认只推送当前分支,simple模式,还有个matching模式推送所有的分支。通过git config --global push.default matching/simple进行设置

git diff 比较区别

比较区别指令常用的很少

git diff <file> //比较工作区和暂存区的区别
git diff <commit> <file> //比较当前工作目录和仓库<commit>的区别.
git diff --cached <commit> <file> //暂存区和<commit>的区别

git alias别名

git alias的配置,主要是简化命令复杂的参数,下面是我使用的alias,添加相关内容到$HOME 目录的 .gitconfig 文件中即可

[alias]
  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
  type = cat-file -t
  dump = cat-file -p

git stash 暂时储藏

git stash 用于储藏当前的工作区和暂存区的变更到一个堆栈区,以后可以随时使用.一般用在工作区有一小点更改,同时又需要合并一下其他分支的代码。

git stash //储藏当前变更
git stash list//列出储藏的队列
git stash apply  [stash@{0|1|2..}] //应用储藏的变更到当前的工作区

merge和rebase的使用

网上有太多说明merge和rebase的用法,我就不详细介绍,只说明一下我们常用的情形以及产生的结果。

rebase的使用

rebase最核心的用途就是变基操作,而且你要记住的是rebase一定只在自己未push的分支操作,否则会导致日志的混乱的问题。 例如:

  1. 我们以master分支作为base创建一个分支feature1,并提交了两个commit(commit 1和commit 2),在feature1分支上图谱为: 屏幕快照 2018-10-20 下午1.39.25.png

  2. 切回到master分支,并提交一个commit。图谱为 屏幕快照 2018-10-20 下午1.46.16.png

  3. 切回到feature1分枝上,如果进行merge master操作图谱为: 屏幕快照 2018-10-20 下午1.49.06.png

看到,master分支的内容合并到了fearture1分枝上,并且创建了一个合并的commit以及保留了feature1分支的路线。

如果进行rebase master操作,图谱为: 屏幕快照 2018-10-20 下午1.52.03.png 看到,并没有产生一个merge的commit,同时通过commit的id我们也可以发现,feature1上的commit的id变了,同时commit 1前面一个commit也变成了master的commit1的id,而且这个日志图谱上没有任何分支的路线,如果master合并一下这个feature1的分支,那么master的日志也不会存在任何分支路线,以为这个时候master执行的是fast-merge,除非合并时候的时候加上--no-ff(不执行快速合并)。

merge的使用

merge就是最基本的合并操作,默认的如果可以执行快速合并,那么不会有分支路线和合并的commit,如果不可以快速合并,那么会创建一个合并的commit,同时,保留分支的日志图谱。可以使用--no-ff来禁止快速合并。

快速合并,如果待合并的分支在当前分支的下游,也就是说没有分叉时,会发生快速合并。

rebase -i 合并临时性提交并修改message

很多时候,我们每天有很多的提交,但大多是临时性的,如果这些临时性的提交的日志合并到master分之上,是很不利于git仓库管理的,所以在我们每天push到远程仓库的时候,我们需要整理下那些临时性的提交。 rebase -i [commit你要撤销的最开始的commit]

用下面的例子来展示

  1. 首先查看下当前的日志git hist 显示结果: 屏幕快照 2018-10-19 下午8.06.49.png

  2. 然后执行撤销操作``git rebase -i 338e0c3` 屏幕快照 2018-10-19 下午8.30.39.png

rebase -i可以有很多操作,对我们来合并需求来说,第一个使用reword,后面都使用squash,这样就可以把commit合并成一个,并且修改commit的message,然后保存文件就可以了。

可以看到338e0c3之前的commit的日志已经没有了。清爽了很多

ISSUES问题