Git的工作流
本文参考链接
清华杨希杰的git分享 [https://thu-ios.github.io/tutorials/lecture/git.html]
up主「玄离199」的git视频教程 [https://www.bilibili.com/video/BV1d6XVYqEuy?spm_id_from=333.788.player.player_end_recommend_autoplay&vd_source=e5f4d0f4141c018524aa67bc05a7a2c2]
Python core dev成员高天大佬的工作流视频
Git 飞行规则指南 [https://github.com/k88hudson/git-flight-rules/blob/master/README_zh-CN.md]
配置设定
配置
本机上的git信息:姓名、邮箱
git config user.name # Cody
git config user.email # liuke504356312@gmai.com
使用下列命令进行更改
git config --global user.name Cody #更改名称
git config --global user.email liuke504356312@gmai.com #更改邮箱
在与远程仓库进行 代码交互时,本地的分支应该与远程的一个分支相对应(相绑定),否则在第一次push时会报错。但是我们也可以设置Git自动为新分支设置上游·
# 设置Git 会自动绑定 dev 到远程同名分支。
git config --global push.autoSetupRemote true
gitignore(指明不参与git上传的文件信息,比如密码文件、图片文件等)
在当前目录上创建.gitignore
文件。其中填写的文件与文件夹不会参与git上传
想更精细可去 https://www.toptal.com/developers/gitignore 自动生成。例如java, intellij, maven, gradle, macos 的组合模板。

image-20250724164128210
macbookpro的git本机密钥
#存储位置
/Users/yourname/.ssh/id_ed25519 # identificatiopn (private key)
/Users/yourname/.ssh/id_ed25519.pub # public key
#密码,用来保护私钥,未进行设置。否则每次ssh连接github还需使用密码提取私钥才能进行

image-20250524180128832
分区
工作区(Working Directory)←→ 暂存区(Stage/Index)←→ HEAD(最后一次 commit)
- 工作区:你正在编辑的真实文件;
- 暂存区:用 git add 添加后的内容,准备提交;
- HEAD:你最后一次 git commit 的版本快照。
命令介绍

git的工作示意图
git diff
git diff # worktree & stage (Changes in the working tree not yet staged for the next commit.) 改了但还没 add 的内容
git diff HEAD # worktree & HEAD (Changes in the working tree since your last commit.) add 了、还没 commit 的内容
git diff --cached # stage & HEAD (Changes between the index and your last commit.) 总体来看,哪些东西跟上次提交不一样(包含 add 和没 add 的)
git diff <commit> <commit> # between two commits 看某两次提交之间的变更
#可以加 --stat 查看概览(文件改了多少行):
git diff --cached --stat
#可以加 --name-only 只显示变动文件名:
git diff HEAD --name-only
git restore
舍弃更改 等价于 用某些之前的东西来覆盖
git --help restore # 查看restore命令的帮助文档
git restore
== git restore --worktree
默认是覆盖worktree
# 参数简介
#指定 覆盖文件来自的分区 。
#默认情况下,覆盖工作区文件,来自分区为 暂存区(Stage/Index),覆盖暂存区文件,来自分区为HEAD区
-s <tree>, --source=<tree>
Restore the working tree files with the content from the given tree. If not specified, the default restore source for the working tree is the index, and the default restore source for the index is HEAD.
#指定 要被覆盖文件的分区,默认情况为工作区(worktree)
-W, --worktree, -S, --staged
Specify the restore location. If neither option is specified, by default the working tree is restored.
merge与rebase辨析
操作 | 目的 | 原理 | 提交记录 |
---|---|---|---|
git merge | 合并两条提交线 | 自动创建一个“合并提交” | 会出现一个“合并 commit” |
git rebase | 把你的提交“搬到”最新主干上 | 重新排列提交 | 保持提交线清晰,没有合并点 |
对于非公共分支,推荐使用rebase:
优点 | 说明 |
---|---|
✅ 更干净的提交历史 | 没有一堆“Merge branch xxx”的噪音提交 |
✅ 提交线性 | 每个人的提交看起来都是从当前最新的主干出发 |
✅ 更容易 review | Pull Request中每个commit都是干净的功能提交,没有因主干改变而产生"追随主干的额外提交" |
✅ 推荐使用rebase的时机
即,先rebase,在push。 对已经上传的不要再进行rebase变基了。
何时使用 | 推荐 |
---|---|
合并主干代码前 | ✅ 使用 git rebase main |
已经 push 到远程、团队成员也基于你工作 | ⚠️❌ 不推荐 rebase(会让别人历史错乱) |
rebase 就像“排练”,让你提交历史整洁、看起来像没分叉过;即,你的新分支修改就是 基于最新的 主干main分支。
merge 就像“记录真实开发流程”,保留所有分叉和合并;即,如果修改分支是基于 上一版本的 主干main,当前新版的main分支有冲突,解决冲突的过程也会当作一个commit会被记录。
分支(branch)
创建一个分支,你可以在这个分支上开发新功能A,过一段时间,你又想开发新功能B,这时你可以再开一个分支。过了一段时间,你两个新功能都开发好了,就可以将两个分支合在一起,这样你的产品就同时有了两个新的功能。
git branch --create(-c) <newBranch> # 创建分支
git branch # 查看本地分支
git switch <newBranch> # 切换分支
# 开发好了新功能之后
git switch main # 切换到主分支,因为我们的所有功能都要合并到一个分支上
git merge <newBranch> # 将开发新功能的分支的内容合并(merge)到main分支上
git branch --delete(-d) <newBranch> # 删除开发新功能的分支,因为开发好了合并进来原来的开发分支就没有用了
设置默认分支从master
变为main
# 查看Git版本
git --version
# Since git version 2.28.0
git config --global init.defaultBranch main
# 之后使用git init初始化项目的默认分支会变为main
git init
# or for one repo
# 还未创建的项目
git init -b main
# 已经存在的项目
git branch --move(-m) master main
版本回退
版本回退可以通过git reset
与git revert
这两条指令进行
首先我们需要明确两点:每一次commit
的编号,一方面代表所有文件的状态,另一方面代表这一次commit
相比于上一次commit
所做的更改。
那么我们如果希望回到之前的某个commit
,指的就是直接将工作区所有文件都恢复成那个commit
之后的样子。
这时我们需要使用:
git reset --hard <commit>
如果我们希望撤销某次commit
所做出的更改,那么我们需要使用:
git revert <commit> # Git帮你提交
git revert -n <commit> # -n: --no-commit,自己提交

image-20250524181847810
两种回退的分析:
git reset --hard
是非常方便的回退方式。如果你写代码提交了两个commit
之后去吃饭,吃完回来一看,觉得刚刚状态不太好写的不行,于是你git reset --hard
回到两个版本之前,发现所有的东西都变成了你修改代码前的样子。
git reset --hard
会删除commit
,所以如果你在某次commit
中添加了敏感信息(如账号密码等),那么使用git reset --hard
进行恢复是十分明智的选择。
但是要注意,在上面的案例中,如果你已经将两次commit
使用git push
上传到了Git服务器,那么git reset --hard
一定会给团队协作带来混乱(因为你直接删除了两个commit!)。这时怎么办呢?你可以使用两次git revert -n
再git commit
,这样你会新生成一个commit
,这个commit
的内容和往前两次commit
的内容一样,由于这是新生成的commit
,所以push到服务器也完全没有问题。
那么如果把密码git push
到服务器了呢?这时Git
已经帮不了你了。要不直接在代码托管平台直接删掉项目吧(不推荐),要不就赶紧去改密码吧…
注:其中的版本号<commit>
可以通过git log
查看。
注:向后回退一个版本可以写为git reset --hard HEAD^
,HEAD^^
表示当前版本向后2个commit
,HEAD~n
表示当前版本向后n个commit
。
远程仓库相关
- 绑定远程仓库
# 本地文件夹与远程仓库绑定 my-repo-nickname远程仓库别名, my-repo-url远程仓库地址
git remote add <my-repo-nickname> <my-repo-url>
# 示例: 绑定后直接用testRepository就可以代指github上的仓库
git remote add testRepository git@github.com:liukegeek/FanucAgent.git
查看关联的远程仓库
git remote --verbose
git remote --verbose show <repo-nickname>

image-20250527155219064
- 克隆远程仓库
git clone <team-repo-url> --origin <team-repo-nickname> <project-folder>
# 通过clone ,可以下载远程仓库的文件,并自动完成本地仓库与远程仓库的绑定。
--origin <远程仓库名>
用来给默认的名字origin重命名
<project-folder>
指本地新出现的文件夹的名称
#示例:
git clone git@github.com:liukegeek/FanucAgent.git --origin FancuDemo demoFolder
git clone git@github.com:liukegeek/FanucAgent.git
#后面参数可省略,这样默认远程分支名为orgin,下载的文件夹为 远程仓库的项目名称
- 拉取远程仓库的内容
# 拉取最新的内容
git fetch <team-repo-nickname> # 或 git fetch --all
git switch main #将`远程仓库某分支`的内容 与`本地仓库分支` 合并,保持同步
git merge <team-repo-nickname>/main
然后自己新开一个修改分支,完成自己的修改后用git merge <newBranch>
将修改分支合并到主分支。
主分支、修改分支合并时,要先重新fetch,确保主分支与远程分支同步后再合并。
如果主分支、修改分支间有冲突,则解决冲突后还要记得再fetch,确保新的主分支与远程分支间没有冲突。
总之,要保证push时,不会与远程仓库发生冲突。
- push到自己的远端仓库
# 将某一本地分支推到远程主机的远程分支;如果远程仓库没有这一分支,则创建
git push <my-repo-nickname> newFeature:newFeature
# git push <远程主机名> <本地分支名>:<远程分支名> 前面的是本地分支名,后面的是远程分支名,
#如果远程、本地分支名称一样,则可简写为:
git push <my-repo-nickname> newFeature
#注意: gitHub默认为main,因此在往github提交代码时,最好把本地主分支改名为 main
示例
git push testRepository master:main
git push testRepository newFeature:newFeature
git push orgin localName:remoteName
git push testRepository main
git push testRepository newFeature:newFeature

image-20250525010221023
- 删除远程分支
- 方法一:在团队仓库的PR界面,如果成功merge,那么你可以看到一个
delete branch
的按钮,可以直接点击按钮删除自己fork的仓库中的newFeature分支 - 方法二:
git push <my-repo-nickname> --delete newFeature
- 方法一:在团队仓库的PR界面,如果成功merge,那么你可以看到一个
- 删除本地分支
- 切换到主分支下,然后执行
git branch -d newFeature
指令 - 使用
git remote prune yxj
删掉本地陈旧的远端分支(就是 远端已经删除掉了但是本地还没删除掉的分支)
- 切换到主分支下,然后执行
标签管理
tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。见github主页的tag部分

image-20250527161347858
# 给当前commit的版本打上标签: first versioin
git tag -a "1.0" -m "first versioin"
#将标签上传至远程仓库: 在push命令后面添加 --tags 参数.
git push origin --tags
# 注意: 这个tags是直接带着·资源·发布的,而不是跟自己的远程分支绑定,即使添加tag与所在分支没有任何关系。
现在从实用场景角度,把 Git 标签(tag)为什么存在、什么时候该用 介绍一下:
一、标签(Tag)到底是干什么用的?
标签是 Git 中用于“给某个提交打上里程碑”的功能。
可以将其理解成:“给历史上的某一个提交贴个版本号的标签”。
📌 标签是:
🏷️ 一个永久性的、只读的、不会随分支移动的名字。
二、哪些场景下必须用标签(tag)
场景 | 是否需要 tag | 原因 |
---|---|---|
发布正式版本(如 v1.0.0) | ✅ 必须 | 用来标记当前代码为“稳定版本” |
开发周期结束阶段,需要生成版本包(ZIP、release note) | ✅ 必须 | GitHub Release 等工具依赖 tag |
自动化部署(CI/CD) | ✅ 常用 | 一般会监听 tag 触发部署流程 |
回滚、定位某次发布 | ✅ 推荐 | tag 是找回某个 commit 的“标签索引” |
三、哪些场景下推荐/没必要使用 tag?
场景 | 是否需要 tag | 原因 |
---|---|---|
在个人开发分支中做临时提交 | ❌ 不需要 | commit 自己就能记录开发进展 |
功能开发中想做多个提交(未准备发布) | ❌ 不需要 | commit + push 就够了 |
团队协作过程中不断合并代码 | ❌ 不需要 | 分支足够表达逻辑,tag 会混乱 |
✳️ 自己开了一个功能分支,用来开发一个功能,我需要打 tag 吗?
❌ 不需要!
只需要按需提交即可(使用 commit);等功能完成、合并到主干后,主干准备发布了,那时才需要 tag。
✳️ 是不是只有管理主干分支 main 的时候,才需要 tag?
✅ 几乎可以这么说。
大部分项目的 tag 都是打在 main(或 master)分支的某个特定提交上,代表的是:
- v1.0.0 发布
- v2.1.3 修复版
- v3.0.0 重构版本
🎯 小结口诀
✳️功能开发看分支,版本发布看标签。
分支记录过程,标签记录里程碑。
✅ 最佳实践推荐
阶段 | 建议做法 |
---|---|
功能开发 | git commit + git push,不要打 tag |
功能合并 | 合并到主干,开始准备发布 |
准备发布 | git tag -a v1.0 -m "发布1.0版本",然后 git push origin --tags |
版本回顾 | 通过 git tag / git show v1.0 找到历史 |
异常解决

image-20250525002605970
错误原因是:
- GitHub 上的 main 分支,已经有一些提交;
- 而你本地的 main 是从零开始创建的,没有那些提交历史;
- Git 拒绝直接推送,是为了防止你“覆盖别人已有的内容”。
解决办法:
git pull --rebase testRepository main
# 解释:
# • git pull 是 先把远程仓库的提交拉取到你本地;
# • --rebase 是 把你的提交“叠加”在远程提交之上,这样避免了多余的“合并记录”;
# • testRepository 是你之前设置的远程仓库名。
#首次推送本地分支给远程仓库的流程
# 1. 确保绑定远程仓库分支
git remote add remoteName git@github.com:xxx.git
# 2. 拉取远程已有提交,并通过变基方式合并
git pull --rebase origin main
# 3. 正常推送
git push
当然,也可以拉取远程仓库的内容到本地,然后合并后再推送。这也是每次推送都应遵循的做法,包括第一次。
git fetch <repo-nickname> # 将远程仓库的内容拉取到本地
git merge # 将本地中远程仓库的内容merge到当前分支
GitHub工作流
参考于
高天
的视频:github工作流
- clone远程仓库
git clone git@github.com:liukegeek/FanucAgent.git
#详细版:指明remote的仓库名为FanucDemo(否则默认为origin),下载的文件夹为demoFolder(否则默认为项目名)
git clone git@github.com:liukegeek/FanucAgent.git --origin FanucDemo demoFolder
- 本地创建分支
#创建并切换分支, 新版git的命令,语义更清晰。
git branch -c myFeature
git switch myFeature
# 也可以直接一步到位,直接创建并切换分支
git switch -c myFeature
#老命令,等同于创建分支并切换过去,等价于git switch -c myFeature,建议优先使用新式命令
git checkout -b myFeature
- 对work directory文件进行修改,并保存到本地仓库
git diff # 查看更改了哪些内容
git add . # 添加所有文件
git commit -m "message" # 带注释信息提交
- 拉取同步远程的最新主干
看是否有别人新的update,导致remote main 与local main不一致,防止冲突.
可以通过pull自动进行合并,也可以fetch手动进行合并。
# 对于非公共分支,建议使用fetch + rebase进行合并
(main): git fetch origin main #拉取远程main的数据,但不合并。不加main会拉取远程仓库的所有分支信息
(main): git merge origin/main # 将拉取到的远程main的数据,合并到本地main中
git switch myFeature # 转换成修改分支myFeature
(myFeature): git rebase main # 将 我的修改先mian的最新版本拿过来 然后再把我的修改尝试添加到新版main上。
# 拉取也可以使用pull,pull既拉取又合并
git pull origin main #等效于: git fetch origin main + git merge origin/main
# 如果省略main,git pull origin 就变成根据当前所载分支来拉取对应的远程分支,并合并
#合并也可以接着用merge,这一步merge和上面rebase的目的都是,将修改分支的main更新成新版的main
git switch myFeature
(myFeature): git merge main #将 主分支main 合并到修改分支myFeature上。
#merge会有合并提交的记录,rebase会让提交更线性干净。公共分支别用rebase,否则会改变其他成员的历史
- 推送远程
git push origin myFeature/myFeature #若remote端无该分支,则将在github上面新增一个分支:myFeature,并将本地myFeature的信息同步进去。
#注意,推荐在 myFeature端 进行push,不要直接操作 master branch界面进行push !!! 否则如果remote 的main有新update,本地的master还需要考虑冲突与合并。

image-20250527234544817
注意,图片中-f
是强制合并的意思。因为是先push,发现有冲突后在pull、rebase解决冲突。而rebase 会重写提交历史(提交的哈希值变了),导致本地的历史和 GitHub 上的远程历史不一样。而Git 为了保护远程历史,默认不允许 push 改写后的提交。因此必须使用-f
参数进行强制推送。
显然如果是该分支首次push,此时remote还没有该分支,那么就不会有远程历史与本地历史不一致问题,推送也不会被拒绝,我们也就不需要加-f
参数。
但是在本篇中,我们优化了流程,在提交并建立remote端时就已经在本地完成先进行了比对,有冲突先rebase再首次提交。 因此大概率第一次push就是基于最新版的master,直接推上去就结束了(不用加 -f)。除非是这个分支的非首次提交,且项目的主干又有了新的更新,我们被迫需要rebase到新主干上去。这时就必须加-f
了,不过由于更改分支一般是自己创建仅用于个人修改,且已经在本地rebase了最新主干,因此强制push也不会有影响。
- 发起PR(Pull Request)
进入分支页面,点击commit内容,查看提交详情

image-20250528133008416
点击create pull request按钮,进入申请界面

image-20250528132858272
填写相关描述,创建pr申请。

image-20250528133325517
- 审查代码,合并提交
有可能一个功能分支上会带着许多commit,我们不希望把功能分支上的所有branch都放到main branch上,我们希望我们的main branch history 尽可能简洁、正常工作。因此,大多数情况下,面对Pull Request 我们会选择 Squash and merge: 一个分支上的所有改变整合成一个改变,然后放入到main branch上。 这不会影响具体的代码改动,只是comimt history中的 commit的结构、数量、名字发生了改变。
- 进入Pull requests界面,点击分支名称,进去详情界面查看更改。

image-20250528122749643
- 将功能分支通过
Squash and Merge
合并到主分支上

image-20250528122642825
- 为合并后生成的一个commit,添加信息说明。

image-20250528133908136
- 代码审查通过后,删除分支
remote端的 myFeature 可以通过 gitHub上面的一个按钮删除。

image-20250528134231473
local 端的myFeature 通过 -d
指令删除。
git switch main # 切换回主分支
git pull origin main #拉取remote端的分支,让local 与 remote 的main 重新保持同步。
git branch -d myFeature #删除已经提交完不在使用的分支:myFeature
附:可能有用的命令整理
git add xyz # 添加xyz文件至index
git add . # 增加当前子目录下所有更改过的文件至index
git branch # 显示本地分支
git branch --contains 50089 # 显示包含提交50089的分支
git branch -a # 显示所有分支(远端分支+本地分支)
git branch -r # 显示所有远端分支
git branch --merged # 显示所有已合并到当前分支的分支
git branch --no-merged # 显示所有未合并到当前分支的分支
git branch -m master master_copy # 本地分支改名
git branch -dr [remote/branch] # 删除远程分支
git branch -d hotfixes/BJVEP933 # 删除分支hotfixes/BJVEP933
git branch -D [branch-name] # 强制删除分支branch-name
git branch --set-upstream dev origin/dev # 指定本地dev分支与远程origin/dev分支的链接
git branch [branch-name] # 新建一个分支,但依然留在当前分支
git branch --track [branck-name] [remote-branch] # 新建一个分支,与指定的远程分支建立追踪关系
git checkout [file] # 恢复暂存区的指定文件到工作区
git checkout [commit] [file] # 恢复某个commit的指定文件到暂存区和工作区
git checkout . # 恢复暂存区的所有文件到工作区
git checkout -b master_copy # 新建一个分支,并切换到该分支
git checkout -b master master_copy # 上面的完整版
git checkout features/performance # 检出已存在的features/performance分支
git checkout --track [branch-name] # 新建一个与远程分支同名的分支,并切换到该分支
git checkout v2.0 # 检出版本v2.0
git checkout -b devel origin/develop # 从远程分支develop创建新本地分支devel并检出
git checkout -- README # 检出head版本的README文件(可用于修改错误回退)
git config user.name # 查看config中配置的 user.name
git config --list # 列出Git可以在该处找到的所有的设置 (或者 git config -l)
git config --global user.name "xxx" # 配置用户名
git config --global user.email "xxx@xxx.com" # 配置邮件
git config --system --list # 查看系统config
git config --global --list # 查看当前用户(global)配置
git config --local --list # 查看当前仓库配置信息
git config --global color.ui true # git status等命令自动着色
git config --global color.status auto
git config --global color.diff auto
git config --global color.branch auto
git config --global color.interactive auto
git config --global --unset http.proxy # remove proxy configuration on git
git clone git+ssh://git@192.168.53.168/VT.git # clone远程仓库
git cherry-pick ff44785404a8e # 合并提交ff44785404a8e的修改 (选择一个commit,合并进当前分支)
git commit -m 'xxx' # 提交
git commit --amend -m 'xxx' # 合并上一次提交(用于反复修改)
git commit -am 'xxx' # 将add和commit合为一步
git diff # 显示所有未添加至暂存区的变更
git diff --cached # 显示所有已添加index但还未commit的变更
git diff HEAD^ # 比较与上一个版本的差异
git diff HEAD -- ./lib # 比较与HEAD版本lib目录的差异
git diff origin/master..master # 比较远程分支master上有本地分支master上没有的
git diff origin/master..master --stat # 只显示差异的文件,不显示具体内容
git fetch # 获取所有远程分支(不更新本地分支,另需merge)
git fetch --prune # 获取所有原创分支并清除服务器上已删掉的分支
git fsck
git gc
git grep "delete from" # 文件中搜索文本“delete from”
git grep -e '#define' --and -e SORT_DIRENT
git init # 初始化本地git仓库(创建新仓库)
git log # 显示提交日志
git log -1 # 显示1行日志 -n为n行
git log -5
git log --stat # 显示提交日志及相关变动文件
git log -p -m
git log v2.0 # 显示v2.0的日志
git log --pretty=oneline # 只显示版本号和说明
git log --pretty=format:'%h %s' --graph # 图示提交日志
git ls-files # 列出git index包含的文件
git ls-tree HEAD # 内部命令:显示某个git对象
git merge origin/master # 合并远程master分支至当前分支
git merge [branch-name] # 合并指定分支到当前分支
git mv README README2 # 重命名文件README为README2
git pull origin master # 获取远程分支master并merge到当前分支
git push origin HEAD # 将当前分支push到远程dev分支
# git push <远程主机名> <本地分支名>:<远程分支名> 前面的是本地分支名,后面的是远程分支名,
git push origin dev # 将当前分支push到远程dev分支 (同名可以省略冒号部分)
git push origin master # 将当前分支push到远程master分支
git push origin :hotfixes/BJVEP933
# 删除远程仓库的hotfixes/BJVEP933分支 效果等同于(git push origin --delete hotfixes/BJVEP933 )
git push origin --delete hotfixes/BJVEP933 # 删除远程仓库的hotfixes/BJVEP933分支
git push origin :refs/tags/v0.9 # 删除远程远程仓库的refs/tags/v0.9分支
git push origin --tags # 把所有tag推送到远程仓库 (git push 的时候不会推送tag,可以使用这个命令推送tag)
git push --force origin
# git push的时候需要本地先git pull更新到跟服务器版本一致,如果本地版本库比远程服务器上的低,那么一般会提示你git pull更新,如果一定要提交,那么可以使用这个命令
git push --all origin # 当遇到这种情况就是不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机,这时需要 -all 选项
git revert dfb02e6e4f2f7b573337763e5c0013802e392818 # 撤销提交dfb02e6e4f2f7b573337763e5c0013802e392818
git rev-parse v2.0 # 内部命令:显示某个ref对应的SHA1 HASH
git reflog # 显示所有提交,包括孤立节点
git rm xxx # 删除index中的文件
git rm -r * # 递归删除
git rm --cached [file] # 停止追踪指定文件,但该文件会保留在工作区
git remote add origin git+ssh://git@192.168.53.168/VT.git
# 增加远程定义(用于push/pull/fetch)(本地git仓库关联GitHub仓库)
git reset --hard HEAD # 将当前版本重置为HEAD(通常用于merge失败回退)
git reset --hard 6fcfc89 # 版本回退到6fcfc89版本
git reset [file] # 重置暂存区的指定文件,与上一次commit保持一致,但工作区不变
git reset [commit] # 重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变
git reset --hard [commit]
# 重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致
git reset --keep [commit]
# 重置当前HAED为指定commit,但保持暂存区和工作区不变
git rebase
git show HEAD@{5}
git show master@{yesterday} # 显示master分支昨天的状态
git show v2.0 # 显示v2.0的日志及详细内容
git show dfb02e6e4f2f7b573337763e5c0013802e392818 # 显示某个提交的详细内容
git show dfb02 # 可只用commitid的前几位
git show HEAD # 显示HEAD提交日志
git show HEAD^ # 显示HEAD的父(上一个版本)的提交日志 ^^为上两个版本 ^5为上5个版本
git status # 查看当前版本状态(是否修改)
git show HEAD~3
git show -s --pretty=raw 2be7fcb476
git stash # 暂存当前修改,将所有至为HEAD状态
git stash list # 查看所有暂存
git stash show -p stash@{0} # 查看第一次暂存
git stash apply stash@{0} # 应用第一次暂存
git stash drop
git stash pop
git show-branch # 图示当前分支历史
git show-branch --all # 图示所有分支历史
git tag # 显示已存在的tag
git tag -a v2.0 -m 'xxx' # 增加v2.0的tag
git tag v1.0 # 新建标签v1.0
git tag v1.0 25656e2 # 给commit id 为25656e2的历史版本打标签
git tag -d v0.9 # 删除本地
git whatchanged # 显示提交历史对应的文件修改