Should I create a feature-branch in this case?

Question

git

Good day!
Until recently, I actively studied the collaboration policy in GIT. In the course of the study, a question arose. But first, a hypothetical story:
Let's say we have a project to which we want to add new functionality. To do this, we create a new branch called feature/${your_name} and work on it. At the end of development, with a satisfied look, we go to merg or ask to consider our pull request. The admin accidentally pressed the merge button and your feature was added to the main branch (for gitflow - develop). Then, after a few months of sobering up, he realized that we had implemented one function incorrectly, and asked us to correct it.
And then we get into the thinking:
"So, I will fix my independent module. I previously wrote this module in a separate branch of the same name called feature/${your_name}. I safely deleted it, since it is required by gitflow. And now, to fix this module, I do I need to create a feature/${your_name}-2.0 branch or do my fixes differently?

Answer 1

When such a situation arises, I would go to the one who accidentally pressed the merge button, that is, to the main merge, and ask him this question.
There is no clear answer to your question. There are recommendations. And no more. Each office is free to commit and name the branches whatever it likes, even with the name of the boss's hamster.
And so - it seems to be a bug. Accordingly, we go to the description of the workflow, and see how to deal with the naming of branches for bugs.

Answer 2

I do not delete feature branches after they are completed, and they weigh until the release is completed, that is, if there was no release, then all fixes are fixed in this branch.
But if there was a release, and the branches merged from the master were usually deleted, then all the fixes go as a hotfix.

Answer 3

https://developer.mozilla.org/en/docs/Web/JavaScript...

Answer 4

Can browsers already export without babel ?