Workflow for collaborating when not everyone is using Glitch

We have a project where the main developer mostly develops locally on his own machine (less latency, etc). But the rest of us want to use Glitch. We have the source code in GitHub.

This is a little fraught because Glitch’s “import from GitHub” feature doesn’t merge changes but overwrites anything in Glitch.

The best workaround we’ve thought of is that, to get everyone’s latest changes merged into Glitch, you first export from Glitch to GitHub, merge the auto-generated pull request, and then import from GitHub. And you have to do those in quick succession because any changes made on Glitch while that’s happening will be overwritten.

Does that sound right? Is there a better protocol? Anything clever we can do in the Glitch console to merge instead of overwrite when getting the latest from GitHub?

we totally want this to be a fully supported flow. In the future, we’ll do that with real github repo syncing (and other version control features like branching).

In the meantime, exported glitch changes and imported gh changes do fully override the project as you mentioned.

I believe they aren’t mergeable like real diffs yet because of file identifier/SHA issues.

1 Like

It seems like exporting from Glitch to GitHub doesn’t overwrite anything, just the import into Glitch. Am I confused about this?

It’s been a while since I’ve done it, we may of fixed that part. It sounds like your existing workflow of having to import from Glitch is the right/only one for now. (unless of course someone else has a better console suggestion)

1 Like

this is exactly how I work around this at the moment - but as @pketh mentioned we are currently working on harnessing the ~power of git~ to improve workflows in glitch!

1 Like

Just bumping this thread because this is still a real pain point for collaboration. I keep having to tell people something like

Don’t ever do “import from GitHub” in Glitch because that overwrites what’s in Glitch. The other direction – “export to GitHub” – is fine. It creates a pull request that can be merged in on GitHub.

And I know eventually we’re going to screw this up and lose work or make a mess.

I did learn how to merge in the other direction (thanks @Gareth!) from the Glitch console. It would be pretty amazing if that was the default, built-in way to get code from GitHub to Glitch.

In the meantime, maybe there could be more of a warning on the “Import from GitHub” option to help guard against losing work? Maybe it could even be smart enough to know when there are changes in Glitch that would be overwritten by that and not let you do it?

Extreme proposal: What if you had to go to the trouble of deleting all the files on Glitch to prove that you really wanted to start fresh from the GitHub version? Annoying in many cases but the alternative I argue is worse: lots of FUD around using both Glitch and GitHub to collaborate. Ie, just having to give the warning above makes it feel to new collaborators like “here be dragons”.

PS: To clarify, I’m complaining so hard because of how completely amazing it is to have Glitch as a medium of collaboration and I want to use it for everything but that’s currently a bit fraught when the primary repository of the source code is GitHub.

Thanks for the feedback, @dreev. When you overwrite a project by importing from GH, you should still have the old code in your git history inside the container. This makes it fairly easy to revert the changes from the console if you’re comfortable with git. I’m in the middle of bringing much better version control support to Glitch right now. Soon you’ll be able to rewind to an earlier version very easily in the UI. I’m also going to revisit GH import as part of that effort.

If you’re seeing GH import blowing the git history away too, let me know and we can dig into it together - that would be a bug, rather than a missing feature.


Ooh, awesome news!

I’m not sure how reassuring it is that you can undo a destructive import, because you wouldn’t necessarily notice right away and so new edits would happen and while it may be an untangleable mess it would still be a mess. So I think I’d still prefer my extreme stopgap solution of not letting the destructive import happen in the first place, until the new version control features are done.

Either way, thanks so much for the update on the progress on these new features. Super exciting!

PS! Wait! Possible epiphany! Could the import-from-GitHub feature atomically also do an export? Like as part of the import operation it would first do an export. That would create a pull request in GitHub that you’re free to reject or ignore if you really did just want to overwrite what was in Glitch. If you didn’t mean to overwrite, no problem. Just merge in that pull request on GitHub and import again!

That’s an interesting suggestion. I’ll flag it up to the team, but sounds promising.

1 Like

I’m not sure if this should be a new topic by now (as opposed to necro’ing this 4-year-old one) but I wanted to renew my pitch for improving the workflow when GitHub is where the master copy of the code lives.

I think the Glitch Powers That Be have long had Grand Plans for doing this the Right Way using the Power Of Git but I think the following adjustment to the import/export functionality could make a night-and-day difference in removing a barrier to developing in Glitch when some of your collaborators are committing directly to GitHub.

To review, I believe that currently it’s just too fraught. In order to be sure I don’t lose work or create a huge mess to be untangled with major git fu, I have to make sure that that any collaborator on Glitch periodically exports their changes to GitHub (so far so fine) and also imports from GitHub occasionally to get the latest changes. This part is not fine. I have to first export from Glitch to GitHub, merge the PR, then immediately import from GitHub to Glitch. If any edits happen in between, they’ll be lost. Plus I don’t trust myself to conscientiously follow that export-merge-import sequence every time.

That workflow means too much apprehension about using Glitch!

Actual Proposal

