I set the Editing branch to dev, do some editing, feel good about it and click on Merge changes into master. At this point I have two problems:
- The
Editing branch is set to master. I think the Editing branch should remain dev, because it’s more likely that I want to keep editing the dev rather than the master branch
- I can edit the
master branch and make a mess on the published version. I think the master branch should be read-only, it shouldn’t be editable not even after setting the Editing branch to master
Traditional git workflows may limit the life of a branch to a short development period, and the branch may be deleted right after the merge, but in most simple Anvil apps there will be one long lasting dev branch.
I think that the default behavior should be for the IDE to keep editing the dev branch. Automatically switching to master (or any merged branch) could be an option set while defining the environments or creating the branches or in the Look & feel.
I think that editing the branch that is served to a public URL should be absolutely impossible. At least absolutely by default impossible. I would like to see a Make branch read-only when creating a branch or when defining an environment.
7 Likes
In other words, the only way to update the Published version is via Merge, not by direct editing?
Yes.
And if an app has more than one published versions, I would like to set all the published branches as read-only.
I would make all the branches read-only. The user must explicitly specify which branches are read-and-write. You can publish a read-and-write branch if you want, but you need to explicitly set it that way.
As is, it’s too easy to edit everything.
Most standard workflows, even advanced ones, will only edit some development branch(es) and merge to the published one(s). I can’t see a workflow that needs to edit a published branch, it’s too dangerous. But if you really want to do that, you can edit the environment and set that branch to read-and-write.
A new app could be automatically configured out of the box with a dev read-and-write branch and a master read-only branch. The UI could have the Publish button that merges dev to master, and the simple workflow is set.
For advanced workflows, you could setup all the branches you want and tag them as read-only or not.
3 Likes
Yes. Sometimes you need footguns. But it’s best if they start out with their safeties ON.
3 Likes
After thinking a little about it I would change the subject from Making it difficult to mess up the master branch to Get rid of the master branch.
Here is how I would manage the app versioning:
- A newly created app has one
dev read-and-write branch and one pub read-only branch, each with its own environment
- The
Version History UI allows to create new branches and set them read-only or read-and-write
- The
Publish dialog allows to define more environments and link them to their branches
- In the
Publish dialog (or somewhere else in the app settings) there is an Only merge to read-only branches checkbox, which is checked by default
- The
Editing branch drop down does not show read-only branches
- If there is only one read-only branch, then the
Merge button will merge to that branch
- If there are more read-only branches, then the
Merge button will ask which branch to merge to
This setup will allow both one-click publishing for beginners and fancy setups for experts:
- If you are a beginner, you edit your app and click on
Merge when you are ready. If you want to revert to an older version, you can right click on a commit and click Move the "pub" branch here
- If you are an expert, you can uncheck the
Only merge to read-only branches, setup all your branches to be read-and-write and enjoy all the flexibility you want. You can even create a new branch and call it master!!
1 Like
It’s only 9am and I have already worked on an app where master is the development branch and one where master is the published one.
I can understand what’s what by looking at the other branches that may be called published, dev or anything else meaningful, certainly not looking at the one named master.
1 Like
Every time you merge to master, it automatically switches to master.
I think this is very very very dangerous and it should change. By “this” I mean both the fact that master is automatically checked out after the merge and the fact that master is editable.
I got hurt with it already many times. I am getting used to immediately switch back to dev, but this is far from both user and beginner friendly. Not only this is dangerous, it is also useless.
3 Likes
About editing the master branch, I don’t think it should be read-only. I think the git flow of commits is now available and I’m loving it. New features should use specific topic branches, but hotfixes can be made directly to master for simplicity and to quickly make the fix available in production.
Make some branches always read-only or read-only by default would be a limitation that would not be in the best interest of all. I just think that the should test some different approaches to how the editor knows when to change branches and things like that.
I agree,
I have enjoyed and documented it myself.
But:
- If you are an expert, all you need to do is create a new branch, apply the hotfix, merge, delete the branch. The 3 create-merge-delete steps take just a few seconds and make the process safer
- If you a beginner, you need to learn to keep your eyes open and make sure you don’t edit
prod (now called master), which is more difficult compared to the old cleaner behavior, where it was impossible to edit prod (earlier called published)
- Whether you are a beginner or an expert, working in an environment that exposes an app to direct editing that very likely causes it to break, is just looking for trouble. When the only advantage is avoiding those 3 quick steps
I think the use Anvil makes of git is genius and very powerful.
Unfortunately Anvil wants you to use git the way git is usually used, with the whole workflow turning around a branch called master. But I don’t see any other reason to call that branch master other than that’s what the other guys do outside of Anvil.
We do have years of testing with a read-only branch called published.
I haven’t seen any complains about it.
I have never accidentally modified it and I have never accidentally broken an app. Because it was read-only.
I don’t understand the decision to rename the published branch from a meaningful published to a confusing master.
I don’t understand the decision to make the read-only branch read-and-write.
I consider these two regressions from the old editor.
One week with the published branch read-and-write and I have had 6-7 accidents of broken apps, and we start seeing questions in the forum like this one. If the published branch was read-only this question wouldn’t exist.
I love the complete redesign and the added features, but I don’t see why the two things that were working beautifully have been changed:
- There was a branch linked to the published app called
published
- That
published branch was read-only
2 Likes
I have to agree with @stefano.menci, here. The IDE should, initially, by default, turn off anything that makes it ridiculously easy to break Production. Keep the footgun – sometimes it’s needed – but start with all of its safeties turned ON.
Folks who prefer to operate with their own safeties off, should be able to turn them off, and keep them off.
From what I read here on the forum, I get the feeling that several safeties are off, by default; and even when turned on, some of them revert without warning. (Topic title names one case in point.)
For now, I’m sticking with the old IDE. It’s more work than using the new IDE. But it’s also insurance. Detecting and recovering from a broken Production can be rather costly; especially for the end-users, who may not have workarounds in place.
3 Likes
I’ve been using branches more in the Beta IDE, and I have to agree 100% with how annoying this is. I never want to edit the master branch immediately after merging the dev branch into it. I always want to stay in the dev branch. Having the default be that the master branch becomes current is way too dangerous.
4 Likes
+1. This is super risky, especially with multiple developers - way to easy to log in at the beginning of the day, make accidental changes to master, and have these end up in production! So long as ‘master’ is the default branch you merge into (and presumably eventually push to production), some safeties as @p.colbert puts it seem like a really good idea.
In an ideal world, we would be able to use GitHub to protect branches and require review etc. In other words, use GitHub - not Anvil - as the VCS (on opt-in basis).
2 Likes
+1. From the collaboration angle, it would be very good to have a control to ‘protect’ the master branch or make it read-only for collaborators. Merges to master can then only be done by users given that permission.
TLDR: I would love to see what you are asking for, but, as a software developer myself, I would give waaay more importance to fixing a regression than to adding new features.
In this FR I was trying to keep it simple: all the branches linked to production environments should be read only, meaning you can’t check them out and edit them. But it should always be possible to merge into them or reset them to other commits.
All I’m asking is to go back to the way it was before (this regression), like in the old editor where the published branch wasn’t editable. You could only edit master and then, with an explicit operation, you could reset published to master (merging didn’t exist then). It was impossible to accidentally break a published app.
The new editor introduces the merge, awesome, and (the regression that) allows to break production branches, horrible.
My feature request was about fixing the regression: make it difficult again to inadvertently edit production apps, just like it was before.
Your request is about adding new features that don’t exist: user permission management in the git workflow. That would be great, but it would be a much more complex job (farther in the timeline) and much less important (it is not a regression fix).
1 Like
For the record, I switched to the new IDE towards the end of 2022. There were too many new features I needed, which were tied to that IDE.
1 Like
I did it again: I messed up the production app because its branch wasn’t read only 
1 Like
I’d “heart” this but that’s the opposite of how I feel so take this as a +1 instead.
I do wonder if GitHub integration would give this branch protection?
You mean you like the fact that after merging from dev to prod and ending up with prod checked out, it’s easy to mess up a production app, put it offline or even corrupt its database?
Perhaps the GitHub integration could do the job, but that’s a thing for a very small elite of Anvil users. The majority, including me, will never touch GitHub, and asking us to setup all our apps to sync with GitHub only as a workaround to bad UI design, is not acceptable. Especially considering that this wasn’t happening with the old editor, where the published branch was read-only, and you could only publish with an explicit action.
Right clicking on a branch and clicking on Make "prod" branch read-only would be much simpler and useful for every user, from beginners to experts.
EDIT
@danbolinson, I realize now that by “this” you meant my last post, not the whole topic.
The clarification about GitHub stays, but I do understand your position, no need to answer my first question 
Agreed. The merging and branching should be way more safe.
Update: A year after that forum post, I switched to the new IDE. It had features I just couldn’t refuse… 