It doesn't matter.

In Git, a branch is just a label pointing to the latest commit on this branch. Editing the labels is basically free. This is unlike other systems such as Subversion, where a branch is a completely new, separate copy of the code.

Consider two scenarios:

1. The latest commit on your main branch is "added new SQL statements". Someone reports an SQL injection bug. You create a branch called sql-injection-hotfix. You fix the SQL injection and then merge this into the main branch. You delete the sql-injection-hotfix branch. You push the main branch.

2. The latest commit on your main branch is "added new SQL statements". Someone reports an SQL injection bug. You fix the SQL injection on the main branch and push it.

The end result of each scenario is exactly the same: a branch called main pointing to the commit "fixed SQL injection bug" and that commit's parent is "added new SQL statements". I mean exactly. There's no way for anyone to tell which one you did. If you view the log you'll see a straight line, with no records of branching.

(Exception: the reflog on your computer, which is like an undo log for git commands, will be different since you used more git commands in scenario 1)

If you work on two fixes at the same time you may create a log with a record of branching, but it's still the same, no matter whether you start working on fix 1 on main and then go back and branch fix-2 off an earlier point of main, or whether you branch fix-1 and fix-2 off main - whichever one you merge first will look like it was main all along.

It doesn't matter.

In Git, a branch is just a label pointing to a commit (the "latest one on this branch"). Editing the labels is basically free. This is unlike other systems such as Subversion, where a branch is a completely new, separate copy of the code.

Consider two scenarios:

1. The latest commit on your main branch is "added new SQL statements". Someone reports an SQL injection bug. You create a branch called sql-injection-hotfix. You fix the SQL injection and then merge this into the main branch. You delete the sql-injection-hotfix branch. You push the main branch.

2. The latest commit on your main branch is "added new SQL statements". Someone reports an SQL injection bug. You fix the SQL injection on the main branch and push it.

The end result of each scenario is exactly the same: a branch called main pointing to the commit "fixed SQL injection bug" and that commit's parent is "added new SQL statements". I mean exactly. There's no way for anyone to tell which one you did. If you view the log you'll see a straight line, with no records of branching.

(Exception: the reflog on your computer, which is like an undo log for git commands, will be different since you used more git commands in scenario 1)

If you work on two fixes at the same time you may create a log with a record of branching, but it's still the same, no matter whether you start working on fix 1 on main and then go back and branch fix-2 off an earlier point of main, or whether you branch fix-1 and fix-2 off main - whichever one you merge first will look like it was main all along.