Git Version Control and publishing - Best Practices with Wappler

I recently added Git to my project for version control. So far, I have used Visual Studio and VSCode for version control and their UI has worked well for me. I use VSTS (now Azure DevOps) for Git control.
I do not understand completely how Git works, and have just used it for versioning. I have not created any branches or forks.

In Wappler, since there is no UI for this, I used the terminal window to initialize a local Git repository and then used the add remote origin and push commands provided by Azure to upload it. So far, everything has worked.

What I need help with is understanding how well Wappler works with Git. Is there anything I should take care of while using Git? Does creating various branches restrict the working of Wappler in any way? How to select a branch when opening a project? And similar questions… any insights would be helpful.

Also, if anyone can share some resources for dummies to understand how Git works, that would be great too. :slight_smile:

P.S. If I have used some wrong terminology that might cause confusion, please point out. :sweat_smile:

If you are in Windows, you can use a tool for Git version control called Git Tortoise (

It would be nice if Wappler would have an option to either pick FTP, or use Git internally which commits, push, pulls, migrations, conflict manager like its built in Tortoise, at work I use Netbeans and it brings that integrated into the IDE,

I was going to post a reply here, but forgot.
Thanks for the suggestion. For now, I have opted to use VSCode for Git.

I open the Wappler project folder in VSCode and all Git options are easily manageable in the UI. So works for me, for now. :slight_smile:

Ah seems I missed this post! Sorry!

As more and more people use git for website publishing, we are looking for ways to integrate it more in Wappler as well.

Think of it as replacement of the current FTP publishing, instead of uploading your site with FTP, you will have a choice to use git and then when you “commit” the site it will get uploaded and published.

So on your live server you actually host a git repository where you just commit to and those changes become your live site.

This is really convenient because you have a full version control and if something goes bad you can just revert back to previous version.

Many hosting and control panels (like Plesk onyx) already have option to use git for publishing.

This will also fit more the direction of publishing workflow we would like to use.

Instead of uploading files separately to the current selected target, we want to move to always work local and at the end when ready publish the new site to the live target. With all the control you need of course.

So @wappler_ambassadors what do you think of such supporting git workflow as well general publishing method?


I have never used Git so have no preferences. I would like to learn more though.


@brad you just can go back within your sourcecode history and see changes in code with line number etc. Green shows newly added code, red shows removed code. :smile: Okay that was quite a simple explanation but would love to see GIT!

As background info here is how you setup git in the most common hosting panels like cPanel and Plesk:


Integrating Git in place of FTP sounds great. Did not think of it this way. Probably because of my lack of Git skills. :smile:

Are you also planning to add a GUI for code compare, staging and committing?
I have used only these features of Git so far. There might be other GUI aspects too.

Also, replacing FTP will kind of force users to use Git and in turn make them better programmers. I don’t know why I never used it until about an year ago. It’s great.

We will definitely not be replacing FTP, it is just an extra publishing provider. So you choose, publish locally, ftp or git

Well we don't have plans for code compare integration yet. Just publishing. But ideas are welcome.
There are many git GUIs, like

I've never used Git, but from what I know of it, I'm sure it would be a good feature to add, and probably useful even for this those who don't work in a team.

This wouldn't suit me (eg I've never clicked the Publish button in Wappler) but I don't suppose this becomes any more necessary with Git - I hope not anyway.

This is probably the feature in Dreamweaver I miss most, simply select a file and see two versions side by side (local or local/remote):


Dreamweaver doesn't have it's own diff tool but it connects to third-party ones very easily. I expect the same feature could be added in Wappler. In fact it's already possible in Wappler - using the terminal window - but it's not nearly as convenient as Dreamweaver. I expect Git might be command-line based too.

You could try using Notepad ++ Compare plugin Tom. Works quite well.

Thanks Dave. I use UltraCompare which is very good (it’s what I used with Dreamweaver). I imagine these programs have some standard interface/CLI. Integrating Dreamweaver with UltraCompare was just a matter of telling DW the location of the program, without any configuration.


I have used Beanstalk for subversion hosting(also version control) in the past. They also have GIT hosting. What I liked about their implementation was their deploy setup and button. So you use version control and get your site ready for deployment. When ready deploy to production.

1 Like

Oh. Makes sense.

I hope the feedback from Git publishing adds this to future Wappler plans. :slight_smile:

One more thing @George - creating branches - can you share some insight on how that would be handled in Wappler?

As long as you continue to maintain the FTP option I have no problem with this approach although it means learning the quirks of still another application.

Love it, hope it gets implemented, I particularly use Beanstalk Git repository, but for my other stuff I use a free one like Github, or Bitbucket, I really never push directly to the server but I deploy from one of those repositories.

We are now working on GIT integration in Wappler and hope to give you a great preview of it in the next Wappler update.

With the GIT integration you will be able to do version control and history on any Wappler project.

Later on we will also add integration for publishing/deploy with just, but the initial implementation will be to have a local repository for a Wappler project and be able to fully track your changes and record history.

So it is good to grasp the basic working of git, a great resource for this is:


I already have Git on some of my existing Wappler projects. Will the built in tools work well with those too? Or will I have to remove it and start again?

Also, by local repository you mean I will not be able to use any other third party Git service to store the data? I am using VSTS/AzureDev and VSCode for Git right now.

Hi Sid,

The Wappler Git integration will automatically detect any existing git repository that you might be using on your Wappler project and will directly use them. No need to create any new ones.

We will have great git integration in our current file manager where you will see directly with icons and colors indication of changed files and be able to commit from there.

Of course you will be able to push your changes to remote repositories as you do now.

I was just talking about remote git deploy to live website repositories used as publishing instead of ftp. We are still figuring out the best workflow there.

Maybe you can share your current git and publishing workflow and what you think will be the dream workflow.


I have not yet used direct Git publishing to live servers.
I usually use shared servers with cPanel, where Git publishing has been added just a few months ago. So haven’t tested that out either.

I am not very well-versed with version controlling either. From what I do know, ability to keep separate branches for deploying in test servers (local or live) and production servers would be expected from Wappler.
If Wappler could also have its options/settings to be stored as per the branches, that would be great. I have seen some posts around here asking for production and development settings.