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).
In the current implementation, no. As it commits on every deploy, I didn't want to add an extra step to deploy. So it generates a rather bland commit message.
This is an area I'd like to hear feedback on.
Having all the commit messages auto-generated doesn't help a user know which was which when they come back to it later.
One idea is to enable git tagging in a simplified way - so a user can tag a commit to give it more significance.
Another idea was to support git commit -amend to change the last commit message - although that is problematic if they have already pushed the commit to a remote.
I like the idea of being able to do something after the deploy, as often you need to deploy and test before deciding to mark it as a 'good' deploy that warrants flagging in the git history.
Wondering from a UI perspective if having an optional pull/commit/push button near the deploy button would help for manual mode ? I find I sometimes forget to commit because it's a bit deep in the UI.
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.
I think this is a great idea and particularly useful to the many Node-RED users who aren't programmers and for whom a git is either a term of endearment or of scorn!
It would indeed be nice to have the option to add a message to each auto-commit but I can't think of a good way to do that without disrupting people's normal workflow too much.
The idea of also having a commit button more obviously placed is also a good idea. And in that case, it would, I think be reasonable to expect to enter a commit message.
+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!
Hi All,
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.
