个人开发必备Git流程：从配置到回滚的完整实践

很早以前我也觉得，git是团队协作才需要的东西，一个人写代码哪用那么讲究。直到自己手里同时维护三四个项目，电脑换了一台又一台，某天想回退一个功能改动却找不到历史节点，才意识到个人开发如果没有一套顺手的git流程，本质上就是在裸奔。项目越往后写，配置、文档、脚本越来越多，改坏一个地方可能半天都找不回来。

这篇东西不是git命令大全，而是我在个人开发场景里沉淀下来的一整套使用习惯。包含git安装与初始化配置、SSH免密登录、日常提交的核心命令流、分支合并策略，以及IDE集成时那些奇怪参数的真实含义。适合正在从“会用几个git命令”走向“能稳定管理自己代码”的开发者，也适合被每次push都要输密码、提交信息乱写、误操作不知道怎么回滚这些事烦过的人。内容按实操顺序组织，照着走一遍就能把个人开发环境理顺。

1. 个人开发流程先想清楚三件事

很多教程上来就铺分支模型、多人协作规范、code review流程，对个人开发者来说反而制造焦虑。一个人开发，没有同事帮你review代码，没有CI帮你跑测试，所有错误都只能自己兜住，所以流程设计的核心逻辑不是“管控”，而是“能后悔、能定位、能恢复”。

1.1 单兵作战最常见的三个误区

个人项目最常见的做法是：git init完事，代码写一大坨一次性commit，commit message写“更新”或者“修改”，所有改动全堆在master/main分支上，从不打tag。短期看没问题，等代码量过万行之后，问题就暴露了。

第一个问题是没法精准回滚。一次提交里混着新功能、bug修复、配置文件调整，某天线上出问题需要回退某一项改动时，根本无从下手，因为commit已经被打包得乱七八糟。

第二个问题是没法定位问题引入时间。用git bisect定位回归bug时，如果每个commit都是几百行代码的巨无霸，每次二分都要在大量代码里人工分辨，效率极低。

第三个问题是换设备后环境不一致。换台电脑想继续开发，发现之前的用户信息是别人的、换行符处理乱套、每次拉取推送都要输密码，这些都是没有系统配置过git的典型症状。

1.2 个人流程只需要守住四条原则

不需要把团队协作的那套完整搬过来，个人开发只要做到四点就足够：

• 每次提交只做一件事，改动范围尽量收窄，哪怕一个功能拆成多个commit也值得。
• 提交信息能说明白改动原因，半小时后你看到它还能想起来当时在干嘛。
• 关键节点打上tag，release一个版本就记录一次，方便随时回到稳定点。
• 所有“误操作”都有后悔药，reflog、stash、reset这几个技能必须熟练。

这篇文章后面的所有内容，都是围绕这四条原则展开的。安装配置是地基，SSH免密解决的是体验问题，日常命令流程是核心动作，分支和回滚则是安全兜底。

2. Git安装与初始化配置：先把工具底座搭稳

个人开发流程里最容易被忽略的是初始配置。很多人装完git就开始commit，根本不管user.name、user.email、换行符属性这些基础配置，结果提交历史里出现别人的名字，或者项目在Windows和Mac之间来回切换时出现成片的换行符diff，这些都是可避免的。

2.1 Windows环境安装与Git Bash的选择

如果主力环境是Windows，安装git时建议直接到官网下载安装包，一路默认选项即可。安装完成后，系统里会出现Git Bash和Git CMD两个入口，日常操作优先使用Git Bash。

Git Bash的本质是一个模拟Unix终端的环境，提供ls、grep、sed这些Linux命令，和真实Linux终端里的操作手感几乎一致。个人开发中大部分时间需要在终端里看状态、查日志、处理冲突，Git Bash下写的命令以后切到macOS或Linux服务器时可以直接复用，不需要重新记忆一套Windows风格的东西。

安装完成后第一步验证版本，在Git Bash里执行：

bash复制git --version

能正常输出版本号，说明安装成功。如果cmd里也想直接使用git命令，需要把git的bin目录手动加到系统PATH环境变量里，但个人使用场景下，固定在Git Bash里操作就够了，不太建议去折腾这个。

2.2 第一次安装后必配的五个参数

刚安装完的git是一张白纸，不配置也能用，但会埋下一堆坑。以下五组配置建议逐条执行，它们分别解决不同的问题。

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --global core.autocrlf input

user.name和user.email会写入每一次commit记录里，这是提交历史的“身份证”，一定要设置成真实可识别的信息，方便日后追溯。

