> For the complete documentation index, see [llms.txt](https://sygnal.gitbook.io/sygnal-webflow-components/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sygnal.gitbook.io/sygnal-webflow-components/cc/technical-notes/sygnals-code-components-development-framework/feature-branches.md).

# Feature Branches

Sygnal's preferred approach is to branch feature development to keep `main` clean and allow for freedom of experimentation and Webflow designer testing.&#x20;

{% hint style="success" %}
Typically we name our feature branches using the convention **feature/NAME**.&#x20;
{% endhint %}

## Creating a Feature Branch

Create your new feature branch, e.g.;&#x20;

```
git checkout -b feature/NAME
```

## Working with a Feature Branch

In VSCode, you'll see the currently selected branch in the bottom-left corner;

<figure><img src="https://2784689242-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fijt1q5GHhhw4y4FjjPNG%2Fuploads%2FcVRr7dJXdC3UHPBITg95%2Fimage.png?alt=media&amp;token=86f714c3-7eb3-49ee-b5c1-1ee073253433" alt=""><figcaption></figcaption></figure>

## Designer-Testing a Feature Branch&#x20;

{% hint style="danger" %}
First, verify you're on the correct feature branch.
{% endhint %}

```
npm run deploy
```

Will deploy the lib to your designated workspace, but as a Test version;

* The Library name will end in `Test`&#x20;
* The Library ID with a `-test` suffix&#x20;

{% hint style="success" %}
Sygnal's deployment setup is branch-aware and distinguishes between `main` and non-`main` branches.  Any deployment of a non-`main` branch will be handled as a Test lib.  In this setup, you can have only one Test lib at a time, so if you're developing multiple features, you can integration one at a time.&#x20;
{% endhint %}

In the designer, you'll see your library as e.g. `My Library Test v1.0.0 ⚠️`&#x20;

Install or update that library in your test project.&#x20;

Add any components you want- it will&#x20;

## Merging a Feature Branch into Main&#x20;

{% hint style="warning" %}
This outlines the basic process; make sure that if you're working in a team, that you use `git pull origin` to update your local copy.&#x20;
{% endhint %}

> In general we want to keep feature branches clean- so that they only contain the new component(s) you're building or refactoring. &#x20;

<details>

<summary>Advanced Merge Notes </summary>

{% hint style="warning" %}
If you've made extensive changes that could create conflicts look into `git cherry-pick` .  &#x20;
{% endhint %}

Start from your feature branch, e.g.&#x20;

```
git checkout feature/NAME
```

Make sure everything is committed;

```
git status
```

See commits that aren't on main;

```
git log --oneline main..feature/rive
```

See which files have changed;&#x20;

```
git log --oneline main..feature/rive
```

Examine detailed file changes if you want;&#x20;

```
git diff --stat main..feature/rive 
```

Switch to the main branch;&#x20;

```
git checkout main
```

</details>

### Merging

In most cases we prefer to preserve branch history.&#x20;

{% hint style="warning" %}
Replace NAME with the actual feature name. &#x20;
{% endhint %}

From the `main` branch,&#x20;

Update the version number in `src/version.ts`&#x20;

Perform the feature branch merge, e.g.;&#x20;

```
git merge --no-ff -m "Merge feature into main" feature/NAME
```

Then, usually cleanup by removing the feature branch;&#x20;

```
git branch -d feature/NAME 
```

<details>

<summary>Some alternative merging approaches </summary>

You may also be able to fast-forward merge;

```
git merge feature/NAME
```

Or squash merge ( combine all commits into one );&#x20;

e.g.;

```
git merge --squash feature/NAME
git commit -m "Add new component"
```

</details>

### Final Integration Review &#x20;

With the feature now merged into `main`, retest to ensure the integration was successful.&#x20;

Update the version.ts to reflect the new library version.  This will be important for marketplace users, and for multiple-workspace distributions.&#x20;

Deploy `main` to your testing workspace.&#x20;

```
npm run deploy
```

From `main`, this will deploy the library under its proper name, without the Test suffix.&#x20;

Retest.&#x20;

In the designer, accept the library revisions from the library panel.&#x20;

* Replace your Test library components with the production library components.&#x20;

You can see both libraries, the test and the prod versions;&#x20;

<figure><img src="https://2784689242-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fijt1q5GHhhw4y4FjjPNG%2Fuploads%2FOSmeAdGB0gXaoOiDZDj9%2Fimage.png?alt=media&amp;token=3a50ea89-9211-477d-ab15-061fff7654ef" alt=""><figcaption></figcaption></figure>

Important, currently there is no way to distinguish in the designer between test and production component versions, they will look identical in the left nav, and in the properties list during this replacement process.&#x20;

To simplify this, select the old component, add the new one and it will position directly after.  then copy-past your property settings.&#x20;

<figure><img src="https://2784689242-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fijt1q5GHhhw4y4FjjPNG%2Fuploads%2FsgCKWi1umQZTP92XxlZa%2Fimage.png?alt=media&amp;token=82608b6d-0074-424c-9c2f-759cdd408126" alt=""><figcaption></figcaption></figure>
