Git常用指令

Git 常用50个核心操作命令(附详细说明)

以下按仓库初始化与配置、文件状态与暂存、提交与日志、分支管理、远程仓库、合并与变基、标签、撤销与回滚、LFS大文件、高级实用十大场景分类,覆盖开发全流程高频操作,命令简洁且标注适用场景,新手也能直接套用。

一、仓库初始化与全局配置(5个)

主要用于首次使用Git的环境配置、本地仓库创建,配置后全局生效(除非单独修改仓库配置)。

  1. git config --global user.name "你的用户名"
    配置Git全局提交用户名(GitHub/GitLab的用户名,必填)。
  2. git config --global user.email "你的邮箱"
    配置Git全局提交邮箱(与GitHub/GitLab绑定的邮箱,必填)。
  3. git config --global --list
    查看Git所有全局配置信息,验证用户名、邮箱是否配置正确。
  4. git init
    在当前文件夹初始化本地Git仓库,生成隐藏的.git目录(仓库核心文件)。
  5. git clone <仓库地址>
    克隆远程GitHub/GitLab仓库到本地,包含所有文件、分支和提交历史(支持HTTPS/SSH地址)。

二、文件状态查看与暂存(7个)

Git核心工作流(工作区→暂存区→本地仓库)的关键操作,高频使用于开发中文件管理。
6. git status
查看工作区文件状态:未跟踪(新文件)、已修改、已暂存、干净(无修改),带颜色标注更清晰。
7. git add <文件/文件夹路径>
将指定文件/文件夹从工作区提交到暂存区,是提交前的必要步骤(例:git add index.htmlgit add src/)。
8. git add .
快捷命令:将工作区所有未跟踪+已修改的文件一次性提交到暂存区(最常用,开发中高频)。
9. git add -u
将工作区已跟踪(曾提交过) 的修改文件提交到暂存区,忽略新创建的未跟踪文件。
10. git reset HEAD <文件路径>
将指定文件从暂存区回滚到工作区,取消暂存(例:误add文件时使用,保留文件修改)。
11. git reset HEAD .
一次性将暂存区所有文件回滚到工作区,取消全部暂存操作。
12. git clean -f
删除工作区未跟踪的新文件(无法恢复,慎用),仅删除Git未记录的文件,保留已跟踪的修改文件。

三、提交与提交日志(8个)

将暂存区文件提交到本地仓库,及查看/筛选提交历史,是版本追溯的核心操作。
13. git commit -m "提交备注信息"
将暂存区所有文件提交到本地Git仓库-m后必须跟清晰的备注(例:git commit -m "feat: 新增登录功能")。
14. git commit -am "提交备注信息"
快捷命令:跳过暂存区,直接将已跟踪的修改文件提交到本地仓库(新文件需先git add,无法直接用)。
15. git commit --amend
修正最后一次提交:若漏加文件/备注写错,执行后进入编辑模式,修改备注或补充暂存文件后保存,覆盖最后一次提交记录(未推送到远程时使用)。
16. git log
查看本地仓库完整提交历史:包含提交ID、作者、时间、提交备注,按时间倒序排列。
17. git log --oneline
简洁版提交日志:仅显示7位短提交ID+提交备注,屏幕占比小,最常用的日志查看方式。
18. git log --graph
图形化显示提交历史,清晰展示分支合并、分叉的关系(多分支开发时必备)。
19. git log --author="用户名/邮箱"
筛选指定作者的提交记录,快速查找某个人的开发记录(例:git log --author="[email protected]")。
20. git log --since="2026-02-01"
筛选指定时间后的提交记录,也可写相对时间(例:git log --since="3 days ago" 查看3天内的提交)。

四、分支管理(10个)

Git最核心的功能,多分支开发(主分支、开发分支、功能分支、修复分支)的必备操作,覆盖分支创建、切换、删除、查看全流程。
21. git branch
查看本地所有分支,当前所在分支前带*标记。
22. git branch -a
查看本地+远程所有分支,远程分支以remotes/origin/开头。
23. git branch <分支名>
创建新分支(基于当前所在分支的最新提交,仅本地创建,未切换)。
24. git checkout <分支名>
切换到指定本地分支,切换前需保证工作区无未提交的修改(避免冲突)。
25. git checkout -b <分支名>
快捷命令:创建新分支并立即切换到该分支(开发中最常用,例:git checkout -b feat/pay)。
26. git checkout -b <本地分支名> origin/<远程分支名>
从远程分支拉取并创建本地对应分支(例:拉取远程dev分支:git checkout -b dev origin/dev)。
27. git branch -m <旧分支名> <新分支名>
重命名本地分支(例:git branch -m feat/pay feat/wechat-pay)。
28. git branch -d <分支名>
删除本地已合并的分支(安全删除,未合并则提示失败)。
29. git branch -D <分支名>
强制删除本地分支(无论是否合并,慎用,例:删除废弃的功能分支)。
30. git push origin --delete <远程分支名>
删除远程仓库的分支(例:git push origin --delete feat/pay,删除后团队成员需拉取最新远程信息)。

