git上传代码的流程

git上传代码这事儿，传代真没你想的流程那么玄乎。我见过太多新手在终端里对着`git push`报错干瞪眼，传代其实流程就那么几步，流程卡住的传代点往往在别处。

先把本地仓库初始化了。流程`git init`敲下去，传代目录里多了个隐藏的流程`.git`文件夹，这就算“建档”了。传代但注意——如果你是流程从GitHub上`git clone`下来的项目，这步直接跳过，传代人家自带仓库。流程很多人在这步就犯迷糊，传代明明克隆了还去init，流程结果搞出两个仓库嵌套，传代后患无穷。

接下来是`git add`。这个命令是把改动“装进篮子”，但篮子里装什么得你说了算。我习惯先`git status`看一眼，红字标的就是改过的文件。然后`git add .`一股脑全装？新手常这么干，但项目大了容易把临时文件、密钥文件一起传上去，那叫一个灾难。正确做法是逐个`git add 文件名`，或者用`.gitignore`提前把不该传的屏蔽掉。

装完篮子，得拍照留档，这就是`git commit -m "描述"`。描述别写“update”或者“fix”，写清楚改了啥，比如“修复登录接口超时问题”。这行字是给未来的自己看的——三个月后你回来看提交记录，一脸懵地猜“update”到底更新了啥，那感觉糟透了。

然后才是重头戏，关联远程仓库。`git remote add origin https://github.com/你的用户名/仓库名.git`，这行命令把本地和远程牵上线。但很多人卡在这——如果之前`git clone`过，远程关联早就配好了，直接`git remote -v`查一下就知道。要是没配，还得先上GitHub建个空仓库，别勾选“初始化README”，不然两边历史对不上，push时会被拒。

最后一步，`git push -u origin main`。这里有个坑，以前默认分支叫`master`，现在GitHub改叫`main`了，你得确认本地分支名跟远程一致，不然报错`src refspec main does not match any`。不一致就用`git branch -M main`重命名。

push完那一刻，终端显示`Everything up-to-date`或者一堆进度条，才算松口气。但等等——如果push被拒，提示`non-fast-forward`，别慌。这通常是你本地落后于远程，别人推了新代码。先`git pull origin main`拉下来合并，冲突了再手动改。记住，pull之前最好`git stash`暂存本地改动，不然容易乱成一锅粥。

说个我自己的糗事。有次我`git add .`把`.env`配置文件传上去了，里面全是数据库密码。GitHub秒发安全警报，我连夜改密码、删历史记录，折腾到凌晨三点。从此我学乖了，`.gitignore`里第一行就写`.env`。这玩意儿不是摆设，是保命符。

整个流程跑顺了，其实不到一分钟。真正花时间的，是理清“哪些该传、哪些不该传”，以及写明白每次提交的描述。git是个好工具，但它不会替你想——你提交的每一行代码，都在给自己和别人讲故事。讲得清楚，合作顺畅；讲得含糊，迟早翻车。