1. Git在开发工作中的定位与使用全貌每天敲键盘几乎都离不开Git。无论是个人项目的版本回溯还是团队多人协作的代码合并Git都已经成了软件开发的基础设施甚至可以说不会Git就意味着很难真正参与到一个团队的开发节奏里。很多同学刚接触Git时觉得它难原因不在于命令多而在于脑子里没有一个完整的模型。你如果只看一个个零散的指令比如add、commit、push永远搞不清它们之间是什么关系。反过来一旦理解了Git的数据流——工作区、暂存区、本地仓库、远程仓库这四个层面的信息流转你会发现那些看似复杂的命令其实都是在操作这几个“盒子”之间的移动和同步。这篇内容我想从实际开发的角度把日常最常用的Git操作串一遍怎么装、怎么配、怎么拉代码、怎么提交、怎么做分支合并、怎么在IDEA里完成整套操作再把高频的失败场景拉出来逐个排查。不追求把所有冷门参数讲全重点是让读的人能够照着操作解决真实工作中的问题。1.1 为什么日常开发绕不开GitGit是分布式版本控制系统这意味着每个开发者的本地都有一份完整的代码历史而不是像SVN那样只有中央仓库才存有全量记录。这个设计的直接好处是在没有网络的情况下你依然可以正常提交代码、查看历史、创建分支等到联网时再同步到远程。日常开发中遇到的环境切换、功能分支、代码评审、发布回滚都是靠这套机制支撑的。说得更直白一点Git解决的是三个核心问题一是历史记录你看得到每一次改动是谁、什么时候、改了什么二是并行协作多个人可以在不同分支上开发不同功能而不互相踩踏三是版本回溯线上出了紧急问题可以快速切回上一个稳定版本。这些都是软件工程里的刚需不是某个团队的习惯而是整个行业协作的基础方式。理解了这三点再看后面所有命令和操作就不会觉得是死记硬背了。比如分支合并本质就是把两个并行开发的历史重新汇合比如冲突解决本质上是因为两边改了同一块内容Git不知道听谁的需要人来裁决。1.2 日常开发会覆盖的核心使用路径我会把整套内容按照实际开发中的时间线来组织这样更贴近真实场景。第一步是工具准备包括Git安装和基本配置这是所有操作的前提。第二步是认证打通主要是SSH密钥的生成和配置解决本地与远程仓库的安全连接问题。第三步是日常操作包括拉取项目、提交代码、推送代码、同步更新。第四步是分支操作包括创建分支、切换分支、合并分支以及处理合并冲突。第五步是IDE集成重点讲IDEA里如何拉取Git项目、提交、解决冲突因为很多同学日常工作都是在IDE里完成的。最后是问题排查把push失败、ssh认证失败、误提交回滚等高频问题逐个拆开来看。这其实就是一篇“从安装到日常开发能独立干活”的完整路径。下面我们就按这个顺序一步步来。2. 从下载到跑通Git安装与基础配置Git的安装本身不复杂但有不少细节会影响后续使用体验比如Windows上的换行符设置、终端的选择、以及配置全局身份信息的必要性。这些如果没处理好后面提交代码时会遇到各种莫名其妙的问题。2.1 不同平台的安装步骤与版本选择先看Windows平台。目前主流的安装方式是直接下载Git for Windows的官方安装包。下载地址在Git官网选择对应系统的64位版本即可。安装过程中有几个界面需要留意。一是选择安装路径时尽量使用默认路径避免中文目录或者带空格的目录否则某些终端工具和插件在调用Git时可能解析出错。二是“Select Components”页面建议勾选“Git Bash Here”和“Git GUI Here”这样在文件夹右键菜单里就能直接打开Git Bash非常方便。三是默认编辑器选择如果装了VS Code可以直接选VS Code没有的话就用默认的Vim但要注意Vim的退出方式Esc后输入:wq很多新手在Vim里卡住就是因为不知道怎么保存退出。还有一个关键选项是“Adjusting your PATH environment”。默认选项是“Git from the command line and also from 3rd-party software”这个选项会把Git加入系统PATH意思是你在CMD、PowerShell里直接输入git命令也能识别。如果你希望某些第三方工具比如IDEA、VS Code能正常调用Git选择这个默认项是最稳妥的。macOS平台的话有两种常见方式一种是直接用官方安装包下载后双击安装另一种是用Homebrew安装命令是brew install git。个人建议用Homebrew因为后续升级方便输入brew upgrade git就行了。Linux平台则根据发行版不同使用apt install git或yum install git不过大多数Linux发行版自带的Git版本已经足够日常使用。安装完成的验证方式是在终端执行git --version能看到类似git version 2.40.0.windows.1的输出就说明安装成功了。我见过很多人在安装阶段跳过PATH配置结果在IDEA里找不到Git这种情况不用重装手动把Git的安装目录加到系统环境变量里即可。另外提醒一句Git版本不要选太旧的。老版本对新的SSH算法支持不够比如Ed25519算法需要Git 2.29版本以上才能完整支持。如果遇到SSH密钥生成后远程仓库不认的情况先检查一下Git版本和SSH版本可能问题出在版本太老。2.2 安装后的第一件事身份配置与换行符策略装好Git之后第一件要做的事不是clone代码而是配置用户名和邮箱。这个信息会写进每次提交里也是代码评审和问题追溯的依据。git config --global user.name yourname git config --global user.email youremailexample.com--global表示全局生效也就是说这台机器上所有仓库都会默认使用这个身份。如果你有几个不同的身份比如工作用和私人用那就不加--global在每个仓库里单独配置本地身份。这里特别想说一下很多人把user.name和user.email当成“登录账号”来填这是误解。它纯粹是提交记录里的签名信息跟远程仓库的登录认证没有任何关系。远程认证走的是SSH key或者HTTPS凭证不是这个。所以用户名可以填中文邮箱可以填任何邮箱只是团队协作时要统一规范方便认人。接下来是换行符配置这是Windows用户最容易踩的坑。Windows系统里换行符是CRLF回车换行而Linux/macOS里是LF换行。如果不做统一处理同一个文件在不同系统间切换时Git会检测到大量“假改动”——明明内容没变但因为换行符不同diff里全是红红绿绿。Git提供了core.autocrlf参数来处理这个差异。在Windows上我建议设置为truegit config --global core.autocrlf true这样做的效果是提交到仓库时自动把CRLF转成LF检出到本地时自动把LF转成CRLF。也就是说仓库里统一存LFWindows本地工作区是CRLF。对于macOS或Linux则设置git config --global core.autocrlf input意思是提交时转成LF检出时不转换。团队协作时这个参数通常应该在.gitattributes文件里统一约定而不是靠每个人自己配置。项目根目录下的.gitattributes文件可以声明特定文件类型的换行符规则比如* textauto *.sh text eollf *.bat text eolcrlf这样即使团队成员分布在不同的操作系统上也能保证仓库里和检出后的文件格式一致避免无谓的冲突和污染。2.3 SSH密钥配置让本地和远程仓库建立信任关系连接远程仓库有两种主流方式HTTPS和SSH。HTTPS方式第一次推送时要求输入账号密码现在各大平台通常要求使用Personal Access Token个人访问令牌来替代密码对于不熟悉令牌机制的同学来说操作起来比较麻烦。SSH方式则是一次性配置密钥配对成功后以后所有git操作都不需要再输入凭证日常用起来最顺手。SSH认证的原理也不算复杂本地生成一对密钥包括私钥和公钥。私钥保存在自己电脑上公钥上传到Git服务商比如GitHub、GitLab、Gitee的账号设置里。连接时服务商用公钥来验证你手里的私钥验证通过就放行。生成密钥的命令是ssh-keygen -t ed25519 -C youremailexample.com-t ed25519指使用Ed25519加密算法相比传统RSA算法它的密钥更短、安全性更高、生成速度也更快。-C参数后面通常填你的邮箱用来作为这个密钥的注释标识方便在企业里管理很多密钥时区分用途。生成过程中会提示你设置密钥文件的保存路径默认在~/.ssh/id_ed25519一般直接回车用默认路径就行。然后会提示输入passphrase口令这个口令用于保护私钥文件建议设置一个丢失电脑时多一层保障。设置了口令后每次使用私钥时都需要输入口令如果觉得麻烦可以后续用ssh-add将密钥添加到ssh-agent里来免输口令。密钥生成后在~/.ssh目录下会有两个文件id_ed25519是私钥绝不要泄露id_ed25519.pub是公钥可以安全地上传到远程平台。查看公钥内容的命令是cat ~/.ssh/id_ed25519.pub把输出的内容整段复制然后到Git托管平台的“SSH Keys”设置页面里粘贴保存。不同平台的入口位置有差异但通常都在“设置 / SSH and GPG keys”这类菜单下面。配置完成后验证连接ssh -T gitgithub.com如果是GitHub成功会输出类似Hi username! Youve successfully authenticated, but GitHub does not provide shell access.的提示。看到这个就说明SSH通路已经建立可以正常clone和push了。SSH这种方式虽然配置步骤比HTTPS多但好处是长期稳定。输一次密钥后面好几年都不用再管认证的事。对于天天跟代码仓库打交道的开发者来说这个花的时间非常值。3. 日常高频命令与工作流解读配置做完接下来是真正每天都用得到的命令。很多人刚学Git时只记住了一句git add .和git commit -m xxx然后就开始打卡式提交。这种用法能用但出问题时往往不知道怎么处理。所以我还是想花些篇幅把日常操作背后的机制讲透。3.1 拉取项目与日常提交流程clone、add、commit、push先从拉取项目说起。克隆一个远程仓库到本地命令非常简单git clone gitgithub.com:user/repo.git拉取时要注意URL的选择。如果是自己公司的项目一般都有统一的代码托管平台登录后在项目首页复制SSH地址然后执行clone。克隆完成后本地会自动建立master或main分支并与远程的对应分支建立跟踪关系。进入项目目录后日常开发的循环主要是四步改代码、查看变更、暂存、提交、推送。改完代码后先看当前工作区状态git status这个命令会列出当前分支、有改动的文件modified/untracked、以及暂存区的情况。我习惯每次提交前必看status确认没有改到不想改的文件。想具体看改了什么内容用git diff这个命令显示的是工作区与暂存区之间的差异。如果文件已经被git add了再执行git diff是看不到差异的需要用git diff --cached来看暂存区与上一次提交之间的差异。这个区别挺重要因为很多人以为“我已经add了为什么diff不显示”其实就是没搞清楚这个机制。暂存文件git add filename git add . # 添加所有改动git add的语义是把文件放入暂存区暂存区也叫索引index。为什么要多一个暂存区呢因为很多时候一次改动里可能包含了多个无关的修改比如修了一个bug顺便改了一处格式。通过git add选择性地暂存就能把不同的改动拆成多个提交每个提交只做一件事代码历史更清晰。提交到本地仓库git commit -m feat: add user login module提交信息这里我多讲一点。不要用“update”“修改”“111”这种毫无信息量的信息。团队协作时好的提交信息应该能让人不看代码就明白这次改动做了什么。目前行业比较流行的是Conventional Commits规范格式通常是feat: 新功能fix: 修复bugdocs: 文档变更style: 代码格式调整不影响逻辑refactor: 重构不改变外部行为test: 增加或调整测试比如fix: 修复登录接口在密码错误时返回500的问题这样的信息在回溯问题时价值非常高。很多项目还会基于提交信息自动生成changelog格式规范就更重要了。提交到本地后并没有同步到远程。这一步是pushgit push如果是首次推送新分支Git会提示你设置上游分支使用git push -u origin branch-name-u参数的意思是设置upstream跟踪关系以后在这个分支上直接执行git push或git pull就能自动对应到远程分支不需要再带参数。再说说拉取更新。很多人习惯直接git pull但pull其实是两步操作的合体先git fetch把远程的变更拉到本地跟踪分支再git merge把变更合并到当前分支。如果你本地没有未推送的提交直接git pull没问题。如果本地有提交我强烈建议使用git pull --rebase这个命令的意思是把本地未推送的提交变基到远程分支的最新提交之上得到的提交历史是一条直线没有多余的分叉和merge节点。相比直接mergerebase后的历史更干净也更方便review。后面我们会专门讨论rebase和merge的区别与选择。3.2 分支管理的日常操作从创建到切换分支是Git最强大的设计之一。开发一个新功能或者说修复一个bug时合理的操作是开一个独立的分支在这个分支里做改动做完再合并回主分支。这样主分支始终保持可用状态不会因为某个人改了一半代码就崩了。查看本地分支git branch查看所有分支包括远程分支git branch -a创建并切换到新分支git checkout -b feature/user-login这个命令是创建分支和切换分支两个操作的合并。分开写是git branch feature/user-login git checkout feature/user-login新版Git也提供了更直观的git switch命令git switch -c feature/user-login # 创建并切换 git switch master # 切换已有分支在日常操作上switch和checkout功能几乎一样只是语义更清晰符合直觉。如果你用的Git版本比较新用switch会更顺手。分支创建好后推送远程并建立跟踪关系git push -u origin feature/user-login之后团队的其他人就能看到这个分支可以拉取下来review或联调。关于分支命名团队里一般有约定俗成的规范比如feature/xxx表示功能分支bugfix/xxx表示修复分支release/xxx表示发布分支。命名规范的主要价值在于CI/CD流水线可以按分支模式自动触发不同环境的构建部署人看名字也能立刻知道这是一个什么类型的分支。切换分支时有个常见问题工作区还有未提交的改动。Git会阻止你切换分支提示Your local changes would be overwritten by checkout。这时候有几种选择把改动commit到当前分支或者git stash暂存起来改完回来再取回。git stash是日常开发非常高频率的命令后面会有专门小节说明。3.3 分支合并与冲突解决merge和rebase怎么选分支合并是多人协作中绕不开的环节。合入分支有两条主要路径merge合并和rebase变基。两者的作用都是把其他分支的提交整合到当前分支但最终的提交历史差别很大。先看merge。比如我在feature分支上开发完功能想合回mastergit checkout master git merge feature/user-loginmerge会生成一个“合并提交”merge commit这个提交有两个父提交历史中会出现一个分叉再汇合的结构。如果合并过程中没有冲突Git会自动生成合并提交无需干预。merge的好处是保留了真实的分支结构和开发过程看起来一目了然——这个分支从哪里分叉、在哪里汇合、改过什么。对于一些需要保留完整上下文的项目比如发布分支、长期维护分支merge是更稳妥的选择。再看rebasegit checkout feature/user-login git rebase master意思是把feature分支的提交依次“重放”到master的最新提交之后。重放之后feature分支的历史会变成一条直线没有分叉。这时再切回master执行git merge feature/user-loginGit会发现master可以直接快进fast-forward不需要生成合并提交历史会非常干净。rebase的问题也很明显它改写了提交历史。原来feature分支上的提交哈希会变因为提交的父节点变了。如果这个分支已经推送到远程并且被其他人拉了你再执行rebase下次push时就会被拒绝因为本地历史和远程历史发生了分叉相当于你在改写“公开历史”。这是git操作中的大忌。所以rebase通常只用于“尚未推送或只有自己一个人在用”的分支。日常团队协作中我个人比较推荐的方法是把功能分支合并回主分支时用merge保留上下文从主分支同步最新代码到自己正在开发的分支时用rebase保持功能分支线性且易于review。具体操作就是在主分支上先git fetch origin拉取最新然后切回功能分支执行git rebase origin/master。如果功能分支上已经有很多提交且长期没同步主分支这个rebase过程可能会需要处理多次冲突但一次处理完后续合回主分支时就非常顺畅。讲到冲突这是Git新手最怕的事情。冲突的根本原因是Git在两个分支上都能找到“同样的位置”做了不同的修改它不知道该听谁的。比如你和同事都在order_service.go这个文件里改动了同一个函数的同一行这就必然冲突。遇到冲突时Git会在工作区文件里插入冲突标记 HEAD // 当前分支的代码 // 待合并分支的代码 feature/user-login处理冲突的方式是手动编辑这个文件把需要的代码留下把、、这些标记行删掉。然后执行git add order_service.go git commit这样就完成了冲突解决。如果冲突太多或者你判断这次合并不合适想放弃合并执行git merge --abort如果是rebase过程中想放弃执行git rebase --abort这两个命令会恢复到合并/rebase开始之前的状态这也是为什么我建议合并前先把本地改动stash或提交好给自己留一个安全退路。关于冲突处理我想强调一个思路不要用编辑器盲目地选择左侧或右侧。真正要读懂两边的逻辑搞清楚为什么两边都会改这里。我见过不少人是看到冲突就选“取右侧”结果把别人的逻辑覆盖了后面又花大量时间排查。正确做法是用IDE的Merge工具把三方当前分支、目标分支、共同祖先的内容并排展示结合上下文做出判断。4. IDEA拉取Git项目从新建项目到提交全流程很多同学日常开发是在IDE里进行的IDEA是目前Java和Kotlin开发中最常用的工具它对Git的支持非常完善。其实在IDEA里操作Git和命令行本质上是一样的只是换了一层图形界面很多人用起来觉得不够熟悉反而更喜欢命令行。我个人的看法是两种方式互补在IDEA里做提交、看diff、解决冲突效率很高在命令行里做分支管理、批量操作更灵活。掌握两者日常开发会非常顺畅。4.1 用IDEA从远程仓库拉取新项目Get from VCS第一次在IDEA里接触Git项目最常见的场景是从公司代码仓库克隆一个新项目到本地。打开IDEA在欢迎页选择“Get from VCS”按钮译为从版本控制系统获取。这会打开一个对话框左侧选择版本库类型Git右侧输入远程仓库的URL。URL从代码托管平台的项目页面复制SSH地址形如gitgitlab.xxx.com:group/project.gitHTTPS地址形如https://gitlab.xxx.com/group/project.git。输入URL后选择本地保存的目录点击Clone按钮。IDEA会调用Git可执行文件执行clone操作这一步会触发SSH认证。如果你在配置SSH密钥时已经通过ssh -T验证过这里一般会直接成功不会弹出任何输入框。如果失败回到终端检查密钥配置IDEA只是把错误信息带出来本质问题还是出在认证链路上。克隆完成后IDEA会自动打开项目并索引所有文件。这时候右下角可以看到当前所在分支比如master或main。如果你在克隆时没有选择分支默认会克隆远程HEAD指向的分支其他分支通过IDEA的Branches菜单切换。还有一个常见需求是团队里新开了develop长期开发分支你希望把本地分支指向它。在IDEA里打开“Git”菜单点击“Branches”在“Remote Branches”列表里选择目标远程分支选择“Checkout as new local branch”输入本地分支名称IDEA就会建立本地分支并自动设置跟踪关系。对没怎么接触过IDE版本控制的同学我想多说一句IDEA里的Git操作其实都是在你项目目录下执行git命令你在IDEA里“拉取、切分支、提交”本质上和命令行没有区别只是图形化后更直观。所以千万不要觉得“会IDEA就不会命令行”是分成两派它们是同一个东西的两种交互方式。4.2 提交与分支管理的图形化操作日常提交代码时IDEA的流程是这样的。在你修改完代码后IDEA右侧会出现一个Commit标签页如果没有通过Alt9快捷键呼出或者点左下角的Commit图标。这个面板会列出所有有改动的文件每个文件旁边有checkbox你可以勾选要提交的文件。面板下方是Commit Message输入框填写提交信息后点击“Commit”或“Commit and Push”按钮。这里我特别推荐勾选“Commit”面板右上角的“Analyze code”选项它在提交前会自动检查代码问题包括编译错误和常见的lint问题。虽然会花几秒钟但能帮你在提交前拦住一些低级错误避免污染仓库历史。提交后如果要推送到远程点击“Push”按钮或者提交时直接选择“Commit and Push”。Push面板会显示将要推送的提交细节确认无误后点击Push。拉取远程更新时使用“Git”菜单中的“Pull”或快捷键CtrlT。IDEA默认的pull操作等价于git pull如果你设置了pull.rebase为true它就会执行git pull --rebase。在IDEA里也可以在“Git → Pull”对话框里选择合并策略默认是merge也可以选rebase。分支切换在IDEA里同样方便点击右下角的状态栏分支名称弹出Branches菜单选择Local Branches下的分支执行Checkout即可。如果你当前工作区有未提交的改动IDEA和命令行一样会阻止切换但它会弹窗询问你是否暂存改动Shelve/Stash选择暂存Shelve Changes后可以安全切换切回来再恢复。查看提交历史使用“Git”菜单中的“Show History”或右键点击项目文件选择“Git → Show History”。历史面板里可以看到每次提交的作者、时间、提交信息、改了哪些文件。双击某个提交还能看到完整的diff。你在代码里看到一行有疑问时可以用git blame类操作查看这一行是谁在哪个提交里引入的。IDEA里的右键菜单“Annotate”就是这个功能会用颜色标注每一行最近的提交信息这个在排查问题时特别实用。4.3 IDEA里解决冲突的展示Merge Dialog在IDEA里执行Pull或合并分支遇到冲突时弹窗会比命令行友好得多。它会列出冲突文件列表每个文件有三种处理方式选择左侧当前分支、选择右侧合入分支、手动合并。如果冲突的代码确实只需要某一方直接选择即可。但大多数冲突都不是二选一那么简单需要手动合并。点击文件进入IDEA的Merge Revisions对话框界面是这样的左中右三栏左侧是当前分支的内容右侧是待合入分支的内容中间是合并结果。同时在底部会有一个“Conflicts”列表逐个显示冲突块。进入Merge对话框后对每个冲突块你可以点击左栏或右栏的箭头把某一方的内容应用到合并结果中也可以在中间结果区域直接手动编辑。处理完所有冲突块后点击“Apply”完成合并。IDEA会把文件标记为已解决并在提交面板里显示为Merged状态等待你提交合并结果。我个人觉得IDEA的Merge对话框在解决“两边改的是同一函数不同部分”这类不太复杂的冲突时效率很高你不需要在源代码里找标记直接在界面里点选就行。对于很复杂的冲突我会先用这个工具理清三方差异再配合上下文逻辑手动调整。一个额外的提醒是合并完成后必须执行一次编译和测试确保合入后的代码在功能上没有问题再提交合并结果。很多线上事故都是“冲突时二选一选错了”根源就在于只解决语法冲突没有验证逻辑正确性。5. 高频问题与排错速查用了几年Git会遇到不少重复率极高的问题。这些问题并不难但如果没人指路第一次碰到时确实会卡住很久。我把日常开发中最常见的几个整理成速查重点是排查思路而不只是给一个答案。5.1 ssh认证失败的完整排查流程从公钥到known_hosts“ssh认证失败”可以算是我在团队里被问最多的Git问题之一。报错信息五花八门常见的有Permission denied (publickey)、Could not read from remote repository、ssh: connect to host gitlab.com port 22: Connection refused等等。遇到这些问题先别急着重装Git按顺序排查第一步看你本地是否生成了密钥文件ls ~/.ssh/正常情况下能看到id_ed25519和id_ed25519.pub两个文件。如果.ssh目录不存在说明你并没有生成过密钥回到2.3节执行ssh-keygen生成一对。第二步看你本地是否加载了私钥ssh-add -l这行命令会列出当前ssh-agent中加载的私钥指纹。如果提示The agent has no identities说明私钥没有被加载。执行eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519如果生成密钥时设置了passphrase这一步会要求输入。输入正确后私钥就正式进入ssh-agent了。第三步验证与远程的连接ssh -T gitgithub.com换成你的代码托管平台域名。看到输出的欢迎信息说明连接没问题。如果仍然报Permission denied (publickey)需要确认你公钥是否已经加到远程平台。把cat ~/.ssh/id_ed25519.pub输出的内容复制到远程平台的SSH Keys设置页注意是添加公钥不是私钥。第四步检查known_hosts问题。如果你之前连接过同一台服务器之后服务器端的系统重装或密钥更新SSH会报Host key verification failed或REMOTE HOST IDENTIFICATION HAS CHANGED。处理办法是把之前的记录从known_hosts里删掉ssh-keygen -R gitlab.com然后重新执行ssh -T连接会提示确认主机指纹输入yes即可。还有一个容易被忽略的点如果远程URL写的是HTTPS地址而不是SSH地址也会导致认证失败因为SSH密钥不会用于HTTPS认证。检查远程仓库地址git remote -v如果要改成SSH地址git remote set-url origin gitgithub.com:user/repo.git这块整体上不复杂核心思路是本地有没有密钥、私钥有没有被加载、公钥有没有被远程识别、连接的地址是不是对的。按这个顺序排查90%以上的ssh认证问题都能定位。5.2 push被拒绝的常见原因与应对git push被拒绝这个问题几乎每个开发都遇到过。不同报错代表不同原因我按频率排一下。最常见的是! [rejected] master - master (non-fast-forward)。原因是远程分支上有你本地没有的提交你直接pushGit发现你的历史落后于远程为了安全起见拒绝推送免得覆盖别人的提交。正确的处理方式是先同步远程代码到本地git pull --rebase origin masterrebase会把本地未推送的提交“挪”到远程最新提交后面然后再执行git push就能成功。这里我建议用rebase而不是merge来同步原因前面说过rebase之后历史是线性的不会有冗余的merge节点。第二种情况是权限不足报错形如remote: Permission to user/repo.git denied或HTTP Basic: Access denied。这是远程仓库不允许你对目标分支执行push操作。排查点有两个一是当前SSH密钥或HTTPS凭证对应的账号是否在项目里有写权限二是分支是否受到保护Protected branch。很多团队的master/main分支都开启了保护不允许普通成员直接push必须走Merge Request合入。第三种情况是提交体积过大。Git默认单次push的文件体积限制通常为100MB如果你提交了一个巨大的二进制文件push时会报remote: fatal: pack exceeds maximum allowed size。这时候的处理思路是如果这个文件还不确定要不要保留可以用git rm --cached把它从暂存区移除并在.gitignore里忽略它如果确实需要保留大文件应该使用Git LFSLarge File Storage管理。push被拒绝还有个隐蔽原因本地分支和远程分支的名字不一致。比如你在本地建的master分支远程叫main直接push时Git会拒绝或者创建新分支这时手动指定git push origin HEAD:main或者用-u明确上游分支。5.3 误操作的撤销与恢复reset、revert、stash再熟练的开发者也有手滑的时候比如把不该提交的文件提交了或者提交信息写错了或者在一个分支上做了一堆测试代码想全部丢弃。Git的撤销机制是日常开发中最需要掌握的生存技能之一。先说“提交信息写错了”这种轻度问题。如果还没有push到远程可以直接修改最近一次的提交信息git commit --amend -m 正确的提交信息这个命令会把最近一次提交的信息替换掉。如果你已经push了--amend会生成一个不同哈希的提交直接push会被拒绝需要force push。对于还没人拉走的提交用amend修正问题不大对于已经推到远程且其他人可能拉过的提交就不要用amend了而是新增一个修正提交用git revert。git reset用于把当前分支的HEAD挪到指定位置适合丢弃错误的提交。常见的用法git reset --soft HEAD~1 # 撤销最近一次提交但保留改动在暂存区 git reset --mixed HEAD~1 # 撤销最近一次提交保留改动在工作区默认行为 git reset --hard HEAD~1 # 撤销最近一次提交改动全部丢弃不可找回我强烈建议在未熟悉之前不要随便用--hard因为它会同时丢弃提交记录和文件内容找不回来的。真要用先确认自己没有重要改动被波及。git revert则不同它不是移动HEAD而是生成一个新的提交来“反向操作”某个旧提交。如果一条错误的提交已经push到了远程且被其他人拉取用revert是安全的因为历史没有被改写只是增加了一条新提交来抵消错误改动。再来说git stash。这个命令用于临时保存当前工作区未提交的改动然后让你切换到干净状态去做其他事。场景很典型你正在功能分支上改代码突然线上出紧急bug需要切到master马上修复。本地代码不能提交也不能丢弃怎么办git stash push -m user login WIP工作区就变干净了你可以放心切分支。修完bug回来恢复git stash list # 查看所有stash记录 git stash pop # 恢复最近的stash并删除记录 git stash apply # 恢复最近的stash但保留记录pop和apply的区别在于pop会从stash列表里删除这条记录apply则会保留。如果你担心恢复后代码有问题想留着备份用apply更稳妥。这里多说一个细节git stash默认不会暂存未被跟踪的新文件untracked files。如果你想连新建的文件一起暂存需要加-u参数git stash -u不然切完分支回来新文件还留在工作区造成混乱。6. 我踩过的一些Git坑给你提个醒最后这部分我想聊一些不那么“命令直给”但实际开发中非常有用的经验。有些是团队规范层面的有些是操作习惯层面的它们不会直接报错但长期下来能显著提升协作效率。6.1 .gitignore项目初始化时就要建好很多项目的问题都是在已经提交了大量不该提交的文件之后才想起来要写.gitignore。比如Java项目里的target目录、*.class文件Node项目里的node_modulesIDE的配置文件.idea/和.vscode/日志文件、临时文件、本地环境配置等等。这些文件每个开发者的本地状态都不一样提交进仓库只会造成污染和冲突。正确的做法是在项目创建时或者第一次提交前就建好.gitignore文件。格式简单说就是每一行写一条匹配规则支持通配符和目录匹配# 编译产物 target/ build/ dist/ # 依赖目录 node_modules/ vendor/ # IDE配置 .idea/ .vscode/ *.iml # 日志和临时文件 *.log *.tmp .DS_Store # 本地环境配置一般保留示例文件 .env.local application-local.yml如果项目已经提交过这些文件再往.gitignore里加规则并不会让已跟踪文件消失。你需要先把它们从Git的跟踪中移除git rm -r --cached target/--cached参数表示只从版本库中移除不删除本地工作区的文件。执行后提交这次移除操作再配合.gitignore以后这些文件就不会再出现在提交列表里。还有个小心机很多托管平台支持为特定语言和框架生成现成模板比如GitHub上新建仓库时可以选择.gitignore模板GitLab也有类似功能。能直接用模板的话比手写省很多功夫。6.2 提交信息与提交粒度该有的职业素养提交信息这件事前面已经展开过我想再强调一点真正影响协作质量的不是命令语法而是提交的“粒度”。我见过有的同学一个提交包含了一个功能、两个bug修复、若干格式化改动最后出了问题根本说不清哪次提交引入了变动。合理的做法是一个提交只对应一个逻辑变更。比如“修复登录模块的NullPointerException问题”就是一个合理的提交而“代码更新”还包含了登录、注册、密码找回三个模块的改动最好拆成三个提交。拆提交不需要多写多少代码只需要在git add时选对文件在IDEA里勾选正确的文件列表即可。这个习惯对代码review的帮助极大——reviewer可以逐个提交地看而不是在一大坨diff里找重点。如果你在改代码时中途发现了另一个bug并顺手修了可以把两个改动拆成两次提交或者至少用明确的信息说明。别用“update”“fix”“wip”这类信息换个角度想半年后你回头查问题看到一条“update”的提交你会崩溃的。6.3 关于团队协作的几条实用建议第一推送前先同步远程代码。哪怕你觉得“我今天一定会第一个推送”也先执行一次git pull --rebase。这能显著降低冲突概率也让别人在review时不需要反复合并更新。第二不要轻易force push。git push -f这个命令会覆盖远程分支历史一旦别人基于旧历史做了提交你的force push会造成他们历史混乱。只有在非常明确的情况下比如rebase后的个人功能分支并且和团队知会过才适合使用。企业级项目的共享分支绝对不要force push。第三分支删除要及时。功能分支合并完成并发布之后本地和远程的分支都可以删除git branch -d feature/user-login # 删除本地分支 git push origin --delete feature/user-login # 删除远程分支分支积累过多会让分支列表变得杂乱也会让某些自动化流程如CI的tag触发出现误判。第四团队层面尽量统一Git工作流。比如GitFlow、GitHub Flow、GitLab Flow这些常见的模型各有适用的场景。GitFlow适合有明确发版周期的项目GitHub Flow适合持续部署的互联网产品。但不管选哪种“主分支直接提交”都不是一个好习惯。通过Merge Request/Pull Request做代码评审既能保证代码质量也能让团队成员互相了解彼此在做什么。第五遇到问题先看完整报错。Git的报错信息虽然经常很长但往往第一行就给出了问题的类型。照抄报错信息去搜索比模糊描述“git push失败怎么解决”更容易找到对症答案。这是我自己踩了无数次坑后总结出的最实在的经验。Git的学习本质上是一个“先会用再理解最终内化成习惯”的过程。很多人卡在中间阶段是因为只背命令不理解机制。用我前面说的工作区、暂存区、本地仓库、远程仓库四层模型去看待Git你会发现它的设计非常清晰操作也不过是在不同层之间搬数据和同步信息而已。日常开发中真正用得高频的技能也就是安装配置、日常提交、分支管理、冲突处理和问题排查这几大类。把这几块练熟就足够在绝大多数团队里流畅工作了。