Code locally, push to glitch via git?

Can I code locally and push code to glitch via git?

This question already has an answer here: Possible to code locally and push to glitch with git?

Where it’s said it will become easier in future.

Is it easier yet?

No, while a lot of progress has been made, it isn’t yet ready for release.

We use Git in our production workflow for Glitch itself, which is a Glitch project and open-source. You can see the flow we use in the Contribution Workflow section of the docs. All the necessary Git commands are spelled out there, too.

My experience so far most favors a changset flow of:

  • Glitch may pull from Central
  • Local dev machine may pull from Glitch or Central; In the event of merge conflicts, resolve them here.
  • Local dev machine may push to Central

Where Central == GitHub, GitLab, your local server, whatever.

This is fairly easy to get up and running-- either start your Glitch project as a clone (so that its paths get set up), or set up git remotes once you’re up and running. Once this is well, you can go into your glitch console and run commands like:
git pull or git pull origin {branchname}:master to update your glitch project to the latest version of what your central repo has.

There’s nothing stopping you from using Git Branches inside of Glitch itself, however I’ve come to favor avoiding them and instead use Glitch remixes like branches. If I want to branch my repo, I start by remixing the project; once I’m satisfied, I merge it back using the git flow outline above.

All that said… let’s say that your end goal here is just “I want to use a local editor sometimes.”, then I recommend the flow above – it’s what I use myself :slight_smile:

If your goal here it to use a local editor… like… A LOT… and you want one-step pushes into Glitch, I’d do this:

  1. (if starting fresh) Put your code in a central spot, like github or gitlab, then clone that into a Glitch project. (if you already have stuff in Glitch, pull it out, push it to central, and set up your repository paths.)
  2. investigate the CI hooks of your central repo; find one that triggers on push. Have that push hit {your-project}.glitch.me/deployhook/?secret={sauce}.
  3. in glitch, add a /deployhook/ endpoint which checks {sauce} against a secret you store in your .env file (this is just a simple effective way to authenticate it), then executes a ‘git pull; refresh’ in the terminal…

So rather than pushing directly to glitch (which would entail having to set up git authentication in glitch and managing it on your own; better not to), you push to your central repo and use a webhook to have glitch pull it into itself.

This also lets you use the glitch editor directly when you want to, and you can always pull those changes locally.

If this is the adventure you choose, go for it! Let us know how it goes, you’ll be an interesting power-user.

On our end, we want to make this a much more seamless and easy to understand process, which is why I would agree with Gareth: No, it’s not easier yet.

5 Likes

Hi folks!

I went ahead and implemented Jude’s strategy as a Glitch project:

Hope it helps!

3 Likes

what does “sauсe” mean?

It’s a secret that you come up with to prevent other external sources from being able to trigger deploys.

1 Like

@VnGNL in the context of what Jude was talking about, Tim’s comment is right on. This is the step where Jude discusses that:

In @noise-machines sample project that demonstrates this workflow they call it SECRET and you can see it (empty and ready to be set when you remix) in that project’s .env file and used in the server.js file.

We can just create post-receive hooks to refresh after every push.

To summarize:

  • Set git to update repositoy everytime you push.
    git config receive.denyCurrentBranch updateInstead
  • Create a hooks to refresh project.
    echo '/usr/bin/refresh' > .git/hooks/post-receive
  • Make it executable.
    chmod +x .git/hooks/post-receive
3 Likes

Why I need to branch out my deployments to the glitch Git branch, instead of master?