Branches are beautiful, on trees. Branches in the code are not what many testers like to work with. The whole branching process appears to be very cumbersome: creating the branch, keeping it up to date with the main branch, deleting it once the work is done, these all seem to take a lot of time and to not be the most fun activities. However, there are some situations when branching really needs to be considered.
When you are working on sprint tasks that require you to create new code, maybe you don't want or need to branch. New classes can be easily added to the main branch, without disrupting code that other people write in the same project, as long as everybody is working on different tasks/classes/methods.
However, adding the new code to the code repository needs to be done in such a way that it does not break the code project and allows it to compile and run successfully. Incomplete code, that does not even compile locally, should not be pushed to the code repository.
The newly written test code should also not break the continuous delivery pipeline runs. This means that tests committed to the main branch are complete and need to pass (as long as there is no bug in the functionality they are testing). Otherwise, if the commit is not a fully functional and correct test, the pipeline will stop when the committed test is run, and the CI process is broken, even though there is no real issue in the software under test.
When such a clean commit is not possible, branching is advisable. This way, the author of the code can commit code as often as they need, while at the same time allowing the tests from the main branch to continue running properly, individually or as part of the CI process.
Another situation when branching is a must is when you are doing a major upgrade of one or more of your test project's dependencies. For example, if you are upgrading from version 2.9 of the dependency to 6.1. This is because, as the version numbers suggest, there has been plenty of change in the dependency code between versions 2.x and 6.x, which might lead to your test code to: not compile, behave unexpectedly, or need to be changed or adapted to comply with the new structure or style of the dependency code.
Branching should also be used when you are doing a major refactoring of your test code. Whether it is just moving packages around, or changing the actual code, these are activities that can break the correct run of the tests or the compilation of the test project. Therefore, in order to assure a smooth refactoring, this activity should be done on a branch, and only after all the tests have run successfully after the refactor work was done, should this branch be merged back into the main one. So, don't hesitate to branch. It helps assure a clean state of the main branch of your testing project, while also allowing for the CI pipeline to work properly.