五、远程仓库操作(6个)

本地仓库与远程仓库(GitHub/GitLab/Gitee)的关联、同步操作,开发中每次推送/拉取前必用。
31. git remote add origin <远程仓库地址>
将本地仓库关联到远程仓库,origin是远程仓库的默认别名(仅首次使用)。
32. git remote -v
查看本地已关联的远程仓库信息,显示fetch(拉取)和push(推送)的地址,验证是否关联正确。
33. git remote rename <旧别名> <新别名>
修改远程仓库的别名(例:git remote rename origin github)。
34. git remote remove <别名>
解除本地与指定远程仓库的关联(例:git remote remove origin)。
35. git fetch origin
从远程仓库拉取所有分支的最新提交记录(仅同步历史,不合并到本地当前分支,安全无冲突)。
36. git pull origin <分支名>
快捷命令:git fetch + git merge,从远程指定分支拉取最新代码并合并到本地当前分支(例:git pull origin main,开发中同步远程代码最常用)。

六、合并与变基(4个)

多分支开发完成后,将功能分支代码合并到主分支/开发分支的核心操作,两种方式适用于不同场景。
37. git merge <分支名>
将指定分支的代码合并到当前所在分支(例:在main分支执行git merge feat/pay,将支付功能合并到主分支),会生成一个新的合并提交记录。
38. git merge --no-ff <分支名>
禁用快速合并(no fast forward),无论分支是否线性,都强制生成合并提交记录,保留分支合并历史(团队开发推荐,便于追溯)。
39. git rebase <分支名>
变基操作:将当前分支的所有提交,移植到指定分支的最新提交之后(例:在feat/pay分支执行git rebase main,将支付分支基于主分支最新代码重新构建),使提交历史更线性、整洁。
40. git rebase --abort
变基过程中出现冲突时,放弃变基,恢复到变基前的状态(冲突无法解决时使用)。

七、标签管理(3个)

用于标记项目的版本节点(如v1.0.0、v2.1.1),便于版本发布和回滚,标签是提交记录的快照,不可修改。
41. git tag <标签名>
为当前最新提交创建轻量标签(仅包含标签名,无备注,例:git tag v1.0.0)。
42. git tag -a <标签名> -m "标签备注"
创建带注释的标签(推荐,包含作者、时间、备注,例:git tag -a v1.0.0 -m "v1.0.0 正式版:实现核心功能")。
43. git push origin <标签名>
将本地标签推送到远程仓库(标签默认不随git push推送,需手动执行,例:git push origin v1.0.0);推送所有标签:git push origin --tags

八、撤销与回滚(5个)

开发中误操作(误提交、误修改、误删除)的补救操作,覆盖工作区、暂存区、本地仓库三个层级,按需选择。
44. git checkout -- <文件路径>
放弃工作区对指定文件的所有修改,恢复到最近一次提交/暂存的状态(无法恢复,慎用,例:git checkout -- index.html)。
45. git reset --hard <提交ID>
强制将本地仓库、暂存区、工作区全部回滚到指定提交ID的状态(所有后续提交记录被覆盖,未推送到远程时使用,慎用)。
46. git reset --soft <提交ID>
轻量回滚:仅将本地仓库回滚到指定提交ID,暂存区和工作区的修改保留(适用于回滚后需重新提交的场景)。
47. git restore <文件路径>
Git 2.23+新增命令,替代git checkout --,放弃工作区指定文件的修改(更语义化,例:git restore src/App.vue)。
48. git restore --staged <文件路径>
Git 2.23+新增命令,替代git reset HEAD,将指定文件从暂存区回滚到工作区(取消暂存,例:git restore --staged package.json)。

九、LFS大文件管理(2个)

针对GitHub单文件25MB限制的解决方案,配套之前的大文件上传教程,高频使用。
49. git lfs track <文件/后缀>
用Git LFS追踪大文件(例:git lfs track "*.zip"git lfs track "data/dataset.csv"),自动生成.gitattributes文件。
50. git lfs ls-files
查看当前仓库中被Git LFS追踪的所有大文件,验证是否追踪成功。

额外高频实用命令(补充,超50个福利)

  • git push:将本地仓库提交推送到远程关联分支(已用git push -u origin main关联后,直接使用)。
  • git push -u origin <分支名>:首次推送本地分支到远程,并建立本地与远程分支的关联(后续直接git push)。
  • git gc:清理Git仓库的无用缓存、过期对象,优化仓库体积(仓库过大时执行)。
  • git diff:查看工作区与暂存区之间的文件修改差异(显示具体修改的代码行)。
  • git diff <提交ID1> <提交ID2>:查看两个提交之间的代码修改差异,便于代码审查。

