作者介绍了自己使用 Git 的方式，包括以下方面：

• 始终使用 Git：任何项目，无论大小、是否完成，都在 Git 仓库中，git init是在新文件夹中做的第一件事。
• CLI 操作为主：99.9%的时间在命令行（CLI）使用 Git，从未使用过 Git 的图形用户界面（GUI）。
• 常用 Git 别名：在~/.gitconfig和.zshrc中设置了常用的 Git 别名，如gst（git status）、gc（git commit）等，频繁使用这些别名。
• 使用 Git 日志函数：每天使用~/.githelpers中的pretty_git_log函数一百次，从 Gary Bernhardt 的 screencast 中获取，未做修改。
• 关注提交内容：根据提交到仓库主分支的内容来决定是否提交、如何提交，要做到易理解、可回滚、可二分查找。
• 尽早频繁提交：将提交视为视频游戏中的快速保存，遇到问题或完成工作就提交，随时可重新整理、合并提交。
• 重视合并请求（PR）：尽早打开 PR，保持 PR 较小且尽快合并，若 PR 审核按提交进行则注重提交，若按单改变审核则可添加“修复格式”等提交。
• PR 基于主分支：PR 基于主分支进行变基，不将主分支合并回自己的分支，交互式变基可整理提交便于审核。
• 注重提交消息：关心提交消息的撰写，若合并时 squash 提交则 PR 描述为提交消息，重要的是提交背后的“为什么”，有时添加前缀使消息简短，必要时在消息中引用其他提交和 PR。
• 配对时的操作：配对时在提交消息中添加“Co-authored-by”，根据不同场景使用不同的提交消息。
• 审核前的准备：请求审核前先自己查看 PR 的差异，CI 未通过时一般不请求审核，审核他人代码时运行测试确保实际效果。
• 处理分支策略：在分支工作时，根据要在另一个分支进行的更改大小和工作目录中的未提交内容选择不同的分支策略，如git add -p && git stash等。
• 不太在意分支名称：只要分支名称有一定意义即可，通过 GitHub UI 查看当前打开的 PR 概览。
• 使用 GitHub CLI：使用gh pr create -w创建 PR，使用gh在打开的 PR 分支间切换，有两个方便的别名但不常使用。
• 解决 Git 问题：多年未因 Git 问题删除和重新克隆仓库，通过git reflog、git reset等解决大部分问题。

作者最后表示自己在不同情境下使用 Git 并非完全一致，会根据具体情况调整。