Environment Division in Git

I have a bunch of network automation stored under one Gitlab repo. Ansible and Python. Currently within that one repo I have a lower environment branch, and an upper. Automation will then run using one branch or the other relative to the environment. This is done currently via Gitlab scheduled pipelines which run the code from a docker container.

What I think I want is to work off feature branches that get merged into the lower branch, like the below diagram. Once satisfied with the lower branch, I simply bring the upper branch up to where the lower branch is.

* LOWER-BRANCH | \ | \ | * SOME-JIRA-BUILD | / | / * UPPER-BRANCH 

My current workflow has been something like...

• checkout new branch based on lower
• implement new feature/change/whatever and test
• merge it with lower
• validate lower automation (the steps up till now may happen several times before lower merged into upper)
• merge lower branch into upper

This workflow works fine functionally but has resulted in some headaches as far as managing commit history and merge requests is concerned. For starters the commit graph/history is nowhere near as clean as the diagram above seeks to be. Merging lower into upper also often has commits that were included in previous merge, unless a rebase is done beforehand which comes with its own pains.

So I guess my question is - is this a dumb way to do this? Does something else make more sense? Anybody else doing something similar and able to provide insight on what works well for them? For context, I'm currently the only person involved, but at some point others should be contributing as well.