How to develop discourse in a team?

Hello everyone. I ran into a problem while developing discourse

I usually clone files from Git
Making changes
Making a commit on Git

My teammate does a git pull
And gets all my changes

How can I implement something similar in discourse?
How can I make changes so that other people can install them at home?

If you are developing a Discourse theme or a plugin, either can live in a Git repository just fine.


Thanks for the reply. Yes, you are right about the topic. What about the synchronization of components and settings?

Your plugin code can define migrations and/or seed contents as necessary. They can also ensure that site settings have the appropriate value.


I want to clone my installation completely

You can take a backup and restore where needed.

1 Like

I tried it. I get an error when restoring
The copy does not appear in the list after even 30 minutes

I like to use S3 for backups and then all sites can share the same backup set. Then when you do a backup on production, you can immediately restore it on your staging sites to see that it works with the current data.

1 Like

What it is S3? I would like to use this

1 Like

Using Object Storage for Uploads (S3 & Clones) Setting up file and image uploads to S3 are where to start. For backups only its quite simple.

Backblaze and wasabi are cheap. Also has a product that I’ve used for backups.

Just my 10 cents, and not to take away from the helpful comments here on backups, but stepping back a bit: I’m really not sure if ‘synchronising’ installs of Discourse is worth much effort.

Unless you intend on PRing into Discourse core, developing plugins or TCs is where it’s at and gives you the most robust, efficient solution for customisation.

The key thing with developing Plugins and Theme Components is they will be deployed to multiple instances of Discourse over which you may not have control in any case?

So having a slightly unique local Discourse instance for development is totally ok. (within reason)

The key workflow should involve keeping the plugin or TC up to date in a shared repo, most likely on Github.


I totally agree. I have a few clients with customizations that can’t be checked (or are easiest checked) against their actual data, so they really like to see the site with the current data.

1 Like

Yes, that’s fair. It depends what you are trying to do and what the client base is (single target, or multiple customers?) and how much control you expect to have.

1 Like

Thank you all for your advice. Most likely, I will use PRing into Discourse core. Therefore, I need the ability to upload the assembly to the git, and from the git to the server

If you are PRing to Discourse core, then again, exact config of local install not critical (just make sure you are on latest), because code contribution is a very controlled process anyway, especially with test cases., so a little variation in settings or content is unlikely to be an issue.

Normally, if working on joint contributions, you’d fork to your org’s repo and work on there before PRing?


No, I not working on joint contributions. I work for personal use

I didn’t to put it that way
How can I install a discourse from a fork of the git?
I will make changes into Discourse core and add them to my repo on git

So I’m confused why you need to sync your installations?

Just git clone your fork.

Normally you would not use docker for development but if you are you can enter your container and check out your fork.

1 Like

For example.

Now I have Discourse configured
Then, when everything is ready, I update my build.

Then I continue the development again. I’m changing some settings in the control panel. There can be a lot of them.
When I want to update my build, I will need to update the settings as well

In this case, I will have to manually set the settings

Settings are persistent, and you are working alone, so why the need to focus on backup/sync?

(also the title of the Topic is confusing then, why “in a team”?)

When you clone or checkout you do not wipe the database (where the settings are held).

You are in control of when to run migrations (if any exist). Otherwise the DB should be stable.

1 Like