init.defaultBranch设成main是为了避免新建项目默认生成master分支。现在主流托管平台默认分支名基本都是main，提前统一格式能少很多认知负担。

pull.rebase true解决的是拉取代码时的合并方式问题。默认情况下git pull执行的是merge操作，会在历史里产生多余的合并提交；设为rebase后，本地提交会“搬到”远程最新提交的顶端，历史是一条干净的直线，对个人项目的代码审查和回溯更友好。

core.autocrlf建议直接设成input。这个参数控制git如何处理换行符。Windows下文件默认用CRLF（回车换行）结尾，Linux/macOS用LF（换行）结尾。如果设置成true，git在提交时会把CRLF转成LF，检出时再转回CRLF，这容易造成一种情况：项目里同一行代码，在一个平台上显示有改动、另一个平台显示没改动。设成input后，git只在提交时把CRLF转换成LF入库，检出时不转换，能最大程度减少换行符引起的假diff。

注意：core.autocrlf只对改动过的文件生效，不会自动修复历史文件。如果项目中已经存在大面积的换行符差异，需要一次性规范化处理，不要指望改完配置世界就清净了。

2.3 Git Bash中文乱码和显示优化的处理思路

Git Bash在中文环境下有两个典型问题。一个是git status和git log显示中文文件名或提交信息时乱码，另一个是终端里手动输入中文commit message显示乱码。前者和core.quotepath有关，后者涉及bash的locale设置。

core.quotepath默认是true，git为了兼容性会把非ASCII字符转义成八进制形式，导致中文文件名显示成\346\265\213\350\257\225这类东西。直接关掉即可：

bash复制git config --global core.quotepath false

设置完后，git status、git log里就能正常显示中文文件名。

终端乱码问题则可以在Git Bash窗口上右键，选择Options，在Text区域把Character set改成UTF-8。同时确认系统区域设置里勾选了“Beta版: 使用Unicode UTF-8提供全球语言支持”，这个选项在Windows设置的语言和时区页面里。这两个地方都调整后，中文支持基本就完整了。

3. SSH免密登录配置：多设备场景下的关键一步

个人开发到一定阶段一定会遇到多设备同步的问题。台式机、笔记本、家里和公司可能有不同的机器，如果每次git push到远程仓库都要输一次用户名密码，体验非常痛苦。SSH免密配置是个人开发流程中投入产出比最高的一步，配置一次，一劳永逸。

3.1 生成密钥并与托管平台绑定

SSH免密的原理是使用一对密钥：私钥留在本地，公钥交给代码托管平台。git操作时，托管平台用公钥验证你的身份，验证通过就允许你操作。整个过程自动完成，不再需要输入账号密码。

生成密钥的命令：

bash复制ssh-keygen -t ed25519 -C "你的邮箱"

密钥类型推荐ed25519，它比传统的RSA更安全，长度更短，生成速度快。如果托管平台比较老旧、不支持ed25519，再退一步用RSA 4096：

bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"

执行过程中会提示设置保存路径和passphrase。路径直接回车默认即可，passphrase可以不设置，否则每次使用密钥都要额外输入一次密码，和免密的初衷冲突。

生成完成后，本地会多出两个文件。私钥一般在~/.ssh/id_ed25519，公钥在~/.ssh/id_ed25519.pub。把公钥内容复制出来，粘贴到代码托管平台的SSH keys设置页面里，绑定即完成。

验证是否配通：

bash复制ssh -T git@你的托管平台地址

能返回欢迎信息说明已经成功。如果返回permission denied，优先检查公钥是否完整复制、是否多了空格或换行。

3.2 多设备多账号的config配置法

个人开发者通常不止一个托管平台账号，比如公司用的企业GitLab、个人项目用的Gitee或GitHub。每台设备都生成独立的密钥对，然后把不同主机的连接分流到对应的私钥上。

在~/.ssh目录下新建一个config文件，写入类似下面的内容：

code复制Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Host gitee.com
    HostName gitee.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitee

这里的关键是每台设备生成各自独立的密钥对，而不是把所有平台都指向同一把私钥。原因在于私钥跟随设备走，如果不同设备共用一把私钥，其中一台设备丢失或泄露就等于所有账号都暴露。使用独立密钥对，任何时候发现设备异常，只需要去对应托管平台删掉那把公钥，不需要逐个平台处理。

config文件的权限在Linux/macOS下需要设成600，否则ssh会拒绝加载：

