No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

&gt; Unfortunately, I get merge conflicts in my state file.

You do not check in your state file.  That is managed by <http://app.pulumi.com|app.pulumi.com> by default, or you can manage it in cloud storage directly.  <http://app.pulumi.com|app.pulumi.com> additionally offers robust concurrency control around modifications, so only one of you can be changing the stack at a time.

&gt; We both develop against the local
copies of the stack file we have on our branches

The most common approach here would be to create a fresh stack from the same project with your feature branch testing, and develop in that.  Then, when you open a PR against your shared branch (`master`), have either CI/CD or a manual process do an update of the shared stack associated with that branch (`production`).

As a general rule, thinking of stacks as roughly 1:1 with "long lived branches" is a good starting point.

There's some notes on this topic at <https://www.pulumi.com/docs/reference/cd/#using-branches-for-environments> that may be helpful.

Also <https://www.pulumi.com/docs/reference/organizing-stacks-projects/>.

<@ULX8829QD> we maintain our state in git (separate repo to the actual code), but we have infra around it to make sure it's always at the latest revision before doing anything, and to make sure that no concurrent runs are possible for a particular stack. it's a bit of a pain though, i probably wouldn't recommend doing it unless you have to.