-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs for new git persistence mode #222
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
--- | ||
title: Git projects and persistence | ||
description: 'How persistence works in the StackBlitz editor for Git repositories' | ||
og_image: what-is-codeflow.png | ||
--- | ||
|
||
# {{ $frontmatter.title }} | ||
|
||
The StackBlitz editor has some differences with respect to _persistence_ (whether and how we store your changes) between _projects_ and Git repositories. | ||
|
||
## Default mode | ||
|
||
In its default mode, the StackBlitz editor **does _not_ store your changes** when you open a Git repository (for instance, https://stackblitz.com/~/github.com/vitejs/vite). You can edit files, create new commits and push them to a remote. However, any intermediate changes that are not pushed will be lost after reloading the page. The editor shows a prominent warning to remind you when persistence is off. | ||
|
||
This is in constrast with _projects_, which always keep your changes stored in the StackBlitz backend. The rough rationale for this difference in behavior is that, for Git-based projects, the ultimate goal is to push some new changes into a remote that already exists. This remote ultimately acts as your storage. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. repeated use of |
||
|
||
## Persistence in Git repositories | ||
|
||
As a convenience, the StackBlitz editor _does_ persist your changes in some scenarios, even when working on Git repositories. The "rules" are: | ||
|
||
* You should be logged in, and | ||
* You should have push permissions for the repository, and | ||
* You should not be working on the default branch. | ||
Comment on lines
+21
to
+23
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
These conditions should enable you to leverage persistence in the commmon use case of working on a feature branch, either in a repository of yours or a fork of a project that you want to contribute to. | ||
|
||
The last condition is not as strict as the others: when you are in the default branch, you can opt-in into persisting your changes. | ||
|
||
We might relax these conditions on the future and enable persistence in more scenarios. | ||
|
||
## Branching model | ||
|
||
For Git-based projects, the StackBlitz editor establishes a one-to-one relation between your URL and the branch that you are working on. You can create new branches, push them to a remote, etc. But working on a different branch, that is, in Git parlance, _checking out_ a different branch requires you to **navigate to its corresponding URL**, in your current tab or a new one. | ||
|
||
For instance, if you open the repository for these docs, you would go to | ||
|
||
> https://stackblitz.com/~/github.com/stackblitz/docs. | ||
|
||
If you change branches through the branch picker or the editor command `Checkout to...`, you will be prompted to navigate away to the corresponding URL, for instance | ||
|
||
> https://stackblitz.com/~/github.com/stackblitz/docs/tree/foobar | ||
|
||
for a branch named `foobar`. | ||
|
||
## Merging conflicts | ||
|
||
If you work on a certain branch and persistence is enabled (as described above), the StackBlitz editor stores your intermediate changes not yet pushed to a remote. If you open the same branch at a later point, new commits from the remote could conflict with your stored changes. When this happens, the editor presents several ways to deal with this situation: | ||
|
||
* Discard your old changes and start working fresh again from the latest commit. | ||
* Push your ongoing changes to an intermediate branch and create a pull request. | ||
Comment on lines
+49
to
+50
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if the convention from the previous list was followed, should the first item here end with I suppose the previous |
||
|
||
We are looking into enabling more sophisticated conflict resolution strategies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems inconsistent to italicise projects, but not Git repositories