bash复制chmod 600 ~/.ssh/config

Windows的Git Bash通常不强制检查这个权限，但如果在macOS或Linux服务器上操作，这一步不能漏。

3.3 SSH免密失败时先别急着换HTTPS

很多人免密配置不成功，第一反应是放弃SSH改用HTTPS加密码，但那样就回到了每次输密码的老路。排查SSH问题和写代码调试一样，要用排除法。

第一步确认ssh-agent正在运行：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

第二步确认config文件里的Host名称和clone地址中的域名完全一致，一个字符都不能差。

第三步确认公钥已经正确添加到托管平台，复制公钥时不要手动打，直接用命令读取再全选复制，避免漏字符：

bash复制cat ~/.ssh/id_ed25519.pub

这三步走完，绝大多数免密失败的问题都能解决。如果还不行，执行ssh -vT git@托管平台地址查看详细连接日志，报错信息会精确告诉你失败在哪个环节。

4. 日常开发核心命令流：一套固定的操作节奏

个人开发流程能不能真正落地，核心在于日常操作到底遵循什么节奏。很多人对git的印象停留在“add、commit、push”三步，但这只是最粗粒度的工作流。真正好用的日常流程应该是一个有反馈、能检查、可回退的闭环。

4.1 新项目初始化时的标准动作

创建新项目时，不要急着写代码，先完成基础初始化动作。这组动作虽然简单，但能为后面的开发省下大量麻烦。

bash复制git init
git config user.name "项目内用名"        # 可选，覆盖全局配置
git config user.email "项目内邮箱"       # 可选，覆盖全局配置
touch .gitignore
git add .
git commit -m "chore: 项目初始化"

这里值得多说两句的是.gitignore。个人项目常见的依赖目录、编译输出目录、IDE配置文件、环境变量文件都必须忽略掉。用Node.js写过项目就会知道，node_modules动辄几万个文件，如果不加进.gitignore，每一次git status都要转好几秒，commit时还会把几百MB的依赖包塞进仓库。建议新建项目时第一时间把该忽略的目录列好，不要等提交了垃圾再懊恼。

一个通用原则是：任何能通过命令或配置重新生成的文件，都不应该进入版本管理。源码、文档、配置文件模板这些需要人工维护的才应该提交。

4.2 每天重复次数最多的四步检查动作

开发过程中，我习惯每完成一个可运行的小改动就执行一轮检查，这个循环我用任何语言写项目时都是同样的动作，已经变成了“肌肉记忆”。

bash复制git status
git diff
git add <具体文件>
git commit -m "feat: 清晰的改动说明"

git status告诉你当前工作区有哪些变化。git diff告诉你这些变化具体是什么内容。很多新手跳过了diff这一步，直接git add .然后commit，结果把调试用的print语句、临时注释也一并提交了。先看diff，能确认自己到底改了哪些东西，粒度是否合适，有没有夹带不相关的修改。

commit message我会用一个简单的类型前缀来区分改动性质。feat是新增功能，fix是修复bug，docs是文档变动，refactor是代码重构，test是补测试。本质上只是给自己看的索引，约定越简单越容易坚持。对于“feat: 给配置中心增加YAML格式支持，配置项自动热加载”和“更新”，带类型前缀的写法在半年后查历史时价值差异是巨大的——前者能一眼判断这个commit改了什么、能不能直接回滚，后者无异于考古。

4.3 提交错了怎么优雅补救

个人开发环境里最常见的提交事故，是commit之后发现漏了一个文件，或者message写错了。这时候不需要慌张，git本身就提供了后悔药。

如果只是漏了文件，把文件加入暂存区后执行：

bash复制git commit --amend

这条命令会修改当前分支最近一次commit，把新的暂存改动并入进去，同时还可以顺便修改提交信息。它的效果是“在不增加commit数量的前提下，修正上一次提交的内容”，对个人分支来说非常方便。

如果分支已经推到远程，并且这个commit已经作为正式历史被别人使用，那就不要用amend了。但对于个人项目完全没这个顾虑，大胆用即可。

另一个高频场景是开发到一半想切换任务，但工作区还有大量未完成的改动。硬commit会破坏历史的整洁性，直接切分支代码也跟着走。git stash就是为这个场景准备的：

bash复制git stash            # 暂存当前工作区的改动
git stash list       # 查看暂存列表
git stash apply      # 恢复最近一次暂存，但保留记录
git stash pop        # 恢复最近一次暂存，并删除记录

