git操作

git命令速查

Git常用命令表

常用操作与撤销

git add xx.txt 把xx.txt添加到缓存区
git reset HEAD xx.txt把xx.txt从缓存区取消

---

git commit xx.txt -m '提交xx.txt' 提交本地仓库
git reset –hard HEAD 撤销之前的commit（HEAD是指向最新的提交，上一次提交是HEAD^{,上上次是HEAD}^,也可以写成HEAD～2 ,依次类推）
HEAD^ 可以替换成指定提交的hash值
如果不小心reset了，git reflog 查看记录，并能过reset --hard找回之前reset的记录
--hard请慎用，请慎用，请慎用

---

git commit --amend修改最后一次修改
比如：

git add a.txt
git commit -m"add a.txt,b.txt"

发现b.txt没有提交，此时再执行

git add b.txt
git commit --amend

此时会跳出编辑提交框，可以修改注释及编辑修改的文件，esc键后WQ!保存退出后，则b.txt会附加到最后一次提交里面。
如果git commit --amend --no-edit则不会出现编辑确认框直接修改。

---

git revert和git reset的区别

git revert是用新的一个commit来回滚之前的commit，HEAD是要继续前进
git reset是直接删除指定的HEAD,其是相当于在不断后退
git reset--hard** 会直接删除掉目标HEAD之后所有的操作，且工作去和暂存区都会修改
git reset --soft ，该命令会将工作去的文件回退到目标版本，但是不会改变暂存区的状态。

---

---

rebase与merge 区别

将dev分支合并到master分支
git merge dev直接合并，提交会按照时间排序
rebase操作dev上的操作会在master的后面

git checkout dev
git rebase master # 将dev上的操作在master分支上做一次衍合处理
# git提示出现了代码冲突，此处为之前埋下的冲突点，处理完毕后
git add readme # 添加冲突处理后的文件
git rebase --continue # 加上--continue参数让rebase继续处理

---

tag标签与branch分支的区别

标签和分支都是引用，它们存储的内容也是类似的，都是指向一个commit对象的sha-1值。
tag的位置是固定的，在给指定提交打好标签以后，它就固定于此位置。分支的位置会不断变动的，随着分支的向前推移或者向后回滚，都在不断变化。

git fetch与git pull的区别

git fetch 相当于是从远程获取最新到本地，不会自动merge。

git fetch orgin master //将远程仓库的master分支下载到本地当前branch中
git log -p master  ..origin/master //比较本地的master分支和origin/master分支的差别
git merge origin/master //进行合并

或

git fetch origin master:tmp //从远程仓库master分支获取最新，在本地建立tmp分支
git diff tmp //將當前分支和tmp進行對比
git merge tmp //合并tmp分支到当前分支

git pull：相当于是从远程获取最新版本并merge到本地
git pull origin mastergit pull 相当于从远程获取最新版本并merge到本地
在实际使用中，git fetch更安全

commit点合并成一个commit点

• rebase实现
  git rebase -i commitId
  参考自这里及这里
  如果这个过程中有操作错误，可以使用 git rebase --abort来撤销修改，回到没有开始操作合并之前的状态。

• git merge --squash 选项

git merge --squash another
git commit -m "message here"

--squash含义和原理如下:
--squash选项的含义是：本地文件内容与不使用该选项的合并结果相同，但是不提交、不移动HEAD，因此需要一条额外的commit命令。其效果相当于将another分支上的多个commit合并成一个，放在当前分支上，原来的commit历史则没有拿过来。
判断是否使用--squash选项最根本的标准是，待合并分支上的历史是否有意义。
如果在开发分支上提交非常随意，甚至写成微博体，那么一定要使用--squash选项。版本历史记录的应该是代码的发展，而不是开发者在编码时的活动。
只有在开发分支上每个commit都有其独自存在的意义，并且能够编译通过的情况下（能够通过测试就更完美了），才应该选择缺省的合并方式来保留commit历史。

忽略本地文件的修改

忽略file.txtgit update-index --assume-unchanged file.txt
恢复file.txt的跟踪git update-index --assume-unchanged file.txt
查看当前被忽略的、已经纳入版本库管理的文件：git ls-files -v | grep -e "^[hsmrck]"