Make the import-from-GitHub button also automatically and atomically do an export-to-GitHub first.

Imagine: I’m hacking away in Glitch, I want to grab the latest from GitHub, I click import, and boom. I’ve got the latest. What’s that? I forgot to merge in my own changes first and everything I was working on is gone and I have to find some git wizard to go back in time for me? Au contraire! Everything I did is waiting on GitHub as a new PR. I can go merge it and then do another import-from-GitHub and I’m back in business.

The only question is how to title that PR so that it’s clear why it got created and so that I understand that if I did intentionally blow away what I had in Glitch, overwriting it with the latest in GitHub, then I can go ahead and delete that PR as well.

Maybe something like “Automatic PR from Glitch before overwriting via Glitch’s import-from-GitHub feature. Delete me if that overwriting was intentional!”.

Possibly More Principled Proposal

I can imagine a fair objection that the above proposal is too magical – that each button should do exactly what it says and nothing more. If so, here’s a more radical and opinionated proposal: Kill both the import and export buttons and replace them with a single “sync with GitHub” button that does an export-followed-immediately-by-import.

Now the workflow for importing is the same as ever. You hit “sync” and you’ve got the latest from GitHub like normal. The workflow for exporting is more annoying but, crucially, impossible to screw up. You hit “sync” and temporarily lose all your work in Glitch. You have to go merge Glitch’s PR and sync again to be back where you left off on Glitch. You’d want a warning like so:

Syncing with GitHub sends your current updates on Glitch to GitHub as a PR and then overwrites your Glitch project with the latest from GitHub. To get the latest from both, you need to merge the PR on GitHub and then hit this sync button again!

Simplest Proposal

A variant that would likely be the least work and least consternating to existing users would be to add a third button. (I know “just add one more button” is rarely the best answer.) The import button would overwrite what’s in Glitch like normal, the export button would create the PR in GitHub like normal, and a new “sync” button would just do both – create the PR and then blow away what’s in Glitch in favor of GitHub.

Then just make the “import” button red (for danger) and I think everyone would feel safe.

1 Like

I think your proposal is well intentioned but I tend to think “if you want something done, do it yourself”. Not everyone uses GitHub as a repo, so now what multiple buttons? Glitch projects already push to Glitch branch (that can be limiting if multiple devs are working on the same code). Any “dev group” that edits in a live editor that auto restarts the project every few minutes and has no restore functionality gets what they get.

As I’ve posted before, develop offline (VS Code supports collaboration) push to a working branch, have the code reviewed and merged into the main branch and deploy to Glitch by pulling in the latest copy.

If you personally want to use Glitch to test a branch, create another project and pull the code into that. When you are happy with the changes copy them into your branch and go thru the check in steps again. This makes everyone aware of the changes and gives everyone the opportunity for review prior to a release.

I don’t see Glitch as ever being the place where projects are developed, they will be the place that projects run. They will be the place you can edit a line or two of HTML (as I recently did) to hotfix something but then it goes into my local code, is pushed up to GitHub and released officially.

Thanks for this feedback!

I think the workflow you describe defeats the point of the Glitch editor. Developing in Glitch is amazing!

To clarify, if all collaborators are using Glitch then there’s no problem. This is about the case where some are developing in Glitch and others are using VS Code or something else and pushing their changes to GitHub.

I should also highlight where I’m proposing this feature live. Namely:


One more anecdote: the lack of this feature and the fear/uncertainty/doubt about changes getting overwritten has led, in the case of one of our projects, to essentially a rule that no one touches the code in Glitch – Glitch is only for hosting. That is a huge shame and it doesn’t have to be that way, is my point.

Also, to clarify, would my proposal here be actively harmful to any of your own workflows? Or do you just mean that my proposal is unnecessary for your own workflows?

Nothing would cause harm no issue there. I find editing in Glitch to be substantially less than amazing. I haven’t explored everything (probably) but just today I was editing a TypeScript project in VS Code.

Press “Rename Symbol” and the class, method and/or variables throughout the project are adjusted. Rename a file it prompts if you want all the imports changed to match. Plus “Goto Definition”, “Find All References” and others. I click on the Source Control icon and I see I have 16 files that changed. I click compare and I see the files side-by-side, I can edit one side or the other and I can revert the file. Two more clicks and the changes are committed. To me that is amazing.

Oh quick revision but only a “sync” button would turn out to be an issue. The point of checking things into branches isn’t only to “save stuff just in case”. You need a person responsible for the changes that are checked in and they need to supply a reason for having modified the source code.

There also needs to be a way to discard the changes i.e. just import again.

It sounds like you make very “atomic” changes, i.e. relatively discrete adjustments. Some project changes are experimental, some cannot be completed in an hour, some not in a week and having spent a week on it the changes can turn out to be unworkable. If such changes are committed every time any person pushes Sync it would be mess.

In any case it isn’t for me to decide but I doubt very much we will see it implemented that way. What you might get is limited access to the import and export buttons. That way collaborators can edit code (you still cannot see what changed) but only a single person can decide that those changes can be checked in or blown away.