我个人的习惯是用apply而非pop。因为pop如果恢复时发生文件冲突，暂存记录会被直接丢弃，改动内容可能丢失。用apply则保留了暂存数据，就算恢复出了冲突，也有原始副本可以对照排查。

注意：stash只暂存tracked文件的改动。如果新增了文件但还没git add过，stash时需要用git stash -u参数才能把untracked文件一并收纳。

4.4 查看历史时比log更有用的几个视图

git log是查看提交历史的入口，但默认输出在个人项目动辄几百个commit之后会变得很难读。我建议先做两件事：一是alias一个短命令，二是换一种清爽的输出格式。

bash复制git config --global alias.lg "log --oneline --graph --all --decorate"

配置完成后执行git lg，能看到一条带分支走向的简版历史，每个commit的哈希和message一句一行，项目全貌一目了然。类似用处很高但容易被忽略的命令还有git log -p（查看某次提交的具体改动）、git log -S "关键词"（搜索哪个commit新增或删除了某段代码），定位历史问题时会派上大用场。

5. 分支、合并与回滚：一个人也要有的安全带

个人开发虽然没人和你冲突，但分支策略依然重要。一段正在开发的功能、一个尚未验证的修复，如果都提交在主分支上，某天需要发布一个紧急修复时就会很被动——发布版本里会莫名带上一堆还在开发期的半成品。

5.1 个人项目的极简分支模型

个人项目强烈建议采用main + develop + feature的三层分支模型，但不需要做完整的Git Flow那么重。

• main分支只存放可发布、可运行的稳定代码。
• develop分支是日常开发的主战场，功能开发的起点。
• feature分支从develop拉出，一个功能一个分支，开发完成后合并回develop。

具体操作是先建立develop分支：

bash复制git branch develop
git branch -d main        # 如果main上还没有独立提交可以删除

开发新功能时，从develop拉出全新的feature分支：

bash复制git checkout -b feature/login-module develop

完成功能后合并回develop：

bash复制git checkout develop
git merge --no-ff feature/login-module

用--no-ff参数的目的是保留feature分支的开发痕迹，让历史里清楚地看到“这是一次完整的feature合并”，而不是把分支里的提交直接压在develop上“看起来像一次性改完”。这在个人开发中看起来有点繁琐，但当项目并行维护多个功能模块时会发现，没有feature分支的隔离，代码里很容易混入莫名其妙的临时改动。

发布稳定版本时，把develop合并到main并打上tag：

bash复制git checkout main
git merge --no-ff develop
git tag -a v1.0.0 -m "release: 用户模块独立版本"

这套模型一个人维护时成本很低，但能保证随时有一个干净的可发布分支。

5.2 merge还是rebase：个人项目里我推荐这样做

团队协作场景里merge和rebase的争议很多，个人开发里我更看重的是历史可读性。

在feature分支开发期间，如果develop上有新提交，可以定期把develop合并进feature，或者rebase自己的feature分支到最新develop之上。两者的效果差异在于历史形状：merge会产生一个额外的合并commit，rebase则重写自己的提交历史，让feature分支看起来像直接生长在最新develop之上。

个人开发中，如果feature分支只有自己一个人用，我倾向用rebase来保持历史线性：

bash复制git fetch origin develop
git rebase develop

执行时如果发生冲突，解决完继续git rebase --continue，不想继续了就git rebase --abort，安全退出。

但有一个禁忌：如果feature分支已经推到远程，并且远程的提交被其他设备clone过，这时候不要再rebase改写历史。改写后再push会导致远程和本地历史完全对不上，别人clone下来会看到大量重复的commit。个人开发虽然很少出现这个场景，但在多设备间同步feature分支时仍然可能踩到，所以我的经验是：“没推过远程的分支随便rebase，已经推过的分支老老实实merge”。

5.3 误操作回滚方案速查表

每个开发者都会有想撤回某个操作的时候。git的灵活之处在于它提供了不同层级的回滚能力，但选错层级可能带来更严重的后果。以下是我整理的一份方案速查表，标记了适用场景和风险等级。

对个人项目而言，最常用的两个回滚动作是revert和reset。

revert会生成一个新的commit来反向撤销目标commit的改动，相当于“改过的痕迹还在历史里，只是通过新提交把内容改了回来”。好处是没有强推风险，缺点是会留下一条“撤销提交”记录，历史看起来多了一个节点。

