大家好。我在开发 Discourse 时遇到了一个问题。
我通常会从 Git 克隆文件，进行修改，然后在 Git 上提交更改。
我的队友执行 git pull，就能获取我所有的更改。
我如何在 Discourse 中实现类似的功能？
我该如何进行修改，以便其他人可以在本地安装这些更改？
如果您正在开发 Discourse 主题或插件，两者都可以完美地托管在 Git 仓库中。
感谢您的回复。是的，您对这个主题的看法是正确的。那么关于组件和设置的同步问题呢？
您的插件代码可以根据需要定义迁移和/或种子数据。它们还可以确保站点设置具有适当的值。
我想完全克隆我的安装环境。
您可以在需要时进行备份和恢复。
我喜欢使用 S3 进行备份，这样所有站点都可以共享同一套备份集。这样，当你在生产环境执行备份后，可以立即在预发布站点上进行恢复，以验证其是否能与当前数据正常工作。
什么是 S3？我想使用它。
使用对象存储进行上传（S3 及克隆） 和 在 S3 上配置文件和图片上传 是入门的起点。如果仅用于备份，设置过程相当简单。
Backblaze 和 Wasabi 价格低廉。此外，Storj.io 也提供一款我曾用过的备份产品。
这只是我的一点浅见，并非要削弱这里关于备份的有用评论，但退一步看：我实在不确定“同步”Discourse 安装是否值得投入太多精力。
除非你打算向 Discourse 核心提交 PR，否则开发插件或主题组件（TC）才是正道，它们能为自定义提供最稳健、高效的解决方案。
开发插件和主题组件的关键在于，它们将被部署到多个 Discourse 实例上，而这些实例你很可能根本无法控制。
因此，拥有一个稍作定制、用于开发的本地 Discourse 实例是完全没问题的（在合理范围内）。
核心工作流程应是将插件或主题组件保持更新，并托管在共享仓库中，最有可能是在 GitHub 上。
我完全同意。我有几位客户拥有自定义功能，这些功能无法（或最方便）通过实际数据进行验证，因此他们非常希望看到带有当前数据的网站。
是的，这很合理。这取决于你打算做什么、客户群体是单一目标还是多个客户，以及你期望拥有多少控制权。
感谢大家提供的建议。我大概率会将补丁提交到 Discourse 核心代码库。因此，我需要能够将构建产物上传到 Git，再从 Git 部署到服务器。
如果你是为 Discourse 核心代码提交 Pull Request，那么本地安装的具体配置并不关键（只需确保使用的是最新版本即可），因为代码贡献本身就是一个高度受控的过程，尤其是涉及测试用例时。因此，设置或内容上的细微差异通常不会成为问题。
通常情况下，如果是进行联合贡献，你会先 fork 到你所在组织的仓库，在那里开展工作，然后再提交 Pull Request，对吗？
不，我没有在处理联合贡献。我是为了个人使用而工作的。
我并不是那个意思。
我该如何从 Git 的一个分支安装 Discourse？
我会在 Discourse 核心中进行修改，然后将这些更改添加到我的 Git 仓库中。
所以我不明白为什么你需要同步你的安装？
只需 git clone 你的 fork。
通常你不需要使用 Docker 进行开发，但如果你确实需要，可以进入容器并检出你的 fork。
例如：
现在我已配置好 Discourse。
待一切准备就绪后，我更新我的构建。
然后我继续开发，在控制面板中修改一些设置，数量可能很多。
当我需要再次更新构建时，也必须同步更新这些设置。
在这种情况下，我将不得不手动配置这些设置。
设置是持久化的，而且你是在独立工作，那么为什么还需要关注备份/同步呢？
（另外，主题标题也很令人困惑，既然标题是“在团队中”，那为什么这么写呢？）
当你克隆或检出代码时，并不会清除数据库（设置就存储在其中）。
你完全掌控何时运行迁移（如果有的话）。否则，数据库应该保持稳定。