@Teodor would you mind helping me understand something.
As mentioned above, my local and remote targets are all docker so I use the deploy in Wappler UI.
As I don’t use git often (mainly just for the sake of backing up to a remote git) - when I deploy it still deploys the full app - even if the git isn’t up to date.
So I guess I don’t really understand how the two work together. If I’m still deploying everything even if all changes haven’t been committed to git.
I use docker for local development and I deploy to my staging environment via GIT hook so I might not have this right but…
If you are working with two environments(local and production) you can’t. As you well say you will deploy the files in your local environment even if they are not in sync with your git remote.
You need an additional target that is in sync with your remote and deploy from there. Normally that’s called staging and it’s usually a remote environment too. But if you only have one remote environment(production) just create a new local target and call it pre-production or something like that. Make sure that’s in sync with your git remote and deploy from there. Do not develop in that target.
Edit: Actually…this won’t work…I think. I need to spare a few hours to set up something.
As such it’s not involved in the deployment process. But you will want to control what branch(i.e master) ends up in production for instance. And you wouldn’t want your working directory(uncommited changes) to end up in your production system.
Hmm, that might be a feature request. I’ve just worked on the basis that what is stored in my project folder is what will be published to the target. I could be wrong, though, as I’ve not (yet) needed to work on something that can’t then be deployed straight away.
I’m assuming and hoping that at least it will deploy the active git branch. So you could create a new branch called development and work there. When you are satisfied with the changes, you sync your local master branch with the remote(specially if there are more than 1 developers working on the project) and then you merge your development branch into the master, switch to master and deploy. Then you switch back to your development and continue working.
Still you could deploy the development branch by mistake and cause mayhem.
I’m just trying to understand a better workflow to allow the incorporation of git into what I do.
If I create multiple branches for new features that are not finished, how does this impact the project if I deploy to the server? Will it deploy the unfinished features or does git alter the project folder that gets deployed somehow
So then there is only one workaround. Set a new project connected to the remote where no working directory is available and deploy exclusively from there.
Switch to old project to develop locally. Commit and push to remote when satisfied.
Switch to new project, pull and deploy.
That way there are no uncommitted files in the deploy project.
After reading the docs I would think that after creating a repository one would be able to commit the changes:
'You will immediately see a list of files from your project to commit to the repository. Initially thisse will be just all files from your project:'
This indeed happens, super easy!
However, next up is this:
Lets edit our main index.html and add something to it like the App Connect framework. After saving the file and refreshing the Git Manager, you will see that a bunch of new files have appeared and that the index.html is changed:
I've changed and saved plenty of stuff in my project, but the changes don't seem to show in the git manager, not even after a refresh:
That seems to be a problem. As soon as any changes are made anywhere in the project, the Git Repo should instantly and automatically show them. It’s worked flawlessly for me so I don’t think you’re doing anything wrong but it’s clearly not behaving correctly. I’m afraid I can’t suggest why, though.
Perhaps better post it as a bug instead of in this topic, then we can keep track of it. I’ve also tried it and for me it shows any uncommitted changes, no need to refresh the git or anything for it.