reset则是直接移动分支指针，让分支回到过去某个commit。soft和hard的区别是：soft保留工作区的改动，只移动HEAD指针，适合“上一个commit写乱了，退回一步重新提交”；hard则连工作区的改动也一并覆盖，执行后工作区会变回那个commit的状态。hard操作风险很高，执行前务必确认工作区没有未提交的改动。

如果reset后发现搞错了，也不用绝望，执行git reflog可以看到git HEAD移动的全部历史，用git reset --hard 正确的commit哈希就能救回来。reflog是git的终极后悔药，每一次commit、checkout、reset、merge都会被记录，个人项目里因为一句话说不清的需求调整而删掉的分支、丢弃的提交，靠reflog都能找回来。

6. 那些绕不开的命令行细节：IDE背后到底跑了什么

个人开发流程中，如果主力工具是IntelliJ IDEA这类IDE，会注意到IDE自带的git插件执行各种操作时，终端底部的控制台里会输出一串很长的命令。很多开发者根本不看这些输出，但偶尔遇到奇怪的现象时，能读懂它们会有很大帮助。

6.1 IDE内置Git的控制台日志解读

在IntelliJ系列IDE（IDEA、PyCharm、WebStorm、Android Studio等）中，执行commit、update、push等操作时，底部版本控制面板会展示类似下面的完整shell命令：

code复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks commit -m "feat: 完成登录模块开发"

这串命令本身就在用“参数式配置”的方式，在调用git时临时覆盖了几个关键配置项，比全局配置更有说服力地说明了日常开发中哪些参数值得我们了解。

• -c diff.mnemonicprefix=false：关闭diff输出的助记前缀功能。git diff默认用a/和b/作为比较双方的目录前缀，关掉后输出更简洁，IDE解析时不容易出错。
• -c core.quotepath=false：和前面配置里讲到的一样，关闭非ASCII转义，确保IDE界面里中文文件名能正确显示。
• --no-optional-locks：告诉git在执行该命令时不要获取额外的可选锁。IDE会高频调用git命令来刷新文件状态，如果每次刷新都去拿锁，大量操作并发时会产生性能瓶颈和冲突。

从这串参数能看到两个关键信息：一是IDE集成的git并不是什么神秘的高层封装，本质还是在调命令行git；二是个人开发如果想排查问题时，绕过图形界面直接在终端执行同样的命令，输出信息通常更完整。

6.2 个人开发中遇到“IDE状态刷新异常”时怎么处理

IDE里的git插件偶尔会抽风，比如明明commit成功了，但文件颜色、状态图标没有更新；或者本地有改动，IDE的提交面板里却不显示。遇到这种情况，多半不是代码问题，而是IDE的git缓存需要刷新。

处理办法是从IDE设置里找到Version Control，对当前项目执行“Invalidate Caches / Restart”（清除缓存并重启）。如果问题依然存在，那就去Git Bash里手动执行git status。终端输出永远是最有参考价值的，IDE界面显示“所有文件都正常”，但终端里却能看到异常状态，这种情况我遇过不止一次。

值得一提的还有IDE内嵌终端和外部Git Bash的区别。IDE内嵌终端本质是在IDE进程里运行的shell环境，环境变量、PATH等可能与外部终端不完全一致。如果在内嵌终端里执行命令出现“command not found”，在外部Git Bash里执行是正常的，不要怀疑自己配置有问题，直接在IDE中把默认终端改成使用系统安装的Git Bash路径即可。

6.3 配置一个顺手好用的.gitconfig

个人开发流程走到最后，一定要沉淀出一份自己的全局.gitconfig。我自己维护着一个跨设备同步的配置文件，每换一台电脑，配置还原之后git命令的手感立刻回来。

全局配置文件在用户主目录下的.gitconfig文件。核心内容除了前面提到的user信息、core.autocrlf、init.defaultBranch、pull.rebase之外，也包含一些别名快捷键。

text复制[alias]
    co = checkout
    ci = commit
    st = status
    br = branch
    lg = log --oneline --graph --all --decorate

这些别名本质上是把高频命令缩短到两三个字母，减少键盘往返。单看节省的时间微乎其微，但积少成多，开发时减少的打断感对注意力的保护是实打实的。建议把alias按自己使用频率进行定制，规则是“自己打字超过四次、使用频率每天至少一次的，就应该起别名”。

7. 个人开发流程中的常见疑难杂症处理记录

无论前期准备多充足，实际操作中一定会遇到五花八门的问题。下面这些场景是我自己在个人项目里真实处理过的，每一个都对应着一套排查思路，顺手整理成问题速查，方便大家对照排雷。

