In 45 minutes we travel through GitOps basics, tools and challenges before we take off to a live demo.
1 Like
After the talk, I ran out of time answering the last question on why (not) to use branches for different environments.
Fortunately, I can answer in more detail here:
Actually, when we started with GitOps we tried using branches to realize a staging environment as well. I actually used to have a slide for this in a former talk on GitOps
For us, using branches resulted in complicated merges, even with only two stages. We expected that it might become even more difficult with more stages. I also vaguely remember we got chaos because the merges were only one way (like staging → production) and we ended up having differences between the environments. Well, this shouldn’t happen in theory, but somehow it did aynway 
We then tried to use a trunk-based approach using folders. With a trunk-based approach you only have one source of truth and not n (number of stages) to synchronize. This seem less complex so we went with it.
This was a couple of years ago and the meantime I heard a lot of other voices from the community coming to the same conclusion. A very detailed explanation can be found here:
There’s also a recent talk (ArgoCon last week) by the author (Kostis Kapelonis) that sums up the essentials: Lightning Talk: Best Practices on Organizing GitOps Repositories - Konstantinos Kapelonis, Codefresh - YouTube
There, we learn that one corner case might be to only apply parts of the upgrade to another stage. How would we realize this on branches? Git cherry picks maybe. With folders we could use a simple copy operation.
Another important point mentioned there are resources shared by multiple environments. Usually we use helm or kustomize to keep our manifests DRY. So keeping them in separate branches would cause redundancy here.
So, I think the gist is: Using folders is less complex than using branches.
I hope this answer helps! Let me know if there are any further questions.