工作中超实用git操作，持续更新

工作中几乎每天都会和git打交道，将自己工作中常用的git操作记录下来，一来便于自己查阅与更新，二来如果能帮助到大家，那便最好不过了。

一、超常用操作

001使gitignore文件在项目中生效

项目中有些文件比如target文件夹、.idea目录，是没有必要提交到GIT上的，我们可以在git根目录（也是项目的根目录）下创建一个.gitignore文件。

但是事情似乎没有这么简单，当引入.gitignore文件后，常常发现.gitignore文件似乎没有起作用，这时可以考虑是否是因为git存在了本地缓存，导致没有生效，可以尝试以下命令带来的魔力。

git rm -r --cached . // 删除本地缓存 文件会全部变红
git add . // 添加要提交的文件

 

002清除红色文件-删除untracked文件

红色的git文件是比较烦人的，尤其是当有很多红色的git文件，散落在各个文件夹下。。。尝试下面的命令，快速赶走它吧！！！

# 连 untracked 的目录也一起删掉
git clean -df

 

003提交一个空的commit

git commit  --allow-empty -m "前端通过api的访问与后端交互"

 

004修改（本地）已提交的commit信息

提交完git commit突然发现commit内容写错了，导致不符合公司的commit信息规范或者不符合本次修改的内容，这时使用下面的操作可以快速编辑修改commit信息。

//修改最近一次的提交信息
git commit --amend

 

005 git stash

这是一个超实用的操作！

场景1：当我们在修改bug时，突然来了一个紧急的bug，这时可以使用git stash 先将修改的内容放到缓存区，然后等修改完后，再git stash pop，将原来修改的内容恢复。

场景2：当我们需要pull来更新代码时，此时也可以先git stash先“隐藏”内容，然后pull之后再pop一下，这样可以减少pull之后带来的冲突问题

#将未提交的内容，放到缓存区，以便切到其他分支
git stash
#切回到原有的分支之后，使用如下命令可以将修改的内容重新添加到本分区
git stash pop
注意：不区分分支。

 

006 cherry-pick

它可以快速将已提交的commit的应用到其他分支
场景：比如多个分支多出现了一个bug，在一个分支修改完bug后，通过cherry-pick可以快速将已修改bug commit应用到其他分支。

//会pick一个commit提交到当前的分支
git cherry-pick <commit id>
//冲突解决完之后。。。
git status
//发现 文件依然是modified 输入下面命令
git cherry-pick --continue

 

007本地项目关联git

比如：将一个本地的分支，关联远端已存在的仓库，（push）提交时提供一个新的分支（名，如use-mp-1），push到仓库中

git init //在已存在代码的根目录位置
git remote add origin 远程仓库地址  // 关联远程已有仓库
git status  // 查看本地仓库状态
git add .   // 将本地项目文件添加到版本控制（可以自己选择添加哪些文件）
git commit -am "first commit"  // 提交到本地仓库
git push -u origin master  // 提交到远程仓库 
                           //  可以使用idea push一个新的分支名到远端

 

008commit后恢复到没有提交状态

对于没有push的commit。因为“手快”代码提交错了？没关系，reset会将你提交的内容会到未提交的状态。

注意：

git的历史提交信息此时会消失
comitId值是需要修改的commit的上一个commitId

git reset --soft 1169ce2e

 

009revert：对应于已经push的commit

比如，我们连续提交了三次commit（commit1、2、 3），突然发现commit 2有bug需要撤销，但又不想影响撤销commit 3的提交，这时使用revert“反做”commit 2，这时会出现一个commit 4，它保留了commit 3提交的内容，但撤销commit2的内容。

想重新提交中间的某一个commit
//回退到某个commit提交前的信息，重新编辑后再提交
git revert 1169ce2e

 

0010通过tag拉取分支

#展示项目有哪些tag
git tag
#根据tag拉取分支：git branch  new-branch-name tag-name
git branch roman-5.4.0.6-uc-fixed 5.4.0.6-uc-fixed

0011代码自动格式化

mvn spotless:apply

 
 

二、其他备忘操作

001优雅的展示日志-日志显示一行

git log --pretty=oneline 

 

002查看两个commit之间有哪些不同的文件

git diff --name-only  66f36bda  e273d6a8

 

003修改你的用户名和密码

//查看
liano@LiangdeMacBook-Pro Commands % git config --list
//修改
git config  --global user.name roman.gao    
git config --global user.email roman.gao@xxx.com

git clone git@github.com:jxnu-liguobin/Java-Learning-Summary.git 
#此处的连接可以是SSH也可以是HTTPS，取决于你的爱好，推荐SSH。

 

004Tag相关操作

git tag

--创建tag 
--在当前分支，给最近提交的一次commit打tag
--1、轻量级
git tag v1.0(标签名)

--2、含有附注的
-a：指定标签名字。
-m：对标签的说明
git tag -a v1.2.0-beta  -m "release_1.2.0-beta  5.2发版"


#push一个
git push origin release_1.2.0-beta_tag 

 
#删除
git tag -d release_1.2.0-beta

解释：
tag是git版本库的一个标记，指向某个commit的指针，是不可移动的。
tag主要用于发布版本的管理，一个版本发布时，我们可以为git打上 v.1.0.1 v.1.0.2 …这样的标签。

tag感觉跟branch有点相似，但是本质上和分工上是不同的：
branch 对应一系列commit，是很多点连成的一根线，有一个HEAD 指针，是可以依靠 HEAD 指针移动的。
所以，两者的区别决定了使用方式，改动代码用 branch ,不改动只查看用 tag。
tag 和 branch 的相互配合使用，有时候起到非常方便的效果，例如：已经发布了 v1.0 v2.0 v3.0 三个版本，这个时候，我突然想不改现有代码的前提下，在 v2.0 的基础上加个新功能，作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ，然后作为开发分支。

重命名tag
1. git tag newtag oldtag
//删除
2. git tag -d oldtag
//
3. git push origin :refs/tags/oldtag
 
4. git push --tags

恢复到tag前提交的代码
git reset --hard 2bfb52fc   直接这样就行了。后面是那个tag的id

 

三. 相关问题

1. git push 时 remote: No anonymous write access. fatal: Authentication failed for …

先在个人github页面的Settings → Developer settings → Personal access tokens → Generate a personal access token，生成令牌
在git bash命令行中输入git push，等待弹出窗口
输入令牌