I have the same workflow! I haven't yet used trunk-based development within a team, but really like it for my own workflow.
Generally I'll create a side branch if I think there's risk involved; e.g. if I'm working on a new feature and am playing around with API ideas. That way, I can delete the branch if it's not going well. Otherwise though I usually just commit to master.
New features should be developed on the trunk/master.
If you want to try things out, which basically means you want to create a proof on concept, then you can do this on a special branch. This branch you throw away when you are going to implement the real thing on the trunk. Proof of concepts are meant to be thrown away, not merged.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have the same workflow! I haven't yet used trunk-based development within a team, but really like it for my own workflow.
Generally I'll create a side branch if I think there's risk involved; e.g. if I'm working on a new feature and am playing around with API ideas. That way, I can delete the branch if it's not going well. Otherwise though I usually just commit to
master.New features should be developed on the trunk/master.
If you want to try things out, which basically means you want to create a proof on concept, then you can do this on a special branch. This branch you throw away when you are going to implement the real thing on the trunk. Proof of concepts are meant to be thrown away, not merged.