This article discusses how to maintain and manage frontend branches in the AI-Commerce-Svelte repository according to agile software development principles. You will get instructions on how automatic merges of changes to the main branch work, when to create a completely new component version and with what name, and how to avoid unnecessary conflicts by, among other things, preserving CSS indentations.

Introduction

• Each frontend project (tenant) of AI Commerce platform is in its own branch, and they all share a common main branch.
• The Main branch acts as a central production branch, from which all core code updates are automatically distributed to other branches.
• This means that, for example, a bug fix for one component only needs to be made once, after which it can be automatically imported into all stores.
• The tree-shaking feature in Svelte development ensures that unnecessary components are dropped already at the compile stage, but if necessary, "reserve components" can still be kept in the branch for future needs.

Key operating principle

1. Common main branch
   • Includes all basic components and core code.
   • When a fix or new feature is made to the main branch, an automatic bash script is run from it that updates the changes to all branches. This script is run manually by AICC core developer team in intervals.
   • Any conflicts to heavily customized components must be resolved manually by a developer.
2. Tenant-specific branches
   • Each store has its own branch where they can store or modify only the components they need.
   • In some cases, an alternative component version is removed or omitted altogether if it is not needed (e.g., only ProductConsumerPrices.svelte is in use, so ProductBusinessPrices.svelte is removed from this branch for clarity).
3. Automatic merge script
   • The script skips conflicts where the new component is missing from any branch (i.e. if it has already been removed as unnecessary).
   • The developer only handles situations where an actual change conflict arises.

Creating new component versions

Often changes can be made to the same component without a separate version, especially if they are small JavaScript or CSS tweaks. However, if:

• The changed component is so different that subsequent updates to the main branch could cause ongoing conflicts, or
• The reform brings significant, widely usable added value , but at the same time may break the previous logic,

it makes more sense to create a new component name in the main branch. For example:

• Original component: Footer.svelte
• New, significantly different version: FooterGrid.svelte (uses grid CSS structure instead of flex)

Naming policy rules

• The original name of the component is partially preserved to keep the files in a logical group (e.g. Header -> HeaderTransparent , Footer -> FooterGrid ).
• The name must describe the essential difference of the component; mere numbering (e.g. Footer2.svelte ) is not allowed.
• The AICommerce core development team oversees the naming of components and approves changes pushed to the main branch.

Managing CSS changes

• Reduce unnecessary merge conflicts by preserving CSS lines even if the value changes (e.g., don't remove padding: 20px line entirely, but change it to padding: 0px ).
• This makes the bash script and developers' work easier when it is clear where in the line the changes have been made.

Recommended progression for developers

• First, check whether the changes to the same component are sufficient or whether you need to create a completely new version.
• Ensure the scope and significance of the changes being pushed to the main branch, as well as their potential benefit to other stores.
• Take advantage of an automated bash script that updates fixes made to the main branch to all tenant branches. Just resolve any conflicts manually.
• Follow component naming conventions to keep files organized and to allow for more widespread distribution of usability improvements.

Summary

Managing frontend branches on AI Commerce platform streamlines development: one centralized main branch enables agile updates and fixes that automatically scale to different customer projects. The goal is to minimize duplicate work, avoid conflicts, and still enable continuous development of customizable components. If a component changes fundamentally, it is worth creating a new, clearly named version of it in the main branch – but only when it is necessary for larger changes or added value.