New branch (created in GitHub) not detected by BL

[kaelig]

📖 Reproduction steps

1. In BL, open a design system connected to a GitHub repository
2. In GitHub, make a change, use branch name new-branch and create a PR directly from its UI
3. In BL, look for new-branch in the list of branches

🙁 Current Behavior

I can't see new-branch in the list, even after a full browser refresh or a hard reset from the git sidebar.

🙂 Expected Behavior

I can see new-branch in the list.

🔗 Link to the design system

No response

🌐 What browser(s) are you seeing the problem on?

Chrome

Browser version(s)

No response

[bashmish]

I think I can relate to why it seems like a bug, in my first days at divRIOTS I had a similar expectation about syncing of branches.

This is how it's working right now. We designed a different workflow for Local branches (created using Git directly) and Live branches (created from the Backlight UI). Live branches are displayed under Branches tab.

Local branches require CLI's syncing from a local dir, which means you can't do it via GitHub UI. From a local dir you can checkout a branch and run CLI's backlight serve %ds_id%. Then this branch will appear in the UI in the Local tab:

You can transform a Local branch to a Live branch, basically fork it in the UI by clicking "+ Branch".

I think we should clarify the names in the UI, because if you are looking for branches and see Branches tab, you might indeed never think there are other branches somewhere else. Not sure why we renamed Live branches to just Branches in the UI.

@m4dz I remember some time ago we wanted to explain these workflows in the docs, using videos or so, wdyt?

@georges-gomes maybe it's smth for GitHub app to consider syncing automatically? I'm not sure what was the plan, but I can relate to this expectation as a first time user, so maybe it can be a good thing to add/configure.

[kaelig]

Thank you for the context! 🙌🏻

This brings up an interesting point: the integration with GitHub seemed really seamless and set the expectation that branches and PRs were going to be in sync between GitHub and Backlight!

[m4dz]

@m4dz I remember some time ago we wanted to explain these workflows in the docs, using videos or so, wdyt?

You're right! Also because I had the same wondering few days ago and can't recall the right to do so 😅. Let me add it to the road map for the on boarding feature, and reuse the video in the doc.

@georges-gomes maybe it's smth for GitHub app to consider syncing automatically? I'm not sure what was the plan, but I can relate to this expectation as a first time user, so maybe it can be a good thing to add/configure.

👍

[georges-gomes]

I don't know how I feel about syncing all branches of the repo with backlight... but if we use the new "load from GitHub" of @muryoh then we can have a readonly list of "Remote" branches setup yes 👍

[muryoh]

Technically possible yep, but wouldn't we want to integrate them with "live" branches? I mean:

• live branches are meant to have a remote counterpart when pushed, so if a branch already exists there with the same name the user will run into the problem late
• users probably have some expectations when a live branch has been pushed to git and the remote branch is being modified

We could associate the live branch to the user based on who pushed that new branch

[bashmish]

Git has a concept of remote-tracking branches. Maybe we can make use of it to achieve what users need. Since Git is a distributed system, I now feel like the automatic syncing is a bit against Git principles. So instead of automatic, I see some benefits in the @muryoh 's idea of associating branches explicitly. And to clarify: I mean associating them with the GitHub repository branch (in contrast to associating Live->Local which is a bad idea IMO). And this behavior should be an opt-in and per branch. I also don't see much issues with the naming. In Git you can have any name locally and track a completely different branch name in the origin, so that's a matter of configuration.

At the same time, things are getting more and more complex with all these things. So instead of doing complex workflows, I'd rather focus now on providing more learning material to existing workflows. Since I started using Backlight, I never actually ran into the limitations of the current workflows, it just took some time to understand them.

[kaelig]

If you'd prefer to keep the current workflows, it'd be good to make it extra clear in the UI that BL branches ≠ GH branches. At the moment it's confusing because the two concepts are sometimes equal (for example, with the main branch), but not all the way.

[bashmish]

If you'd prefer to keep the current workflows, it'd be good to make it extra clear in the UI that BL branches ≠ GH branches. At the moment it's confusing because the two concepts are sometimes equal (for example, with the main branch), but not all the way.

Yep, UI improvements should clarify it too.

About the main branch

Local main behaves exactly like any other local branch: you serve it with the CLI and can open from the Local branches tab only, it doesn't impact the Live main branch (or any other Live branches) in any way. Local branches are pretty isolated from anything else.

Live main branch has only one special behavior (as compared to other Live branches): it auto-syncs with GitHub and AFAIK only when GitHub app is active, that's probably what you meant.

[kaelig]

Gotcha, note that I haven't used the CLI yet, and wasn't planning to do so, but I'll look into it for my next pairing session with @m4dz!