★ FEATURED ARTICLE 新人入职第一周leader 往群里丢了个 Git 仓库地址说“代码拉下来建个分支把登录模块的接口调通”。我当时的反应是GitHub 我之前也传过作业啊不就是一个 git add、commit、push 三步走吗结果真上了项目仓库第一条 push 就被拒了——原因写着“protected branch”整个人懵在原地。这种场景我见得太多了。很多新人对 Git 的认知停留在“一个人写代码、把代码传到网上”的程度但团队开发里的 Git 完全是另一套玩法有分支权限、有合并规范、有 code review、有自动化流水线。你以为自己会 Git其实只是会“存代码”而已。这篇文章我不打算从 git init 讲起而是直接站在“你刚进团队、leader 丢给你一个仓库”的场景把新人真正需要的东西一次讲透团队用的是什么工作流、每天要敲哪些命令、遇到冲突怎么处理、以及那些文档里不会写但老手默认你该知道的事。适合谁看刚入职半年内的开发新人、实习生以及那些一直是独自写代码、第一次用 Git 参与协作的朋友。有基础也行重点看工作流规范部分那部分才是团队协作和单人玩 Git 最大的区别。1. 团队协作里的 Git和你之前用的不是同一个东西1.1 你之前学的是“存代码”团队用的是“管协同”大多数人对 Git 的第一印象来自 GitHub。一个人写个小项目自己的分支自己开提交信息随便写push 之前连 pull 都不用。这套模式背后是你一个人承包了开发、测试、发布所有环节Git 在这里充其量是个“网盘 时间机器”的组合体。但团队协作里同样一套 Git 命令背后的约束条件完全不同代码不是只给你一个人看的同事会 review 你的代码commit 写得乱会被吐槽。不是所有分支都能直接 push主干分支往往有权限保护。你不是最后一个碰代码的人昨天还正常的代码可能今天就被别人改了。你的代码会触发自动化测试、自动部署push 上去的每一条 commit 都可能变成线上事故。这就是很多新人最不适应的点Git 在单人模式下是工具在团队模式下是规则。工具只要会用就行规则却需要先理解再遵守最后才能谈用得溜。所以我建议新人入职第一天不要急着敲命令先把团队仓库的 Wiki、Git 相关的规范文档读一遍。正规一点团队会有一份 Git 工作流说明里面写着分支怎么命名、commit 怎么写、merge 还是 rebase。没有文档的团队也别慌直接问带你的导师要一份提交记录近一周的 commit、merge 历史翻一遍基本就能摸清团队的协作习惯。1.2 版本管理的本质协同工作的“空间分配”问题我用一个生活类比来讲团队 Git 的本质一个项目仓库就像一间合租的大厨房每道菜是新功能锅碗瓢盆是共享代码文件。一个人做菜东西放哪儿都行但 5 个人同时做饭你就要考虑谁负责哪个灶台你的食材放在哪一层冰箱你炒菜的时候能不能动别人已经在锅里的菜Git 的分支就是给每个开发者的“灶台”。你在自己分支上随便折腾没问题调料撒了、菜炒糊了都是你自己的事。但你做的菜最终要端上公共餐桌——合并回主干分支。这时候就要遵守公共规则菜的摆盘要统一代码风格、每道菜要有标签说明commit message 规范、必须经过“试菜员”确认才能上桌代码 review。理解了这个隐喻你就掌握了团队 Git 的底层思维分支隔离每个任务、每个功能都在独立分支上开发不污染主干的稳定性。提交即记录commit 是给别人看的工作日志不是给自己看的记事本。合并即发布把分支合并到主干是一条不可逆的通道越到后期代价越大。所以整篇文章你看下来核心其实就是一件事在合理的时间把正确的代码通过合规的流程合并到该去的地方。新人最开始不需要理解 Git 的底层对象模型、不需要记住那些悬空提交的底层原理先把“分支隔离 提交规范 合并流程”这三件事做对就赢过了 80% 的新入职同事。2. 团队主流的 Git 工作流以及为什么你们团队选了其中一种2.1 三种标配工作流对比集中式、Git Flow、GitHub Flow团队用什么 Git 工作流通常和团队规模、发布节奏、业务性质强相关。我见过小型创业团队阶段性地把代码直接推到主干上的——不是人家不规范是真没人也见过几十人的团队用一整套完整的分支模型版本发布还要打 tag、创建 release 分支——不是流程繁琐是发布的系统实在太多、风险实在太高。但不管团队规模如何市面上主流工作流绕不开下面这三种。集中式工作流Trunk-Based Development所有人都往同一个主干分支上开发分支不常开功能也不隐藏。小型团队、需要快速迭代的项目适合这种模式。优点是流程最简单没有分支管理成本缺点是主干随时可能处于“半成品”状态质量靠 CI 和同事自觉撑着。Git Flow 工作流以 master 为线上版本分支develop 为集成开发分支功能从 develop 拉 feature 分支开发完成后合并回 develop发版时从 develop 拉 release 分支线上紧急修复用 hotfix 分支。这套模型分工严密适合需要严格版本管理、定期发版的大型项目但分支多、操作重新人刚接触时容易被分支关系绕晕。GitHub Flow 工作流只有一条常驻主干分支 main任何新功能都从 main 拉分支通过 Pull Request 的形式提合并code review 通过后合并回 main。这是目前互联网团队最主流的方式配合 CI/CD 可以做到随时随地发布。轻量、快速对新人非常友好——因为永远是一条主干你不需要记住复杂的上下游关系。新人拿到仓库后先别急着敲代码第一时间确认团队用的是哪种流。我见过有的新人照着网上 Git Flow 教程在单主干仓库里硬建一条 develop 分支出来结果每次同步都要合并两次给自己和同事都添了麻烦。2.2 分支命名规范一看名字就知道你在做什么团队协作的分支和私人仓库的分支差异很大。自己开发时名字随便起test、dev、fix一个词了事没人管你因为上下文只有你知道。团队协作里分支会被很多人看到、搜索、归并、清理没有统一的命名规范仓库过两个月就会变成一锅粥。绝大多数团队采用的分支命名方式是按类型和描述组合的。举几个真实的例子feature/user-login-api新增用户登录接口feature/pay-order-optimize优化下单支付流程bugfix/fix-orderAmount-npe修复订单金额空指针hotfix/urgent-login-timeout紧急修复登录超时从主干拉出、完成后快速合并用这套命名规则的原因在自己回头看的时候尤其能体会两个月后你接到一个任务要排查“用户反馈登录偶发失败”的 bug在分支列表里用关键词一搜login相关分支一目了然不用一个一个点开看提交记录才能猜出这分支是干嘛的。而且很多团队的 Git 服务端还配置了分支权限——比如普通开发者不允许直接往main分支 push分支名包含了类型前缀权限控制才能写进规则里自动生效。命名还有一个建议分支头和结相小尽量拉完马上开发开发完马上合掉删掉不要让一个 feature 分支活过一个月。分支也是有保质期的放久了和主干冲突越来越大合并成本越来越高最后没人敢碰它成了仓库里的“僵尸分支”。2.3 远程仓库的协作不是 push 上去就完事了如果用一句话概括新人最容易犯的错我会说把推送当成终点而不是起点。我见过太多新人兴冲冲写完代码git push一敲然后就在群里跟导师说“写完了”。实际上在你 push 之后真正的工作才刚刚开始去远程仓库发一个 Pull Request简称 PR有的团队叫 Merge Request在 PR 描述里写清改了什么、为什么改、怎么测试选择合适的 reviewer 来检查你的代码——这一步在正规团队里是代码合并进主干的必经门槛。Reviewer 会看你的 diff、运行你的分支、给出修改建议。你觉得大功告成的代码很可能要被打回来调整两三轮才能合。这个过程不是为了打击你而是团队在拿所有人一起写的代码质量做一道共同把关。所以新人不要有“被 review 就是被否定”的心态把 PR 看成一次请同事帮忙检查代码的机会心态会轻松很多。远程协作还有一个重要原则改别人的代码之前先 pull 最新的主干基于新主干拉新分支而不是在一个放了几天的旧分支上继续开发。主干的变动不会自动通知你但你不主动同步合并时产生的冲突会让你的开发效率断崖式下降。养成每天开始工作前先同步一次主干的好习惯能帮你躲避至少一半的合并灾难。3. 新人加入团队必须先掌握的 Git 命令清单命令我按团队开发的真实使用频率来排不是按教学大纲排。每一条都会先讲怎么用再讲为什么在团队场景下要这么用最后补一个我实际踩过的坑。这部分宁可写得啰嗦一点因为很多问题当时一个点拨就能省掉一天以上的折腾。3.1 克隆、同步、关联进入开发状态的第一步进入团队的第一步用下面这两条命令把代码库拉到本地# 克隆团队仓库到本地url 替换成你们仓库的真实地址 git clone https://github.com/team/project.git # 进入仓库目录后确认当前在哪个分支 git branch -a克隆完成之后第一件事不是直接改代码而是创建一个属于自己的分支git checkout -b feature/user-login-api这里有个新手容易犯的错误直接在 main 分支上改代码。你想想你本地 main 分支开发了半天另一同事已经合并了新功能你想同步他的代码就得 pull 一下结果git pull和你的本地改动撞在一块儿轻则冲突提醒重则把别人代码和自己半成品混在一起理都理不清。所以记住一条铁律主线分支永远保持干净永远不要在 main 上开发。我见过最混乱的一次局面某新同事在 main 分支上改了三天的代码期间团队其他人合并了十几个功能他 pull 的时候冲突从中到后列了几十个文件最后我帮忙把本地改动用 stash 存起来、重置分支、再还原折腾了整整一个下午。进入团队每天开工先同步最新代码git fetch origin # 更新远程所有分支的引用不主动修改本地代码 git checkout main # 切回主干分支 git pull origin main # 更新本地主干到最新 git checkout feature/user-login-api # 回到自己的功能分支 git merge origin/main # 把最新主干合入当前功能分支这套 4 连有一个很重要的隐蔽作用让“主干更新”和“自己改代码”这两件事的生效边界彻底分清。git fetch和git pull很多人分不清。我这儿给你一个最省脑子的用法fetch只下载信息pull才是下载代码并合并。拿不准是不是自己的代码还没保存就用fetch先看一下远程什么情况确认没有风险再pull。熟练之后可以简化合并操作用git pull --rebase教程里都讲 rebase但团队开发里如果你的代码从来没有被推到过其他分支--rebase是安全的一旦你 push 过分支、有别人在基于你的分支开发用 merge 更稳。新人不确定自己在什么阶段就保守一点用git merge。3.2 提交的粒度与信息Commit 是写给别人看的日志很多新人提交代码普遍存在两个问题要么憋了一整天写了几十个文件一次性 commit要么每改一行就 commit 一次提交信息还全写“update”“最新修改”“111”。这两种习惯在自己开发时问题不大但在团队协作里Reviewer 想要做的事是搞清楚这段改动是因为什么引入的、是否可以被单独理解。好的 commit 习惯是一个功能点、一个 bug 修复、一次重构单独占一个 commit。每个 commit 的粒度要小到你万一想回退可以只撤销它而不影响其他内容。举个例子你做“用户登录接口”这个任务里面其实包含新增用户表结构加几个索引新增登录接口业务代码修改前端的登录页面调用严格来说这三件事应该分成三个 commit分别写清楚feat(db): 增加用户表唯一索引确保手机号唯一 feat(api): 新增登录接口支持验证码校验 feat(web): 登录页改为调用新接口至于 commit message 的规范格式业界主流的团队都采用“类型 作用范围 描述”的结构。常见的类型有feat新功能fix修复 bugdocs只改文档style不影响代码逻辑的格式调整refactor重构不改功能只改结构test补充测试chore构建过程、辅助工具的变动格式大致长这样feat(api): 新增用户注册接口增加邮箱格式校验 fix(order): 修复订单金额小数计算丢失精度的问题 style(login): 格式化登录页面代码无逻辑变化这套规范很多新人第一反应是“很做作、很麻烦”但一旦团队规模上来、代码量多起来就明白它的意义重大了。你月底复盘自己做了多少事不需要翻聊天记录只需要git log --oneline过一遍所有工作轨迹清清楚楚查线上 bug 的时候git bisect二分定位问题 commit规范的 message 能帮你瞬间圈定嫌疑范围。实际开发中我的建议是代码逻辑还没完全调通可以先在本地暂存区躺着等确认能编译过、自测通过再把相关文件一次性组织成规范的提交。不需要在开发每一行时就纠结这条信息怎么写提交信息的作用是“事后给人看”的调通后再补齐反而信息更准确。3.3 推送、删除、撤销你需要知道的安全操作姿势几个高频操作在新人这里最容易出事push 被拒、分支删不掉、撤销不知道用哪个命令。推送最稳的姿势是先确认当前分支和远程分支的关系git status # 确认当前所在分支和暂存的变更 git log --oneline -3 # 看看最近提交是什么 git push origin HEAD # 把当前分支推送到同名远程分支push origin HEAD这个姿势新手刚开始可能觉得不直观但它是“在我自己分支上推送”这件事最安全的写法——不会因为分支名打错而把代码推到别的分支去。删除分支团队项目跑久了远程积累一堆已经无用的分支这些分支可删。但要分清删的是本地还是远程git branch -d feature/user-login-api # 删除本地已合并的分支 git push origin --delete feature/user-login-api # 删除远程分支本地分支用了-d是安全模式Git 会检查分支是否已被合并如果还没合并它会拒绝删除此时如果你确定要强删换成-D。远程分支删除不可逆执行前先用git branch -r看看这个分支还在不在、确认是不是已经没有用了。撤销是新手最怕的操作也是平时最容易出错的。直接给你一张行为对照表场景命令说明改乱了工作区想回到上次提交的状态git restore .丢弃所有未提交的改动慎用已经 add 进暂存区想取消暂存git restore --staged file只取消暂存保留你的改动已经 commit 但还没有 push想撤回提交且保留改动git reset --soft HEAD~1撤销最近一次提交但所有该提交的改动回到暂存区已经 commit 但还没有 push想彻底撤销提交和改动git reset --hard HEAD~1不保留该次提交的任何痕迹不可轻易用已经 push 到远程想撤销这次提交不要用reset用git revert commit追加一个相反的新提交覆盖已推送的错误这里特别重点提醒最后一条已经推送到远程的提交几乎永远不要用 reset 去强制回退。因为远程代码别人也可能拉下来过你用 reset 改写了历史别人再拉代码的时候仓库历史出现分叉轻则 pull 报冲突重则直接把同事本地已有的提交搞丢。正确方式是用revert追加一个“反向提交”用一次新提交把旧提交的改动抵消掉——历史被完整保留其他人同步时不会遇到冲突。这个表你截图保存也好、收藏也好建议贴在自己工位旁边。团队这两年下来我处理过的所有“代码丢了”的求助现场十有八九都是reset --hard用在了不该用的时候。4. 实操从拿到需求到提 PR完整走通一条开发链路前面光讲概念和命令了这一章就把一个任务从开始到结束按真实工作流一步步带你走完。我们统一用一个模拟的需求举例“为订单模块增加导出 Excel 的功能并导出前可选日期范围”。这是一个团队里非常典型的增量式开发任务。4.1 拿到需求后同步主干、拉分支、起名字第一步先把自己本地仓库同步到和远程一致的最新状态。这一步比很多人想象的重要因为这是你整个开发周期的起始点你后来的所有 diff 都是相对这个时间点的主干代码来计算的。# 1. 切到主干分支 git checkout main # 2. 拉取最新代码确定本地和相关 git pull origin main # 3. 基于最新主干拉出功能分支命名按团队规范 git checkout -b feature/order-export-excel拉分支这个动作建议带一个明确的意图——你是基于什么需求点、什么任务号、什么目的来拉这个分支的命名好之后项目代码的改动就相对独立地在自己的分支里进行和主干暂时分道扬镳。4.2 开发过程中高频小步提交写清每步在做什么开发过程中我不建议把代码攒到一次性做完再提交。而是每完成一个相对独立的节点就提交一次。比如这个导出功能开发节奏大致是# 1. 新建 Excel 导出工具类并且在导出接口中定义了响应结构 git add src/main/java/com/yourcompany/order/export/OrderExcelExporter.java git commit -m feat(order): 新增订单导出 Excel 工具类定义导出结构 # 2. 实现日期范围条件查询逻辑接上参数 git add src/main/java/com/yourcompany/order/service/OrderQueryService.java git commit -m feat(order): 导出接口支持按日期范围筛选订单 # 3. 写单元测试验证导出内容和查询逻辑 git add src/test/java/com/yourcompany/order/OrderExportTest.java git commit -m test(order): 增加订单导出功能单元测试这样三个 commit 下来代码历史脉络非常清楚。整个功能模块相对独立每一步都自洽就算中间哪一步临时有变化回退也只影响单个逻辑点不会把整个功能推到重来。你也可以用git add .一次性提交所有文件但那样会把无关的格式调整、临时日志输出混进代码里Reviewer 看起来会非常难受。关于提交频率我多说一句有人提倡“每次编译通过就提交一次”有人提倡“一个任务一个提交”。我的实践体会是提交频率取决于你自己的把握能力关键是提交里每一行代码你都能解释清楚它为什么存在。一个功能相关的几十个文件的提交和一次一行的碎片提交同样都是问题。4.3 开发完成之后自测、查看 diff、推送、发 PR功能开发完了自己先确认几件事再推送。这一步能帮团队省去大量无意义的 review 来回沟通。# 1. 先查一下本地这份工作区的变更范围 git status # 2. 再确认代码 diff 是否符合预期 git diff --stat确认改动范围没有误伤其他文件后编译、跑相关的单测把功能本地自测一遍。这两步没人替你等推上去被 CI 拦截或被人 review 出来来回成本就会高很多。然后推送到远程发 PRgit push origin HEAD推送成功后去你们团队的 Git 平台GitHub / GitLab / Gitee 都各有各的操作界面原理一样上发起一个 Pull Request。PR 的基本要求是标题简练概括这次改了什么描述里写清楚本次变更的背景、改动要点、测试情况、涉及到的关联需求或 issue 编号。这些看似琐碎的信息是 reviewer 判断“这个改动靠不靠谱、要不要合”的第一依据。PR 发出来后还可以做几件事提升过审效率主动在 PR 描述里标注“改动最大风险点”比如这次你改了订单金额计算逻辑提醒 reviewer 重点关注表示你有风险意识。如果 PR 解决了某个缺陷把这个 PR 关联到对应的任务单或缺陷单团队可追踪性会强很多。不要把多个不相关的功能塞进同一个 PR比如顺手改了个单词拼写、顺手格式化了一个文件reviewer 对莫名出现的改动非常敏感。与其被要求拆开不如一开始就保持干净。4.4 PR 合入之后删除分支、同步主干、检查流水线PR 被 review 通过、被合并进主干之后开发任务并未结束还有三四步收尾动作新人特别容易漏# 1. 先更新本地的远程分支信息 git fetch origin # 2. 回到本地主干分支 git checkout main # 3. 拉取最新代码这时代码已经包含了你的 PR git pull origin main # 4. 删除本地已经被合并的功能分支 git branch -d feature/order-export-excel # 5. 删除远程已经合并的功能分支 git push origin --delete feature/order-export-excel这几步的意义在于主干是我方最稳定的基线功能分支是一次性的合并之后它的使命就结束了不删的话真个仓库经年累月积累几百个僵尸分支后人翻起来非常痛苦。还有一点合并主干后盯着 CI / CD 页面看几分钟。团队一般都有自动化流水线你刚合并的代码会不会触发构建失败、单测失败很快就能看到结果。如果流水线红了第一时间在 PR 或群里说一声并着手修复而不是坐等同事来提醒你“构建挂了”。这个习惯直接影响同事对你的专业信任度。4.5 代码 Review 的素养不要怕被 review要会回应 review代码 review 是团队 Git 协作中非常特殊的一环它和技术本身关系不大更多是沟通和心态。新人第一次收到一堆 review 意见第一反应基本都是心里有点不舒服“我觉得我写得挺好的啊”“原来这里还能这么写”“这也要改吗”我给你们最大的建议是把 review 意见当成免费的代码设计课。同事指出你代码的问题不是在否定你的能力而是避免这些问题进入主干去影响更多人。而你越早知道、越早改掉你的成长曲线就越陡。我见过太多例子一个新人入职三个月写的代码质量突飞猛进原因就是每次都认真抠 review 意见里隐含的设计原则甚至主动追问 reviewer 为什么这么改。反观那些“改完即走、不关心为什么”的新人半年后写出的代码和刚入职时没什么两样該犯的坑一个没少。收到 review 意见之后常规的标准动作是逐条查看意见在有疑问的地方先补充问一下背景不用急着改。修改之后在原评论下回复“已修改”并附上新的 commit 链接。每次修改尽量追加 commit而不是去改写已经 push 过的历史。reviewer 看到 diff 还是可以一条一条往下看如果改动被压到一个提交里前后对比很吃力。只要你能心态放平、沟通主动、修改及时review 过程其实是一个很高效的互相学习过程。等你以后当了 reviewer大概率也会以同样的方式帮助更年轻的人。5. 团队开发中躲不开的合并冲突与疑难杂症写代码就免不了有冲突团队开发更是如此。这一章把新人必踩的冲突和处理策略讲透附一份高频排查表。5.1 冲突是怎么产生的以及从源头减少冲突的手段想象一个最简单的场景你和同事同时修改了OrderService.java这个文件的第 38 行附近。你改的时候基于的是昨天的代码版本同事基于的是大前天的版本等你们俩的分支先后合并到主干Git 面对同一处地方两个不同的改法没法替你决定保留哪个、放弃哪个于是抛出冲突需要人类来裁决。冲突产生最核心的根源只有一个修改了同一处代码。但从团队协作角度我们可以通过一些手法显著减少冲突概率小步高频合并你的功能分支越晚合入主干、间隔越长冲突概率越大。天天同步一次主干和写了两周再合并后者的痛苦完全不是一个量级。代码模块划分清晰不同团队负责不通的包模块边界清晰不太会同时碰到同一个文件。但这属于架构层面的事新人更多是配合执行。不要把格式化混进功能提交老同事改代码的时候顺手格式化整个文件整个文件 diff 满天飞你和他的改动必然会“冲突”。任何无关的格式改动都应该单独成 commit或者压根就别做。新人阶段最能控制的其实是第一点。我自己有个习惯每天上午开工前先同步一次主干到自己的功能分支下午下班前再看一眼主干有没有新变化。看起来多了几个操作但换来的是合并时的极端省心。5.2 冲突解决的标准流程一步一步来别慌真撞上冲突了不要慌。首先知道一个前提Git 的冲突并不是丢数据只是把人类该做的决策暂时交还给你。标准操作流程如下。第一步先同步主干到自己的分支触发合并。git checkout main git pull origin main git checkout feature/order-export-excel git merge main当 Git 提示冲突时它会把冲突文件里的两边代码都呈现出来用特殊的分隔符标记。打开文件你会看到类似于这样的结构 HEAD // 当前分支feature/order-export-excel上的代码 System.out.println(我的导出订单功能); // 传入分支main的代码 System.out.println(我先有的导出 Excel 功能); main你需要做的事情是决定保留哪一边还是两边整合一下然后把三行分隔符和不需要的内容统统删掉留下一段干净正确的代码。第二步处理完所有冲突文件逐一保存之后用 git add 标记为已解决。git add src/main/java/com/yourcompany/order/OrderService.java git commit -m merge: 合并 main 分支到 feature/order-export-excel解决导出逻辑冲突注意合并冲突解决之后提交信息是带merge上下文意义的录制时好好说是合入主干代码不要只有一句“解决冲突”就完事了。第三步冲突解决后立即自测。合并动作很隐蔽的一个危险在于编译器不会告诉你逻辑是否出错它只保证语法合并对了。冲突是我们人工合并两边的逻辑极有可能出现两边代码逻辑是独立的、但拼起来失去原有语义的情况。所以合并一旦结束务必至少跑一遍相关单测、本地构建确认关键功能没有因为合并而受到破坏。还有一件事提醒新人冲突解决过程中不要顺手做额外的功能改动。你现在的角色是调解员不是开发者。在合并期间夹带新功能会让后面的回溯非常困难。5.3 常见异常场景排查速查表结合这么多年的观察我挑了几个新人提问率最高的问题合并成一张速查表。你遇到问题时先对着表格看一遍多半能自己搞定。场景出现原因标准处理push 被拒提示fetch first远程主干有新提交你的本地历史落后于远程先git pull或git fetch merge解决冲突后重 pushpush 被拒提示protected branch你试图直接推到受保护的分干如 main不要硬 push重新基于主干拉一个分支push 到该分支发 PR 合并git pull后本地改动被要求先提交本地工作区有未提交改动pull 可能发生覆盖先用git stash暂存本地改动pull 完再git stash pop恢复git merge后立刻后悔合并内容没问题但没有自测尚未 push 的话用git reset --merge取消本次合并已 push 的话用git revert追加回退提交找不到自己之前提的分支分支名没记住或分支已经被删除远程用git branch -r查所有远程分支本地用git reflog查最近的操作记录提交信息写错了还没 push最近一次提交信息不合适git commit --amend重新提交改信息而不增加新提交在没有感知的情况下改了代码却不在想改的提交里多个文件全部 add 了用git add 文件精确控制要提交的文件配合git status反复确认远程分支有别人 push 的新提交而你本地也 commit 了历史分叉需要整合git pull默认 merge 即可也可用git pull --rebase把本地提交接到最新主干上但注意如果有同名分支冲突优先 merge这几点你要是都感知到了Git 团队开发基本就已入门。剩下的都是在实际操作中积累手感的问题——多踩几次坑并自己排查印象会深得多。5.4 新人的心态建设接受低效保持透明最后一段讲点技术之外的事。新人用 Git 时常有的心理负担是怕自己动作慢、怕总在问同事问题、怕 merge 冲突被别人觉得自己菜。我可以明确告诉你这些担忧非常普遍每个人刚开始都一样。但你会发现团队的老同事对一个新人的接纳程度往往取决于一个态度当你遇到自己搞不定的问题时是不是及时暴露、及时求助。我见过两类新人一类吭哧吭哧自己搜解决方案憋了几个小时没进展另一类发现自己卡住二十分钟就去问旁边的老同事先拉通阻塞再继续。谁更受团队欢迎、成长更快几乎没有例外是后者。具体到 Git 操作上就是宁可多问一句“我们团队的合并策略是 merge 还是 rebase”也不要按网上教程任意发挥搞完之后仓库历史风格跟团队完全不同。宁可初期慢一点、每步看一眼git status确认自己在哪儿也不要凭感觉敲命令然后看 log 一脸蒙。宁可 commit 写得啰嗦些、信息充足些也不要为了显得简洁写一个只有自己能看懂的缩写。Git 是工具不是考核。团队更在意的是协作结果——代码是否及时合入、主干是否保持稳定、团队是否因为你的操作而降低了效率。你只要把这个核心目标放在心上把流程跑熟剩下的技术细节都能在真实项目中快速补齐。6. 实操三个月之后我建议你回看这几件事如果运气好你在这家公司待够三个月你一定会在某一次操作中体会到这篇文章前面所有内容到底在讲什么。到那时候再回过头来复盘你会对自己的成长有个清晰的感知。复查自己的提交记录。用git log --author你的名字 --oneline看看自己提交了哪些 commit信息是否规范、粒度是否合理、有没有出现于是前后矛盾的一堆碎片提交。如果你发现自己已经能稳定地写出结构良好的提交记录恭喜你你已经跨过了“会用 Git”的坎开始“用 Git 表达你的开发过程”了。再回看一次你处理过的冲突。Git 的reflog记录了你每一次操作。看看你哪次冲突最惨烈、哪个步骤最多余复盘当时如果换一种方式会不会更好。这个过程其实就是老手和新手最大的差异老手不是不会犯错而是犯过一次之后再也不会用同样的方式犯第二次。最后给你一条很实在的建议把你学习和踩坑的过程记录下来。不用写得花哨就在个人笔记里记一条“合并冲突时要先看三行分隔符的位置再动手别急着删”“revert 的是提交reset 回的是状态”这种小笔记。半年后回头看这些才是职业生涯一开始最宝贵的积累。Git 本身不是目的它只是团队协作的载体。掌握了这门工具和它背后的协作规范你才能真正把“一个人写代码”的思维切换成“和一群人把一个项目长期维持下去”的思维。这也是软件开发这件事比单纯写码更迷人的那部分——它是一种需要大量沟通、协调和共识的工程活动而 Git 的冷冰冰的指令背后恰恰是团队不断磨合、共同维护代码质量的日常。
阅读完成 · 觉得有帮助？
