Changes are wiped every time the owner opens a project connected to Github

[FossPrime]

Description of Bug

Creating a new Git repo for a project does not warn the user of hard pulls. This means a team of 5 could work on a project for a week, and as long as the owner doesn't open the project everything will look fine. Only the true owner has the ability to commit to Git/Github.

What happens next is tragic, the owner will open the project and Stackblitz will HARD pull without asking and delete all changes made by other people in your team. No version history will be available all progress and data will be lost. This is an Integrity security and Accessibility security issue.

Steps to Reproduce

1. Create a new Stackblitz project
2. Connect new GitHub repository
3. Close your project
4. Share your Stackblitz project with awesome developers
5. Have them work on your project and click save
6. After they've saved changes and are happy with the work, open the project as the owner

Expected Behavior

No data loss

Additional Comments

What's the point of Co-owner and Editor roles if ultimately nothing can be saved by anyone but the owner, and even then that's only IF they have the project open at the same time as someone else is making changes to it. I do appreciate the direct push functionality, and the option to do HARD force pulls, but that should not be the default auto-start action.

[kc0tlh]

This issue is resolved in our new VS Code editor!

1. We have added Undo (CTRL + Z and CMD + Z)
2. Changes are stored in browser cache in case the page is closed without saving
3. Github is now fully and properly supported for Version Control(see Github issue Export and import to github, gitlab or pagure. #2473 for more info)

[FossPrime]

The experience is still not good.

1. Co-worker makes a change in Stackblitz and saves to Stackblitz (Github is not an option for saving when looking at a shared Stackblitz project)
2. Project owner opens stackblitz project, gets old version from github, no warnings or anything.

The owner has to magically know there was a change, and where there was a change, for Ctrl+Z to work. Manual pull and normal-ish git commands would fix this.