[git] github管理项目之环境依赖管理

导出依赖到 requirements.txt

pip install pipreqs pipreqs . --encoding=utf8 --force

但是直接使用pip安装不了torch，需要添加源！！

pip install -r requirements.txt -f https://download.pytorch.org/whl/torch_stable.html

想到一个麻烦的解决方法

1. 先conda env export > environments.yml导出环境
2. 然后把conda部分和pip部分分开，pip部分放进去 requirements.txt 里面
3. 然后再手动安装

# please run these commands manually in your terminal conda env create -f environment.yml conda activate Multi-OSCCPI pip install torch==1.13.0+cu116 torchvision==0.14.0+cu116 -f https://download.pytorch.org/whl/torch_stable.html pip install -r requirements.txt

python 项目中 setup.py 文件的作用是什么

参考：

1. https://zhuanlan.zhihu.com/p/276461821

包分发的始祖：distutils

distutils 是 Python 的一个标准库，从命名上很容易看出它是一个分发（distribute）工具（utlis），它是 Python 官方开发的一个分发打包工具，所有后续的打包工具，全部都是基于它进行开发的。distutils 的精髓在于编写 setup.py，它是模块分发与安装的指导文件。

如果一个项目使用python setup.py install来安装依赖，那么这个项目的安装方法是通过源码安装。相反，与之对应的是通过二进制软件包的安装。

• 这里整个项目都是一个包！

分发工具升级：setuptools

setuptools 是 distutils 增强版，不包括在标准库中。其扩展了很多功能，能够帮助开发者更好的创建和分发 Python 包。大部分 Python 用户都会使用更先进的 setuptools 模块。

distribute，或许你在其他地方也见过它，这里也提一下。

distribute 是 setuptools 有一个分支版本，分支的原因可能是有一部分开发者认为 setuptools 开发太慢了。但现在，distribute 又合并回了 setuptools 中。因此，我们可以认为它们是同一个东西。

因此，setuptools 是一个优秀的，可靠的 Python 包安装与分发工具。

源码包与二进制包什么区别？

Python 包的分发可以分为两种：

1、以源码包的方式发布

源码包安装的过程，是先解压，再编译，最后才安装，所以它是跨平台的，由于每次安装都要进行编译，相对二进包安装方式来说安装速度较慢。

2、以二进制包形式发布

二进制包的安装过程省去了编译的过程，直接进行解压安装，所以安装速度较源码包来说更快。

由于不同平台的编译出来的包无法通用，所以在发布时，需事先编译好多个平台的包。

二进制包的常见格式有：

eggs 与 wheels 有什么区别？

Egg 格式是由 setuptools 在 2004 年引入，而 Wheel 格式是由 PEP427 在 2012 年定义。Wheel 的出现是为了替代 Egg，它的本质是一个zip包，其现在被认为是 Python 的二进制包的标准格式。

以下是 Wheel 和 Egg 的主要区别：

• Wheel 有一个官方的 PEP427 来定义，而 Egg 没有 PEP 定义
• Wheel 是一种分发格式，即打包格式。而 Egg 既是一种分发格式，也是一种运行时安装的格式，并且是可以被直接 import
• Wheel 文件不会包含 .pyc 文件
• Wheel 使用和 PEP376 兼容的 .dist-info 目录，而 Egg 使用 .egg-info 目录
• Wheel 有着更丰富的命名规则。
• Wheel 是有版本的。每个 Wheel 文件都包含 wheel 规范的版本和打包的实现
• Wheel 在内部被 sysconfig path type 管理，因此转向其他格式也更容易
• wheel 包可以通过 pip 来安装，只不过需要先安装 wheel 模块，然后再使用 pip 的命令。

如何编写setup.py文件？

暂时不那么重要。。。

参与项目开发之后如何管理分支？

🚀 完整操作流程（从克隆后开始）
假设你已经克隆了仓库：

git clone xxx cd ai-backend

1️⃣ 确保本地 deploy/test 是最新代码

git checkout deploy/test # 切换到测试分支 git pull origin deploy/test # 拉取远程最新代码

2️⃣ 基于最新的 deploy/test 创建你的功能分支
分支命名规则：feat/你的名字/功能（例如你的名字是 zhang，功能是 add-login）：

git checkout -b feat/zhang/add-login

创建分支git branch feat/zhang/add-login
删除分支git branch -d feat/zhang/add-login
现在你已经在自己分支上了。

3️⃣ 进行开发、提交
开发你的模块，完成后：

git add . # 添加所有修改（或指定文件） git commit -m "feat: 增加登录模块" # 提交信息要清晰

可以多次提交，每次都要写清楚做了什么。

4️⃣ （可选）开发期间同步 deploy/test 的更新
如果你的功能开发时间较长，期间同事可能往 deploy/test 推送了新代码，为了避免最后合并时冲突太多，可以随时把他们的更新拉到自己分支：

git pull origin deploy/test # 把 deploy/test 的新代码合并到当前分支， # 如果有冲突，解决后 git add . 再 git commit

5️⃣ 功能开发完成，合并到 deploy/test

git checkout deploy/test # 切回 deploy/test git pull origin deploy/test # 再次拉取最新（确保合并前是最新的） git merge feat/zhang/add-login # 把你的功能分支合并进来

如果提示冲突，解决冲突（编辑冲突文件 → git add . → git commit）。

6️⃣ 推送 deploy/test 到远程仓库

git push origin deploy/test

推送成功后，Coolify 会自动检测到 deploy/test 分支更新，并开始部署到测试环境。

7️⃣ （可选）推送你的功能分支到远程（备份）
虽然 leader 没说必须推，但建议也把你的功能分支推送到远程，方便其他人查看或备份：

git push origin feat/zhang/add-login

注意！ 如果担心搞坏了 deploy/test，那么就最好采用提PR的方式合并。

（1）方式一：直接合并推送

• 操作：本地完成开发 → 合并到 deploy/test → git push origin deploy/test
• 耗时：几乎为零，推送后立即触发部署。
• 适用场景：小型团队、快速迭代、开发分支（deploy/test）允许直接推送。

（2）方式二：提 PR 再合并

• 操作：将功能分支推送到远程 → 在 GitHub 上创建 PR → 等待 review → 由 reviewer 合并或自己合并
• 耗时：取决于 review 速度，可能几分钟到几天。
• 适用场景：需要代码审查、多人协作、保护主分支（如 main）。

不对！！！应该基于prod进行开发！！！那我上面基于 deploy/test 开发的内容进行了备份之后，我要重新把 /dev/xxx/memory 改到指向 deploy/prod 。

一步到位的修复：

git checkout deploy/prod # 先回到 deploy/prod git branch --set-upstream-to=origin/deploy/prod deploy/prod git fetch origin # 拉远端信息 git reset --hard origin/deploy/prod # 强制对齐远端， ★ 这里会丢掉 deploy/prod 上的未保存内容/本地提交 # 现在 deploy/prod == origin/deploy/prod

这个时候 deploy/prod 已经跟上游对齐了？

git checkout dev/pigeong/memory git reset --hard deploy/prod # 把dev分支对齐回prod， ★ 这里会丢掉 dev/pigeong/memory 上的未保存内容/本地提交