Git visual integration is amazing

Just wanted to throw some praise to the Wappler team for the git integration as it made for a great workflow today.

Been working simultaneously today on some bug fixes needing to go into production, as well as a larger feature build. The only thing missing in the Wappler UI was being able to merge a branch to something other than master, but the Github desktop picked that up easily, so no complaints from me.

For those of you not using git yet, this is what can easily be done:

Work for days on a feature (in this case the memberpess branch) but then find bugs that need to be pushed to production before you are ready to push the new feature. Just use another branch (in this case meal_plan_list_view) to make the changes, and then merge those changes into your feature branch, and separately merge the bugs into the master for production. Then go back to work on the feature development. No mess, no fuss. No half baked code finding its way into production.

The visual nature of the Wappler interface makes it very clear to see what took place and is great to work with.

Well done team!

6 Likes

Praise deserved.

I use it extensively for day to day thingies. But I must admit that I still use Gitkraken for a lot of things that are still not available in Wappler’s UI.

I don’t complain about the lack of features as I have this idea that not many wapplers use GIT because you know…difficult and terrifying.

Hopefully in the future GIT becomes “mainstream” and they can dedicate resources towards adding features.

Gitkraken has a beautiful UI(it’s electron based also) and can give some inspiration for future iterations in Wappler.

2 Likes

The Git manager visual structure is indeed quite good in Wappler.
But like Jonas points out, it lack many features.
We have finally added Git to out team’s development workflow, but we usually use SourceTree for Git management.

We are not entirely sure of all Git’s features and workings, so haven’t really submitted any posts about improving Git manager in Wappler. Probably do so in future when its less difficult and terrifying. :sweat_smile:

I assume that this is only really works if you are using Git to deploy to your servers, right? Right now I use Docker - and deploy from the Wappler UI.

I really like the idea of utilising Git but need to better understand the workflows. Looks very powerful.

Not at all. Deploying from GIT is a nice feature hosting providers can have. But it’s not GIT’s main purpose and it’s not a GIT feature. It’s a hosting provider feature.

The main purpose is source control. If you are a team of developers it’s a must but even solo there are a lot of things that make your life easier. Like the one pointed out by Ken.

1 Like

Wappler will not become a full Git tool like Gitkraken or SourceTree, we will support just basic usage to make it easy to commit code directly from within Wappler and have some control of reverting back, basic branching and publishing. We try to keep it easy enough for new users and have enough functionality for the somewhat more experienced users. It will always be possible to use an external tool like Gitkraken or SourceTree next to Wappler to have more control over your Git repository.

5 Likes

In a sense I am relieved to hear this. Out of interest @patrick what do you guys use?

Thank you for the reply JonL.

That’s excellent. I just need to try and get my head around it.

Right now, even if I don’t push to git, if I deploy via Wappler to my remote Docker/AWS - then the changes are applied, regardless of git. So I need to try to find some info on why / what I need to do differently to take full advantage of it.

It’s something I need - I find myself getting into a situation as Ken mentions. Building out a big feature, then all of a sudden I need to handle a bug - but if I deploy, then I’m deploying the changes of the big feature release too, often that means a bug deployment is delayed or the new feature rolled back slightly. Terribly inefficient.

2 Likes

I never really used GIT before Wappler added the feature. Now I rely on it completely. I generally work alone on projects so I use it as a means of backup and synchronising between desktop and laptop but it’s also saved me on the rare occasion something has gone very wrong and I just need to roll it back.

I’ve hardly used the branches facility but @mebeingken’s post has encouraged me to look at that in more detail again as I think it could be invaluable.

4 Likes

I like this thread because I know GIT is something I could benefit from as a solo developer. Unfortunately, like others, I just don’t understand it. Can someone point me at some Wappler tutorials and other GIT tutorials that would explain things in VERY simple terms?

I suppose I need to understand why, then understand how to implement it using Wappler.

1 Like

Just wait until you end up with one of these.

image

This is what happens when you get lazy with GIT and you have to cherry pick lines in files.

Thank god staging environments exist.

/me starts praying

As always, that is a good, simple tutorial on how to do it. I suppose to make things clearer for my brain I am looking to understand ‘why you would do this’ and ‘what it is that you are actually doing’, so for instance

  • Do you need a local repository, remote repository, or both (and why)?
  • Do you need multiple repositories?
  • What is a repository and is it part of your site structure or separate?
  • Do I need to subscribe or sign-up to an external service?
  • Can you exclude files from being uploaded?
  • And I suppose I don’t understand what the different coloured branches are doing in Ken’s example above? (blue magenta green)

I know that these are probably simple and obvious things to some people but unfortunately I need to see the bigger picture. I seem to learn better by example rather than by theory.

Sorry for all the questions but I really want to learn.

You need a local repository to keep track of changes - version history, so you can see the history of changes and revert to previous versions of your files. You don’t need a remote repository, unless you want to share the project with other computers. You don’t need to subscribe to any service to use git with your project. Yes, you can exclude files in the .gitignore file. The branches have different colors, so it’s easier to distinguish them. In case of simple git usage - version history for example, you will rarely need to use branches.

1 Like

I would recommend using a remote repository, too, for backup purposes. You can create it as private so only you have access to it. And most are free. Plus, that would give you the facility to work on two computers and your repo is the means to sync them. That’s how I use it.

I’m still very much a GIT newbie and only use it in its most basic level but I now wouldn’t be without it.

1 Like

Thanks Teodor, that helps me alot, thanks.

Simple GIT version history is the way to go for me, at least initially.

And I’m happy that I don’t need to be concerned about the coloured branches at this time, but can you explain a little more about them. Just a simple explanation will do.

Cheers

Well … it’s already explained in the docs:

Hi Jon, what you say makes a great deal of sense, I like the idea of back-up and I like the idea of backing up development or experimental files as well as production files.

Who do you use for remote repositories?

I hope to soon catch up with you :laughing:

1 Like

Thanks Teodor, I suppose I didn’t realise what I needed to look for. I now feel more confident to be able to dive into these murky waters :smile:

I use Github.com but there are plenty of others. Gitlab and Bitbucket are probably the other two leaders. I think they all do free plans but check about limits on private repos. Github, I think, provide unlimited for free but can’t remember for sure. The limit is certainly large enough for all my projects.