# An improvement to working with git projects

**URL:** <https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694>\
**Category:** Share Your Nodes\
**Created:** [23 March 2024 13:40 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694 "2024-03-23T13:40:27Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![04nd01](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/04nd01/32/89567_2.png) [@04nd01](https://discourse.nodered.org/u/04nd01)\
**Post date:** [23 March 2024 13:40 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694/1 "2024-03-23T13:40:27Z")

</div>

I recently switched to using the projects feature but felt it didn't give me a real benefit as far as version control goes because everything is squashed together in a single .json file.

I couldn't see any good solutions for this problem out there, so I built a flow to help with that. It runs in the background and splits all flows into separate, well readable .yml files every time a deployment is made.  
These files can then be separately committed any time changes are made to a specific flow. This allows a better overview of the changes at the project level where you can see which flows have been changed, removed or added. Also function nodes are multiline, so changes in a function can be easier identified line by line in a diff.  
The goal was mostly better organization of git repositories but it also offers the ability to revert a single .yml file to any point in time and to then merge it back into the main flows.json file.

[Node Project Flow Splitter - Export flows to separate YAML files](https://flows.nodered.org/flow/00a567e1e2400f33e0eb76194877c4c6)

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/e/9e6532a7590b595af17b3d02f51ff44b15119849.png)

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [23 March 2024 17:13 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694/2 "2024-03-23T17:13:33Z")

</div>

That might make a great Node-RED plugin or custom node! 🙂

---

<div class="post-metadata">

**Author:** ![RvG](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/rvg/32/96613_2.png) [@RvG](https://discourse.nodered.org/u/RvG)\
**Post date:** [25 March 2024 16:08 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694/3 "2024-03-25T16:08:43Z")

</div>

That's very interesting.

Reminds me of this: [node-red-contrib-flow-manager (node) - Node-RED (nodered.org)](https://flows.nodered.org/node/node-red-contrib-flow-manager) .

This one is also related: [node-red-flow2src (node) - Node-RED (nodered.org)](https://flows.nodered.org/node/@steveorevo/node-red-flow2src)

I've never tried to use those, especially the first one looked too complex for me 🙂

But with your solution it is much easier to see what's happening, and I don't need to install new nodes.

Some small things:

- The 'Get flows' http request node has a URL field filled in, but the input message also contains msg.url. That override will trigger a [warning](https://github.com/node-red/node-red/wiki/Deprecated:-Message-properties-overriding-set-node-properties) in Node-RED 4 beta 1.
- Personally I like to limit the number of rules in a change node, you could use a JSONata expression to simplify some things. For example to build the last API string: `apiHost & '/flow/' & payload.id`.

---

<div class="post-metadata">

**Author:** ![RvG](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/rvg/32/96613_2.png) [@RvG](https://discourse.nodered.org/u/RvG)\
**Post date:** [25 March 2024 16:49 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694/4 "2024-03-25T16:49:41Z")

</div>

BTW, I encountered two practical issues using when trying out this flow.

- when I use the roll back action, the affected tab moves to the end of the tab row
- you have to remember to edit the name of the tab to roll back, and deploy, before pulling/editing a specific yml file

---

<div class="post-metadata">

**Author:** ![04nd01](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/04nd01/32/89567_2.png) [@04nd01](https://discourse.nodered.org/u/04nd01)\
**Post date:** [25 March 2024 18:48 UTC](https://discourse.nodered.org/t/an-improvement-to-working-with-git-projects/86694/5 "2024-03-25T18:48:39Z")

</div>

Yeah I looked at node-red-contrib-flow-manager too. It can handle subflows, which mine doesn't do yet but also seems to be geared towards a more advance use case than just prettying up your git repo.

> The 'Get flows' http request node has a URL field filled in, but the input message also contains msg.url. That override will trigger a [warning](https://github.com/node-red/node-red/wiki/Deprecated:-Message-properties-overriding-set-node-properties) in Node-RED 4 beta 1.

Thanks, it's fixed now. I'm already getting these messages on 3.1.7 but that one must have slipped through when I was finishing up.

> when I use the roll back action, the affected tab moves to the end of the tab row

I suppose that's a consequence of going through the admin API instead of working with the json file directly.

> you have to remember to edit the name of the tab to roll back, and deploy, before pulling/editing a specific yml file

Your're right. I wasn't sure what you meant by this and then promptly made that exact mistake. If I go to edit the injection node with the name of the file I want to restore it will of course overwrite that file again. A solution for this would be a mechanism that prevents the file watch node from triggering when the flow is first deployed but the only way I can think of would be using a "inject once" node and those don't trigger when you're only deploying only modified flows, so that would only work when you're doing a full deploy every time.