about

docs

pricing

oss

consulting

Appearance

Developing with Floro


Page:
/development


Overview

It's very easy to over-analogize floro to something like git. Admittedly when we built floro, we wanted to copy the commit -> pull-request -> merge flow that we thought was missing for content. This flow has a major fatal flaw in developer experience though.

The Problem

If you are using floro while writing code in tandem and adopting this approach, then you have to first create a branch in git, next you have to open a branch in floro. Then you develop your feature in tandem with floro BUT you can't push your code branch to git until you first commit your floro branch and create a merge-request for it in floro.

Then you have to have your merge-request peer reviewed before it can be merged into the main floro branch. Then you can finally push your code branch to git, which can now sync against the remote floro main repository. This is way too much friction in our opinion and exactly the opposite of the problem we were trying to solve with floro.

The Solution

Don't make developers use branches in floro, let them push directly to main.

You can use roles and branch rules to enforce that anyone else interacting with floro (e.g. translators, copy-editors, designers) has go through the traditional peer-review merge flow, but we highly recommend not forcing engineers into this flow. You can also employ static analysis techniques (as shown in the demos) to guarantee that you won't break production by pushing directly to main.

What about conflicts though?

The truth is that everyone is already on their own branch on their own computer. You'll still get conflicts and be able to resolve them when you pull (pulling attempts to automatically merge for you). The only difference between this approach and forcing a peer-reviewed approach, is that conflicts are resolved locally. Any user with direct push access is also notified when they are attempting to force push.

Who does this not work for?

If your organization has low trust of its engineers then this is probably not an ideal solution for you. In that case you may be better off making engineers spec their floro changes before developing their code features. It is a version control system though, so in your worst case scenario you can always roll-back a bad change.