1、写了2个需求的代码一次性提交暂存了, 不符合规范,想分2次分别commit
此时需要先执行一个命令,进入交互式模式:git add -i
可以revert把已经提交暂存的文件挪出来。

2、版本的回退和前进:git reset --hard commit标识符
3、在当前分支上,如果要回退到过去的某个历史版本的话,那么此时应该是用git log就可以,但是如果要回到未来的某个版本,是用git reflog
git log和git reflog的区别:
git log,是你当前的分支指向的commit之前的所有commit会显示出来,你的分支指向的那个commit之后的commit是不会显示的
git reflog,是会显示最近几个月,完整的一个commit历史的
用git reflog命令就能查看完整的一份commit记录,而使用git log就只能查看当前分支指向的那个commit之前的commit记录

4、git log --abbrev-commit master…feature/001
查看哪些commit是feature/001分支可以触达的,但是是master分支无法触达的,此时就可以看到feature/001分支做的那些改动哪些还没有合并到master分支里去

5、写需求写到一半,需求切分支去修复线上bug,但是又不想commit一个半成品的代码:
此时执行一个命令:git stash
同时我们可以查看一下stash列表:git stash list
git stash apply --index,将工作区和暂存区中的内容进行恢复
git stash drop stash名称,手动删除掉某个stash

6、修复上一个提交的不符合公司规范的备注
git commit --amend

7、对上一次commit加入几行遗漏的代码
或者说,你刚执行了一个commit,结果扫了一眼代码,发现今天忘记修改几行代码了,需要修改之后补充到上一个commit中去,没关系
先修改你的代码,同时加入暂存区,然后再次执行:
git commit --amend
就会将你最新修改的代码跟上一次合并到一个commit中去

8、对历史上的多个commit进行修改
这个场景,常见于这样,你可能在本地连续几天都提交了几个commit了,但是一直都忘了push到远程仓库。此时突然有一天,你发现你需要将这个几天的commit都是一次性push到远程仓库,但是你看了一下,发现你3天前的某个commit的备注不规范,需要调整一下,此时你需要。。。

git commit --amend,只能针对最近一次commit去修复和调整

使用git rebase -i HEAD~3,就是调整最近3个commit

同时要注意,如果你已经推送到了远程版本库的commit,不要修改和调整

然后需要将你需要调整的commit之前的pick修改为edit,比如选择其中一个commit

此时你需要对你要修改的commit,一个一个的进行修改,可以修改3天前的那个commit的备注,执行git commit --amend即可

你如果要对前几天的某个commit加入更多的代码,可以仿照之前讲解过的那个先修改代码,加入暂存区,接着git commit --amnend,就可以加入代码。或者是直接执行git commit --amend,修改备注即可。

修改完了一个commit之后,可以执行下面的命令,继续修改下一个commit

结束之后,执行git rebase --continue

最终会将你设置为edit的那几个commit都让你一个一个的修改

9、将一个commit切分为多个commit
还有一种情况,就是你不小心将3天修改的代码都合并成了一个commit了,此时木已成舟,没法用git add -i来多次commit了,咋办?

没事的,将这个commit拆分为多个commit就好了

还是在上面那个界面,将要拆分开来的commit前面的指令,修改为edit

然后你就会回到那个commit对应的版本,此时执行git reset HEAD^,此时会直接回退到之前的状态,然后此时可以执行多次git add和git commit,形成多个commit

接着最后执行git rebase --continue结束这次commit拆分

10、推送了merge后的commit到远程仓库之后想要撤回
服务A,依赖于其他团队开发的服务B,在不同的仓库里的两个项目;但是。。。你要一起上线的其他团队的同学,服务B,突然发现在QA环境,临时测试出来了一个大bug,此时pm沟通了一下,评估了一下风险,决定,今天取消上线,下周再上

尴尬了

你的代码都合并到master分支了。。。但是说不上线了,此时你是不能将不准备上线的代码留在master分支里的

如果碰到这样的情况,你是需要将本次之心的merge给撤回的,无论是本地还是远程,都要撤回

但是如果push到了远程仓库以后,你是不能再本地reset一下,再push的,因为那样会搞乱你的提交历史的

不上线了。。。撤回release/v1.2.0到master分支的合并

需要在本地执行一个命令:git revert -m 1 HEAD

git revert实现的效果,不是说指针往回挪动,而是说创建一个新的commit,对应的代码版本跟合并之前的那个commit是一模一样的

-m 1的意思就是,恢复到当前这个分支合并之前的那个状态,此时会创建一个新的commit,这个新的commit对应的版本跟合并之前的commit是一模一样的

这就完美撤回了merge操作,同时此时如果执行git push origin master,会让远程仓库的master分支也回退到merge之前的状态,但是也多了一个新的commit出来

但是此时有一个问题,就是如果再次执行git merge feature/001,你会发现,git不让你merge了,因为之前已经merge过了,很尴尬

这个时候,过了几天了,然后呢,已经准备好可以上线了,你需要重新将release分支的代码合并到master分支上来,此时该怎么办呢?

而且此时一般是说feature分支需要继续修改代码,比如又加入了一些代码,但是如果这个时候你胡乱再次合并,会发现master分支仅仅merge进去了feature分支后来修改的那一点代码而已。。。。

此时,要做的事情是,继续对feature分支进行修改,完成最终版本的代码

然后,再次执行git revert HEAD,将master分支再次进行revert,回退到之前merge过后的那个状态,这个状态是包含了feature分支merge进来的部分代码的,然后再次执行git merge feature/001,将feature分支最新的修改也merge进来

ok了,完美解决,再次git push origin master,推送到远程分支去

10、需要追责时,二分查找引入bug的commit
谁在哪一次commit具体的引入了这个bug,用git提供的二分查找

git bisect start:开始二分查找
git bisect bad:标注当前这个commit是有bug的
git biset good v1.0.0:用tag来标注说从上一次哪个上线为止,是没有bug的,就是那个tag对应的commit之前都是好的

此时git会做一个二分查找,比如说两次commit中间差了12个commit,此时会给你定位到第6个commit

然后你可以对这个版本的代码,运行个测试用例,看看bug能否复现出来

11、后开发的版本想比先开发的版本先上线:
现在假设我们同时在开发两个版本,v1.0和v1.1,然后pm突然决定,将v1.1的部分功能提前放到v1.0版本先上线?此时该怎么办呢?
用git cherry-pick功能

如果我们要做到部分功能提前挪到v1.0先上线,那么就需要将v1.1中那些功能对应的git commit放到v1.0分支上去,然后将那些commit对应的代码都应用到v1.0分支上去,就可以了

git checkout feature/v1.0
git cherry-pick feature/v1.1分支对应的多个commit标识