问题描述
在设置一个全新的项目时，考虑使用何种工具来存储构建产物（在此例中为 APK 文件）。他们在讨论是否可以直接使用 Bitbucket 来存储构建产物，以减少所需安装和维护的工具数量。用户希望了解不适合在 Bitbucket 中存储构建产物的原因，以及是否会在以后的工作中面临一些问题。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
使用 Bitbucket-server 作为构建产物存储库可能并不是最佳选择，以下是一些原因：
-
Git 是源代码管理工具：Bitbucket 作为 Git 仓库的管理工具，其主要设计目的是用于版本控制和管理源代码。虽然有一些扩展如 Git LFS 可以用于管理大文件，但这不是 Git 的核心功能，且可能会导致一些性能和管理上的问题。
-
大二进制文件占用大量存储空间：Git 本身无法有效地处理大型二进制文件，因此如果构建产物是经常生成的大型二进制文件（如 APK），那么这些文件将会占用大量存储空间，不仅会影响仓库的性能，还可能导致仓库变得臃肿难以管理。
-
历史记录管理困难：Git 设计时注重历史不被丢失，但这也意味着如果你后期决定删除旧的、长时间不再使用的构建产物，会变得非常困难。Git 会保留这些文件的历史记录，需要额外的工具和步骤来执行删除操作。
-
构建产物的语义不适用于 Git：构建产物的概念与 Git 的“提交”不匹配。构建产物需要上传和下载操作，这与 Git 的版本控制并不一致。构建工具（如 Ruby 中的 bundler 或 Java 中的 Maven）能够从构建产物存储库中轻松获取第三方库，并上传新的版本。如果强制使用 Git 作为下载存储库，你需要自己开发工具，手动指定要在哪个提交中找到那个二进制文件，或者在本地检出所有用过的二进制文件。上传到 Git 存储库也需要自己开发工具，可能会导致创建不必要的提交。
综上所述，将 Bitbucket-server 用于构建产物存储库并不是一个合适的选择。如果你的同事担心增加类似 Nexus 这样的复杂工具，那么至少也要说服他们使用一个简单的工具，而不是 Git，比如在某个虚拟机上搭建的 (s)ftp 或 scp 存储库，通过一个简单的 Web 服务器提供 https 访问。
如果非要使用 Git，至少确保构建产物不与源代码一起提交，而是放在它们自己的历史记录部分。可以参考这个旧的回答来了解如何创建一个孤立分支，这样这些构建产物可以在需要的时候被删除，而不是每个客户端都被强制下载所有的构建产物。
示例
以下是一个存储构建产物的 Git 仓库结构的示例：
project-root/
├── src/
│ ├── ... (源代码)
├── build-artifacts/
│ ├── v1/
│ │ ├── artifact1.apk
│ │ ├── artifact2.apk
│ ├── v2/
│ │ ├── artifact1.apk
│ │ ├── artifact2.apk
在这个示例中，构建产物被放在 build-artifacts 目录下，每个版本都有一个独立的子目录。这样就可以在需要的时候删除旧版本的构建产物，而不影响其他客户端。