The Projects feature integrates a git workflow into the editor. This lets you version control the files that make up your Node-RED application.
Currenty, the user has to remember to actually commit their changes in order to use version control. For many developers that is a natural part of their workflow.
However for developers not accustomed to version control, that extra step of committing changes can be easily overlooked.
To help with that, I've created a simplified git workflow a user can opt into. This automatically commits any changes whenever the Deploy button is pressed. Commits, ultimately are cheap to make. And it will give the flexibility to rollback changes on a per-deploy basis (once we add the ability to roll-back to previous commits... something still on the todo list).
I like the idea of having git commit button next to deploy. If this were similar to the deploy drop down, it could have modes like "Manual commit" "Auto commit on deploy", "Request commit on deploy" [Needs more thought and discussion]
If "Request commit on deploy" is set, then the dialog would pop up with the comment auto set but presented in an editable text area. This would permit a quick and easy commit but also allow the user to change the comment if they wanted to.
Personally, i often deploy small mods and test before a commit - then I ultimately forget! Promoting on deploy mode would remind people.
If something like this was available, I would choose "Request commit on deploy" as my default setting and when I'm done with my flow changes & testing, I'd press this new easily accessible button to perform a commit and enter a relevant commit comment.
+1 for an "auto-commit" option -- but there will be hundreds of repo commits a day per user (every time I turn off a debug node, move a wire, add a comment, add a test node to change a msg, etc). I think any static "comment" string will just add noise...
Now, if the comment could be a summary of the changes (like those shown in the flow diff tool) --
+3 nodes, -1 flow, 12 nodes changed
... well that would be useful... but I'm sure there is far too much processing necessary to build that little summary string!
I like the idea of a simplified git workflow but would like to see the simplification taken a step further in order to appeal to non-programmers who probably have never heard of git or even the concept of version control.
In its simplest form it could just allow a rollback history of previous deploys and not use a central repository but be local to the server directory.
This way the user is oblivious to git and can organise their work in folder hierarchies that they can see and comprehend. It also alleviates the need for the user to set up git repo. settings and provides an obvious way for them to recover from the dreaded lock-up that hits novices as they stumble into unfamiliar territory.
I would like to use Projects myself but have not found a way that fits in with my way of working. I often have multiple servers running (with different versions of node, NR and dashboard) and often copy/paste flows/nodes between browser tabs. My folder names allude to what is contained within as well as the port number to use when launched. viz. name#1881. When I start work on a new version I create a new folder then copy certs, settings.js and two shell script files. One script runs yarn init which installs specific versions of node, NR and dashboard for example. The second script launches the server on that port with the -u command line switch.
I can supply the scripts if anyone is interested.
Thank you for providing this opportunity to comment and sorry that I do not have enough skill to offer a PR to demonstrate what I describe.
I suppose "off-line" deploys needs to be treated as well?? I mean working on your flow, having full access to the NR editor and host but currently without internet access. Not so common but could happen I think. Would just give a warning and nothing more?
Oh, I see this topic is +2 years old, forget my comment above
Hi @krambriw, I hesitated over the age of the topic also but the subject I think is intended to remain open.
I would suggest that there may be many who work off-line.
I also believe the attack surface is far too big already when it comes to smart homes. None of my IoT nodes have internet access. If I wish to do an update I temporarily remove the IoT host IP address from a firewall rule, do the update and then reintroduce the rule.