Make it difficult (or impossible) to mess up the master branch

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 :frowning:

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 :blush:

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… :exploding_head:

I see this marked as Beta now. Can I test it somehow?

Presuming that “this” means “the Anvil IDE”, I’d start here: Anvil Docs | New Editor

The thread was originally marked as “[Beta]” because years ago when it was first created, the new editor was a beta creature! It’s now all grown up, and is no longer “new” - it’s just the Anvil Editor - so to avoid confusion I’ve removed the beta tag from this thread.

3 Likes