git init 是个人 PHP 项目唯一必要起点，应先写代码再初始化仓库、手动配置 .gitignore（含 vendor/、config.local.php 等），避免误提交敏感文件或生成目录，首次推送前需设 origin 并用 -u 绑定分支。
用 git init 就能起步，别碰 SVN 或 Mercurial
个人 PHP 项目不需要复杂流程，git init 初始化本地仓库是唯一直接有效的起点。SVN 和 Mercurial 对单人小项目纯属增加负担——没服务器、没团队协作需求，就别给自己加配置成本。
常见错误是先建远程仓库再克隆，结果本地 PHP 文件结构被 Git 默认忽略规则搞乱（比如 .gitignore 没配好，漏掉 vendor/ 或误删 config.php）。正确顺序是：先写代码 → 再 git init → 然后手动写 .gitignore。
-
.gitignore至少要包含：vendor/、node_modules/、composer.lock（如果不用锁文件部署）、*.log、config.local.php - 别用 GitHub/GitLab 的「Add README」勾选框初始化仓库——它会强制你第一次提交带 README，反而打乱你本地开发节奏
- PHP 项目常混有生成文件（如
cache/、logs/），这些目录必须进.gitignore，否则每次git status都飘红
commit 前先确认哪些文件真该提交
PHP 项目容易把不该进版本库的东西提交上去，比如本地调试用的 test_db_connect.php、硬编码数据库密码的 config.php、或 IDE 自动生成的 .idea/ 目录。Git 不会帮你判断“这文件该不该存”，全靠你人工过滤。
执行 git add . 是最危险操作——它默认递归添加所有未忽略的变更文件。你应该用 git status -s 先看一眼，再逐个 git add 明确文件。
立即学习“PHP免费学习笔记（深入）”；
- 敏感配置必须分离：用
config.example.php提交，本地复制为config.php并加入.gitignore -
composer install生成的vendor/绝对不提交——只提交composer.json和composer.lock（后者用于锁定依赖版本） - 如果用了 Laravel Mix 或 Vite 构建前端资源，
public/build/这类产出目录也要忽略，只提交源码（resources/）
push 到 GitHub 前，先设好 origin 而不是直接 git push
很多人卡在 git push 报错 fatal: The current branch main has no upstream branch，本质是没告诉本地分支该推到哪。GitHub 新建空仓库后给的提示命令（git remote add origin xxx）不能跳过。
注意：GitHub 默认主分支名现在是 main，但你本地可能是 master。别强行改名，用 git branch -M main 重命名本地分支更省事，避免后续推送时反复指定 -u origin/main。
- 设置远程地址后，用
git remote -v确认是否成功，输出应含origin https://github.com/xxx/xxx.git (fetch) - 首次推送用
git push -u origin main，“-u” 是关键，它把本地main绑定到远程origin/main，之后直接git push就行 - 如果之前已提交过敏感信息（比如密码），别想着删文件再 push——得用
git filter-repo彻底从历史中清除，否则远程仓库依然可查
日常更新别总 pull，用 fetch + merge 更可控
个人项目虽无多人冲突，但你可能在多台设备（公司电脑 / 家里笔记本）上开发。直接 git pull 会自动 merge，一旦本地有未提交修改，就触发合并冲突——而你只是想同步远程最新版。
更稳妥的做法是分两步：git fetch origin 先拉取远程变更但不应用，再用 git merge origin/main 或 git rebase origin/main 手动决定如何整合。尤其当你本地有未 push 的 commit，rebase 能保持线性历史。
- 如果只是想覆盖本地代码（比如在家改错了，想回退到远程最新版），用
git reset --hard origin/main，比pull更干净 - 用
git log --oneline --graph --all快速看分支关系，避免误操作导致 HEAD 漂移 - PHP 项目常因换环境导致换行符或权限位变化，引发大量假冲突。可在
.gitattributes加* text=auto统一处理
实际最难的不是命令，而是每次 commit 前花 10 秒想清楚：这个改动会不会让别人（或者三个月后的你自己）看不懂？有没有把临时调试代码一起提交？.gitignore 是否还准确？这些细节比学会 rebase 更影响长期维护。