核心使用原则

  1. 多分支开发规范:主分支(main/master)仅用于发布,开发在dev分支,新功能/修复单独建分支(feat/xxx、fix/xxx);
  2. 提交前必看:git status确认文件状态,避免误提交无关文件;
  3. 同步远程前必做:git pull拉取最新代码,避免推送时冲突;
  4. 危险操作慎用:git reset --hardgit branch -Dgit clean -f,执行前确认工作区已备份重要修改。

以上命令覆盖99%的日常开发、团队协作场景,建议收藏备用,常用几次后即可形成肌肉记忆~

Read more

【Spring】Spring事务和事务传播机制

【Spring】Spring事务和事务传播机制

🎬 那我掉的头发算什么:个人主页 🔥 个人专栏: 《javaSE》《数据结构》《数据库》《javaEE》 ⛺️待到苦尽甘来日 文章目录 * 事务三连 * 什么是事务 * 为什么要有事务 * 事务的操作 * Spring中事务的实现 * 准备工作 * Spring编程事务 * Spring 声明式事务 @Transactional * @Transactional详解 * rollbackFor * 事务隔离级别 * Mysql事务隔离级别 * Spring事务隔离级别 * Spring事务传播机制 * 总结 事务三连 什么是事务 事务是⼀组操作的集合, 是⼀个不可分割的操作. 事务会把所有的操作作为⼀个整体, ⼀起向数据库提交或者是撤销操作请求. 所以这组操作要么同时成功, 要么同时失败. 为什么要有事务 我们在进行程序开发时,也会有事务的需求。 比如转账操作: 第一步:A 账户 -100 元。 第二步:B 账户 +100

By Ne0inhk
掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

🔥我的主页:九转苍翎⭐️个人专栏:《Java SE》《Java集合框架系统精讲》《MySQL高手之路:从基础到高阶》《计算机网络》《Java工程师核心能力体系构建》《RabbitMQ理论与实践》天行健,君子以自强不息。 1.事务 AMQP(高级消息队列协议)实现了事务机制,主要用于确保消息的原子性发布和确认。换言之,它允许你将多个操作(如发送消息、确认消息)绑定在一起,要么全部成功,要么全部失败 发送消息 @RestController@RequestMapping("/producer")publicclassProducerController{@Resource(name ="transRabbitTemplate")privateRabbitTemplate transRabbitTemplate;@Transactional@RequestMapping("/trans")publicStringtrans(){ transRabbitTemplate.convertAndSend(""

By Ne0inhk
Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构

Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 lyform 适配鸿蒙 HarmonyOS 实战:响应式表单引擎,构建多维校验与状态驱动的交互反馈架构 前言 在鸿蒙(OpenHarmony)生态迈向政务办公、智慧医疗及大型企业级管理系统等重定义表单交互的背景下,如何实现高度解耦的表单校验逻辑、提升超长表单的录入效率,已成为决定应用用户体验(UX)的“核心命门”。在鸿蒙设备这类强调分布式协同与流畅性能(Fluidity)的终端上,如果表单逻辑依然堆砌在 UI 层的 setState 之中,由于由于复杂的字段联级校验与高频的视图重绘,极易由于由于主线程阻塞导致虚拟键盘弹出时的严重掉帧。 我们需要一种能够实现逻辑与视图彻底分离、支持基于流(Stream)的状态监控且具备严密规则校验能力的表单治理框架。 lyform 为 Flutter 开发者引入了基于 BLoC 模式的高阶表单管理方案。它将每一个输入字段抽象为独立的 InputBloc,并由 FormBloc 进行全局状态统筹。在适配到

By Ne0inhk
从“多库并存”到“一库多能”:聊聊金仓KingbaseES的融合架构实践

从“多库并存”到“一库多能”:聊聊金仓KingbaseES的融合架构实践

干数据库这行快十年了,亲眼见证了企业数据架构的变迁。早年做项目,最头疼的就是“数据竖井”——交易系统用Oracle,用户行为日志扔到MongoDB,时序监控数据塞进InfluxDB,图谱关系又得搞个Neo4j。每个库都有自己的语法、管理工具和运维体系,开发团队整天在不同数据库之间做数据同步和格式转换,数据一致性难保证,系统复杂度却直线上升。 这几年“融合数据库”的概念越来越热,但很多厂商的理解还停留在“多模接口”层面。直到去年深度参与了某城商行的核心系统分布式改造项目,用金仓数据库KingbaseES 完整跑了一轮,才算真正体会到什么是“一库多能”的设计哲学。今天就跟大家聊聊我们的实践心得,特别是金仓在这方面的独特思考。 一、为什么是“一库多能”,不是“多库拼装”? 先看个真实场景。我们那个银行客户要做实时反欺诈,需要在一个查询里关联:用户账户信息(结构化)、近期交易流水(带时序特征)、设备指纹(JSON文档)、社交关系图谱(判断是否团伙),以及地理位置信息(空间数据)。如果按传统思路,至少要跨5个不同数据库做联合查询,光数据同步延迟就够受的,更别说保证事务一致性了。

By Ne0inhk