git log --oneline

将git日志在一行中展示

git checkout(gco)

将代码复原到任何一个状态上,但不修改仓库的信息

• git checkout 版本号

• git checkout SHA-1

• git checkout master (本地分支)

• git checkout origin/master (远程分支)

• 新建一个XX状态的分支: git checkout -b 分支名1 其他能代表分支的状态
  例:
  git checkout -b newBranch origin/oldBranch
  根据远程oldBranch分支创建了一个本地newBranch 分支

• 在工作目录和暂存区移动文件
  git checkout -- 文件名

  
  git结构.png

例:
若文件A.txt在git add后,做了新的修改,那么修改前的A.txt在暂存区,修改后的A.txt在工作区.
如果不需要修改后的A.txt,那么使用git checkout -- A.txt 即可丢弃工作区的文件

git reset(gr)

强行将当前分支HEAD的指针移动到指定状态

• git reset HEAD --hard (清空工作区)

• git reset origin/master

• git reset SHA-1

• git reset HEAD~3 (HEAD的往前推三个的父版本)

• --soft (只回退了commit信息)

• --mixed (默认选项,保留源码,回退add和commit信息)

• --hard (彻底回退到某个版本,源码也会相应回退)
  使用场景:
  1.迅速将分支恢复到某个状态
  2.合并提交squash commits,例如方便rebase

例:
合并提交,分支branch1的多个commit,但是只想显示一个commit:
git reset branch1 --mixed (仅回退add和commit,代码保留,--mixed可省略)
git add
git commit
git push

注:

git reset HEAD *.java
(*在此为gobbling command line,如果存在既有untracked的文件,又有tracked的文件,那么命令行会失效,若只有一种,则有效)
此时,混合的特殊情况,用git reset HEAD '*.java' (即可让git识别文件,并执行该通配符命令)

git cherry-pick(gcp)

将某个提交在另外的分支上重放

• git cherry-pick de6613c
  使用场景:
  1.希望把一个bug fix同步到老版本中
  2.在master中进行的变更,希望进入到release环节
  例:
  已经在v3.0修复了一个远古bug,想同步恢复到v9.0中
  git checkout v9.0
  git cherry-pick 修复bug的SHA-1
  若有冲突
  git status
  解决冲突
  git add 冲突的文件
  git cherry-pick --continue

注:

cherry-pick后提交的commit与之前的commit不相同,SHA-1的id不同

git revert

产生一个反向提交,撤销某一个commit

• git revert de6613c
  产生的反向提交可以再次进行revert,即恢复最初的commit,但依旧会生成一个新的SHA-1
  使用场景:
  1.撤销历史中的某个更改,如bug或不恰当的功能
  2.回滚某次发布

git bisect

在历史中查找某处引入的bug(通过二分查找)

• git bisect start/reset

• git bisect good/bad/skip

• git bisect run
  使用场景:
  1.在问题可以稳定重现的时候,迅速定位问题代码
  2.有时候比debug更快

• 使用步骤:
  先手动,确定验证操作的流程,便于写脚本.再自动(git bisect run)
  例:查找v10.0-v1.0之间bug何时引入的

• 方法一:手动查找
  git checkout v10.0 (确定该版本确实有问题)
  git bisect bad
  y
  git chekcout v1.0(确定该版本没问题)
  git bisect good
  二分查找到v5.0,并会被自动切换到v5.0版本,验证该版本是否有问题
  若有问题git bisect bad,没问题git bisect good,若无法确定git bisect skip,以此类推,获得有问题的版本

• 方法二:自动查找
  git checkout v10.0 (确定该版本确实有问题)
  git bisect bad
  y
  git chekcout v1.0(确定该版本没问题)
  git bisect good
  git bisect run ./run.sh

run.sh脚本内容如下(以查找maven的问题为例):

#!bin/sh

#获取maven版本号
VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)

#执行前,先删除上一次执行的内容
rm -rf apache-maven-* &&\
# &&\为执行成功该行后,再执行下一行
mvn clean package -DskipTests -Drat.skip=true &&\
#解压缩maven的打包到指定文件夹(即压缩包的当前文件夹下)
unzip apache-maven/target/apache-maven-$VERSION-bin.zip -d . &&\
#由于maven默认setting使用org中心仓库,下载慢,所以修改为本地maven的阿里云配置
cp -rf /sofaware/apache-maven-3.5.3/conf/settings.xml apache-maven-$VERSION/conf
#文件和路径名根据具体的项目修改
apache-maven-$VERSION/bin/mvn -f /project/maven-issue/pom.xml compile

git stash(储藏)

临时性将工作目录的变更内容存起来,然后清空工作目录

• git stash (存档)
• git stash list (查看存档list)
• git stash pop (读档)
• git stash apply stash@{n} (多个存档中,挑选第n个读取)
  使用场景:
  1.正在开发,突然线上来了个bug
  2.此时只能将手头的工作保存之后,开始别的工作
  3.结果又来了个优先级更高的bug
  4.完成别的工作之后回来继续
  类似于存档/读档

git tag

指针,指向某个恒定的版本
例:
方法一:
对38f27f2打个v1.0的版本号
git checkout 38f27f2
git tag v1.0
git push --tags (发布所有的tags) 或
git push v1.0 (仅发布v1.0的tag)
方法二:
对38f27f2打个v1.0的版本号
git checkout 38f27f2
git tag -a v1.0 -m '1.0版本发布信息'
git push --tags (发布所有的tags)