ThinkPHP Linux如何进行版本控制

ThinkPHP项目在Linux环境下的版本控制，其实本质上就是个Git的使用问题。框架本身不提供版本管理功能，得靠外部工具来搞定。下面这套流程，算是团队协作里比较成熟、也踩过不少坑之后总结出来的做法，你可以参考一下。

1. 准备工作：装好工具再出发

要在Linux上跑起来，第一步就是把Git和Composer这两位“大管家”请进系统。Git管代码版本，Composer管第三方依赖，缺一不可。

# Ubuntu/Debian安装Git
sudo apt update && sudo apt install -y git
# CentOS安装Git
sudo yum install -y git
# 安装Composer（全局可用）
curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
# 配置国内镜像（加速依赖下载）
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

这里有个小提醒：Composer的国内镜像能极大提升依赖安装速度，尤其是刚开始搭建环境的时候，能省下不少等待时间。

2. 初始化Git仓库

工具就绪，进入你的ThinkPHP项目根目录——就是那个包含app、public、runtime等核心文件夹的位置，然后执行初始化命令：

cd /path/to/your/thinkphp_project
git init

就这么简单，一个隐藏的.git文件夹就生成了，所有版本控制的“黑盒操作”都将在它里面发生。

3. 配置.gitignore文件（这一步很关键）

不是所有文件都需要被Git“盯上”。比如运行时生成的临时文件、Composer下载的依赖包、用户上传的图片、以及包含数据库密码的.env配置文件。这些如果一股脑提交到仓库里，要么是浪费空间，要么是泄露敏感信息，非常不专业。

所以，在项目根目录创建或编辑.gitignore文件，把下面这些内容加进去：

# 运行时生成的临时文件
/runtime/*
# Composer依赖目录（仅提交composer.json和composer.lock）
/vendor/*
# 用户上传的文件
/public/uploads/*
# 环境配置文件（包含敏感信息，如数据库密码）
.env
# IDE/编辑器生成的配置文件
.idea/
.vscode/
# 日志文件
*.log

需要特别注意的是，composer.json和composer.lock这两个文件是需要提交的，它们记录着项目的依赖信息和精确版本号，是团队协作时保证环境一致的“定海神针”。但vendor目录本身不能提交，因为它是通过Composer安装生成的文件，拉取代码后运行composer install就能自动还原。

4. 首次提交项目代码

现在，把项目文件添加到Git的暂存区，并打上第一个版本标签：

# 添加所有未被.gitignore忽略的文件
git add .
# 提交并添加描述性信息
git commit -m "Initial ThinkPHP project setup"

这一步之后，你的项目就有了第一个“快照”，可以随时回溯到这一刻。

5. 关联远程仓库（强烈推荐）

本地仓库虽然自成一派，但要想备份代码、团队协作，还是得把它挂到远程仓库（比如GitHub、GitLab、Gitee）上。操作也很直接：

# 替换为你的远程仓库URL（如GitHub）
git remote add origin https://github.com/yourname/your_thinkphp_project.git
# 推送代码到远程主分支（如main/master）
git push -u origin main

推送完成后，你的代码就在远程有了一个“娘家”，再也不怕本地硬盘出问题了。

6. 分支策略：团队协作的灵魂

说到协作，分支策略是绕不开的话题。这里有两种主流的玩法，你可以根据团队规模和项目节奏来选择：

• Git Flow（适合大型项目）：流派分明，分支众多（main、develop、feature、release、hotfix），流程严谨但稍显繁琐。
• GitHub Flow（适合中小型、快速迭代项目）：大道至简，只保留一个main分支，始终保持可部署状态。所有开发从main拉出feature分支，通过Pull Request（PR）审查后再合并回来。

举个例子，如果要开发一个用户登录功能：

git checkout -b feature/user-login

就这样，一个新功能分支就创建好了，可以安心地在上面写代码，不会影响主分支的稳定性。

7. 提交与同步规范

• 定期提交：每完成一个小功能或修复一个bug，就提交一次。提交信息要清晰明了，让别人一看就知道你干了什么。比如git commit -m "Fix user login validation error"。
• 同步远程代码：在开始新任务之前，记得先从远程拉取最新代码：

git checkout main
git pull origin main

这个习惯能有效避免很多冲突问题，把问题消灭在萌芽状态。

8. 冲突解决：遇到问题不慌张

多人协作，冲突是难免的。当Git无法自动合并时，它会在冲突文件中用<<<<<<<、=======、>>>>>>>这些标记告诉你“这里有问题”。正确的处理流程是：

# 查看冲突文件
git status
# 手动编辑冲突文件（删除标记，保留正确代码）
# 标记冲突已解决
git add conflict_file.php
# 完成合并
git commit

别怕冲突，它其实是Git在帮你确保代码质量。手动解决冲突时，仔细核对逻辑，跟相关同事沟通一下，基本就没什么大问题了。

9. 标签管理：给版本刻个里程碑

当你完成一个版本发布时，可以用标签打上一个标记，方便日后准确定位和回滚。推荐使用附注标签，它能包含更多信息：

# 创建附注标签（-a表示附注，-m添加描述）
git tag -a v1.0.0 -m "ThinkPHP project release version 1.0.0"
# 推送标签到远程仓库
git push origin v1.0.0

有了标签，后续部署或者bug回溯时，就能很清楚地知道哪个版本对应着哪段代码。

10. 依赖与环境管理

• 依赖安装：团队成员拉取代码后，第一步就是运行composer install，它会根据composer.lock文件安装完全一致的依赖版本。这才是团队环境一致的保障。
• 环境配置：推荐的做法是，把.env文件从版本控制中排除，但提供一个.env.example作为模板放在仓库里。团队成员复制该模板为.env，然后填入自己的本地环境信息（如数据库连接）。这样一来，既保证了灵活性，又不会泄露敏感信息。

按这套流程走下来，ThinkPHP项目在Linux环境下的版本控制就算是上了正轨。代码安全、团队协作顺畅、版本清晰可追溯，这才是专业开发应该有的样子。