每次push都提示输入用户名和密码

问题几乎都出在远程仓库地址用的是HTTPS协议。执行git remote -v查看，如果返回的地址是https://开头，说明走的是HTTP认证。虽然也可以配置credential helper缓存密码，但最省心的还是换掉remote地址，改用SSH协议。

bash复制git remote set-url origin git@你的托管平台地址:用户名/仓库名.git

前提是已经完成前面第3节的SSH密钥配置。改完后再次push，如果一切正常，就不会再问用户名密码了。

新项目git init之后发现默认分支叫master

这说明本地git版本可能较老，或者没有正确配置init.defaultBranch。首先执行git config --global init.defaultBranch main解决以后新建仓库的问题。已存在的仓库直接用git branch -m master main重命名即可。

commit之后发现全局配置的user.name不是自己想要的

执行git config user.name "项目内的名字"，在仓库目录内覆盖全局配置，然后再用git commit --amend --reset-author更新上一次提交的作者信息。如果历史已经有多条错误信息，可以用git filter-repo批量改写作者，但个人项目一般不需要处理得那么深远。

开发一半时被其他事打断，想换个分支但代码乱成一团

这种情况推荐先commit一个WIP节点或者stash暂存。WIP节点指“Work In Progress”，提交信息写wip: 临时保存，返回时再根据需求继续开发或重新整理。相比stash，WIP节点的好处是改动仍然保留在分支历史里，不容易因为误操作丢失。

git pull时提示“unrelated histories”

这个错误出现在两个仓库历史没有共同祖先的前提下执行合并时。比如新建了远程仓库并勾选了“初始化README”，然后本地很多个commit后再去拉取远程内容，两边的历史完全没有交集。建议先确认要不要保留远程的初始提交。如果不需要，可以直接git pull origin main --allow-unrelated-histories完成一次强制的历史合并，或者用git fetch后手动整合。

误删了分支或误reset后找不到提交

用git reflog列出所有历史HEAD移动记录，找到目标commit的哈希，然后从那个地方重新创建分支或者reset回去。这是个人自救的最后一道防线，几乎所有硬分支删除都可以用reflog找回。需要注意的是reflog的记录本身会被git定期清理，默认大约90天，超过这个时间窗口后就真的找不回了。

项目目录突然出现一堆.orig或反斜杠后缀的混乱文件

这类文件通常来自git合并冲突时自动生成的备份文件合并冲突备份，说明之前某次merge或cherry-pick时发生过冲突，而当时处理完冲突后没有清理干净。确认改动正常后，直接把这些临时文件从工作区和磁盘上删除即可，不需要提交版本管理。

8. 一套开箱即用的个人git全流程清单

最后，把整篇文章的核心动作整合成一个可直接照着执行的清单。这份清单我不定期用到新项目上时都会过一遍，每次都能挡掉一些低级问题。

bash复制# 新设备、新环境初始化
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --global core.quotepath false
git config --global core.autocrlf input

# SSH密钥生成与绑定托管平台
ssh-keygen -t ed25519 -C "你的邮箱"
cat ~/.ssh/id_ed25519.pub  # 复制到托管平台

# 新项目初始化
git init
git checkout -b main
touch .gitignore
git add .
git commit -m "chore: 项目初始化"

# 主分支保护：建 develop 开发分支
git branch develop
git checkout develop

# 功能开发流程
git checkout -b feature/my-feature develop
# ...开发代码，小步提交...
git add <具体文件>
git commit -m "feat: 每个独立功能作为一个commit"
git checkout develop
git merge --no-ff feature/my-feature

# 发布稳定版本到 main
git checkout main
git merge --no-ff develop
git tag -a v1.0.0 -m "release: 稳定版本说明"

# 踩坑后恢复
git reflog  # 万能后悔药入口

这套流程每个节点用到的命令没有一个是偏门高深的，全部是个人开发场景下最高频的操作组合。但把它们按照正确顺序串起来，效果比散装用命令好得多——因为流程的核心价值从来不是某个单独命令，而是命令之间的组织关系和触发时机。

我在实际使用中最大的感受是，git流程不是给别人看的规范，而是自己工作习惯的固化。刚开始时会觉得“多了一步操作”，坚持两周之后，这些动作已经成为写代码之外的默认节奏。真到了项目迭代到第几十个版本、某个改动需要追溯到几个月前的时候，才会意识到当初那些“多出来的步骤”全都是在为后来的自己省时间。