文章目录
git blame查看单个文件修改历史
-
git blame:查看文件中每行最后的修改作者
git blame your_file
-
git log和git show结合
- git log:查看文件的修改历史
- git show:查看特定提交的修改
git log your_file # 查看文件的提交历史 git log -p your_file # 查看文件每次提交中的具体差异 git show hash_id:your_file # 查看某次提交中文件的差异
git blame your_file # 查看文件每一行最后修改的提交信息
git stash单个文件
-
git stash push命令
git stash push -m "your comment" your_file
-
git stash save命令
git stash save -- your_file "your comment"
git rebase命令
-
git rebase:变基到
-
通过两个图来说明过程
-
当执行rebase操作时,如上图
- 先提取feature分支和master分支的公共祖先节点B
- 从feature分支的B节点开始提取feature分支上的修改C和D
- 在master分支的最新节点M之后逐个应用修改C和D,变成C’和D’
- 处理冲突后,feature分支指向最新的D’分支
- 完成变基
-
注意:master分支的M节点不一定比feature分支的C和D老,变基后问题不好追溯
-
变基过程中产生冲突处理:处理完冲突文件后git add file
git rebase --continue # 继续变基过程,可能只应用了C还没处理D git rebase --abort # 放弃变基过程 git rebase --skip # 某个提交比如C不再需要,虽然冲突了,但可跳过该提交
git rebase -i master # 交互式方式排列或选择feature分支的一系列提交 # 打开的交互界面长这样:C/D提交都要,放弃E提交,条件C/D提交顺序 pick D some commit message pick C another commit message drop E yet another commit message # 如果确实要应用某几个commit,可以使用git cherry-pick命令
git rebase和git merge区别
- git rebase: 提交记录比较简洁,但无法区分feature分支最早是从哪拉出来的,而且和master分支的修改先后顺序发生了变化,出问题不好追溯
- git merge:虽然会多出一条提交记录,但便于问题追溯
- git rebase不太推荐使用
git cherry-pick命令
-
git cherry-pick:希望合并另一个分支的某几次commit,而不希望merge另一个分支
git cherry-pick commit_id # 应用某个commit git cherry-pick start_commit_id^..end_commit_id # 应用从start-end中间的所有commit git cherry-pick commit_id_1 commit_id_2 # 应用多个提交 git cherry-pick -x commit_id # 保留原始的提交信息 git cherry-pick --continue # 解决冲突后继续cherry-pick git cherry-pick --abort # 放弃cherry-pick,恢复到操作前的状态 git cherry-pick --skip # 即使冲突,放弃本次cherry-pick git cherry-pick --quit # 没有完成cherry-pick的序列都会被停止
-
git rebase -i 和 git cherry-pick
- git rebase -i:会修改提交历史,可能不利于问题追溯
- git cherry-pick:只挑选特定的几个commit,不改变现有的提交历史
git reflog和git log区别
-
git log
- 用于显示分支或文件的提交历史,方便查看提交的详细信息
- 回顾分支的开发历史或者查看特定提交的详细信息时有用
-
git reflog
- 用于查看分支的所有操作记录(切换,提交,reset等)
- 关注的是分支的变化而不是具体的提交信息
- 对于找回/恢复分支的某次提交特别有用
[参考文章]
[1]. git rebase的原理和优缺点
[2]. git rebase图解
[3]. 文心一言和kimi模型
created by shuaixio, 2024.08.24