本文将一直持续更新
GIT操作记录
GIT commit 规范
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
我使用的是idea插件编写提交描述
安装插件 git-commit-template
提交点击插件
打开效果
显示日志信息
常用
// 查看日志
git log
// 显示详细日志
git reflog
// 查看git日志一行展示;展示10条
git log --oneline - 10
//同理
git reflog --oneline -10
其他:
git log --online --decorate
显示提交历史、各个分支的指向以及项目的分支分叉
git log --oneline --decorate --graph --all
创建分支
基本步骤 创建分支–> 切换分支
创建分支 —> 创建新分支;但是不会直接切换到该分支
git branch branch1
#切换到branch1分支命令
git checkout branch1
以上两步完成创建分支并切换到该分支; 可由下面一步替换
快速创建分支并切换到该分支下
创建分支并切换到该分支下面
git checkout -b branch1
GIT 分支查看
// 查看本地分支
git branch
// 查看本地分支的最后一次指向
git branch -v
// 查看本地分支所对应的远程分支
git branch -vv
// 查看所有分支
git branch -a
//查看远程分支列表
git branch -r
GIT分支合并
首先切换到需要合并的分支上;然后使用 git merge
需求 : 将 branch1分支合并到master上面
//切换到最终合并到的分支
git checkout master
//执行合并;被合并分支
git merge branch1
删除GIT分支命令
//删除指定 branch1 的分支;次分支合并之后下面删除才会成功;
git branch -d branch1
//如果需要强制删除;使用下面操作
git branch -D branch1
远程仓库分支下载本地其他分支
使用远程仓库 origin 下面的branch1分支,创建本地分支branch2;不切换当前分支创建出来的本地分支 branch2没有远程仓库指向
// git push <远程主机名> <本地分支名>:<远程分支名>
// 创建本地分支 branch2 ;将 远程branch1 的代码下载到branch2分支
git fetch origin branch1:branch2
推送本地分支到远程指定分支仓库
// 来将本地的 branch_local 分支推送到远程仓库上的 branch_remote 分支。
git push origin branch_local:branch_remote
检出远程仓库origin的branch1分支并创建本地分支branch进行追踪
// git checkout -b <branch> <remote>/<branch> 格式
// 检出远程的 branch1分支到本地的 branch分支
git checkout -b branch orign/branch1
// 上面操作的简单写法,如下, 下面意思追远程仓库branch1 并创建本地分支 branch1;并切换到该分支
git checkout --track orign/brach1
// 设置当前本地分支追踪一个刚才下载下来的远程分支
参考地址 :https://stackoverflow.com/questions/520650/make-an-existing-git-branch-track-a-remote-branch
// 设置当前 分支的追踪远程的 origin/branch 分支
git branch -u origin/branch
Given a branch foo and a remote upstream:
As of Git 1.8.0:
git branch -u upstream/foo
Or, if local branch foo is not the current branch:
git branch -u upstream/foo foo
Or, if you like to type longer commands, these are equivalent to the above two:
git branch --set-upstream-to=upstream/foo
or
git branch --set-upstream-to=upstream/foo foo
As of Git 1.7.0:
git branch --set-upstream foo upstream/foo
Notes:
All of the above commands will cause local branch foo to track remote branch foo from remote upstream.
The old (1.7.x) syntax is deprecated in favor of the new (1.8+) syntax. The new syntax is intended to be more intuitive and easier to remember.
Defining an upstream branch will fail when run against newly-created remotes that have not already been fetched. In that case, run git fetch upstream beforehand.
提交的文件 commit到本地仓库的 ;比对上一次commit的差别 HEAD^ -->commit 上一次的提交; HEAD —> 本次提交指向
git diff HEAD^ HEAD
临时暂存分支数据不提交
参考文章 https://blog.csdn.net/stone_yw/article/details/80795669
官方地址 :https://git-scm.com/docs/git-stash
场景 :
git在编写代码的时候,代码写了一半;线上有bug需要修复;但是功能没有完成;所以不想commit的解决方案;下面的命令将会把本次的修改暂时仓储到某个其他的地方去
git stash
显示所有被暂时仓储的数据
git stash list
恢复暂时被仓储的数据
方式一 :一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;
// 恢复数据
git stash apply
// 删除stash的数据
git stash drop
方式二: 恢复的同时把stash内容也删了;等同于上面的操作
git stash pop
=====================================================
你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令:
//下面的 0 就是你需要恢复的制定stash的值
git stash apply stash@{0}
//可以保存你之前的分支历史。能够更好的查看 merge历史,以及branch 状态。
git merge –no-ff
//则不会显示 feature,只保留单条分支记录。
git merge
案例说明;比如:我当前分支是master, 修复bug的分支是issue-001
//检出到master分支
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
//合并issue-001分支
$ git merge --no-ff -m "merged bug fix 001" issue-001
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
//删除该分支
$ git branch -d issue-001
Deleted branch issue-101 (was cc17032).
git merge 和 git merge --no-ff 的区别图解
参考文章地址 : https://www.cnblogs.com/phpper/p/8034480.html
下图是分析图图示例
合并多次commit 提交
参考地址 : https://blog.csdn.net/w57685321/article/details/86597808
官网地址 https://git-scm.com/book/en/v2/Git-Branching-Rebasing
请勿对已经推送到远程的历史版本进行此操作
git rebase -i [startpoint] [endpoint]
上面含义 :其中-i的意思是–interactive,即弹出交互式的界面让用户编辑完成合并操作,[startpoint] [endpoint]则指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支HEAD所指向的commit(注:该区间指定的是一个前开后闭的区间,也就是 -i 后面的 startpoint 的这次提交不会被合并)
实例演示
需求
需要 合并 从 第二次提交到最后一次提交
实现步骤
//因为前面所说的前开后闭原则; 我们需要合并的是从第二次; 所以此处 -i 后面的commit id是第一次提交的id
git rebase -i 65fab01
字段含义
pick:保留该commit(缩写:p)
reword:保留该commit,但我需要修改该commit的注释(缩写:r)
edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
squash:将该commit和前一个commit合并(缩写:s)
fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)
exec:执行shell命令(缩写:x)
drop:我要丢弃该commit(缩写:d)
按照上面解释的含义修改前缀执行合并; 修改部分 pick 为 s;之后执行 wq保存
wq保存之后页面跳转至第二个弹框;下面是 commit提示;可以进行自主修改
修改commit的信息为 下图所示; 然后 wq保存退出
保存退出之后显示结果 :如下;说明成功
在执行 日志命令;如下图所示;至此合并结束
请勿对已提交到远程的代码进行此操作!!!
GIT reset
官网地址
https://git-scm.com/book/zh/v2/Git-工具-重置揭密
引用说明 : git reset --soft
它本质上是撤销了上一次 git commit 命令。 当你在运行 git commit 时,Git 会创建一个新的提交,并移动 HEAD 所指向的分支来使其指向该提交。 当你将它 reset 回 HEAD~(HEAD 的父结点)时,其实就是把该分支移动回原来的位置,而不会改变索引和工作目录。 现在你可以更新索引并再次运行 git commit 来完成 git commit --amend 所要做的事情了
git reset --soft HEAD~
执行效果
更新索引 git reset --mixed
引用 : 它依然会撤销一上次 提交,但还会 取消暂存 所有的东西
//git rest 不带参数的默认操作
git reset --mixed HEAD~
//等效于下面
git reset HEAD~
更新工作目录( git reset --hard) !!!慎重操作
必须注意,–hard 标记是 reset 命令唯一的危险用法,它也是 Git 会真正地销毁数据的仅有的几个操作之一。 其他任何形式的 reset 调用都可以轻松撤消,但是 --hard 选项不能,因为它强制覆盖了工作目录中的文件。 在这种特殊情况下,我们的 Git 数据库中的一个提交内还留有该文件的 v3 版本, 我们可以通过 reflog 来找回它。但是若该文件还未提交,Git 仍会覆盖它从而导致无法恢复。
git reset --hard HEAD~
执行上面操作之后文件 test.txt 的内容
执行之前test.txt的原内容;也就是 第三次提交的内容
谨慎使用 git reset --hard操作
Git 修改本地分支名称
// git branch -m '原分支名' '新分支名'
// 本地原分支名称 temp 修改为 temp_before
git branc -m temp temp_before
//如果 当前所处的分支就是 temp分支;则可以直接
//git branch -m temp_before
GIT revert
//回滚到指定commitId 提交之前的版本信息
git revert "需要回滚的commitId"
例如
//回滚到 524a4fd 提交之前的版本数据信息
git revert 524a4fd