Most of your questions go to your sprint process and it will depend on (be up to) your Scrum Master to define this for the team, with the teams input.
But how do you tag or create your branches for each sprint?
This is quite varied, one approach I have used that works well, is to branch per PBI from a stable main (talking Git here) and have branch policies on main to stop it becoming unstable. Then you swarm on the PBI and PR it back to main when the PBI is
Done. This means you only have a few PBI's open at a time (based on a "standard" scrum team size of 6+3 people. The key factor is to keep PBI's small, so you can iterate more quickly and have a smaller impact when going to/from main.
What is the version you use?
Generally the build number from the build system being used, which also tags the public version numbers when needed within the build/release/deploy pipeline. Build systems are typically highly configurable. I don't use Jenkins but I am sure you could customize it to suit your needs whilst maintaining a high level of automation.
how to prevent waiting time between sprints
This goes directly to process. To not have a large lag between developement and testing both roles (and I am not saying this is two different teams) need to be swarming on the PBI at the same time. Testing is development, whereas the artifact of testing & development is a condition of the PBI meeting DoD and being
Done, which would ultimately be decided by automated testing ... and possible some other manual considerations. Ultimately the PBI's undertaken within a sprint should be
shippable at the end of that sprint - this doesn't mean you are shipping them, but you should be able to. If testing (the act of writing tests and having their output readily available) is not treated as a first class citizen in the process then your sprints will seldom be finished.
If you are testing in a coming sprint what was achieved this sprint then both sprints are broken.
Is continous testing and creating a working release in a sprint a requirement for agile development?
No, but your life is much more pleasant if you adopt a customer-first, automation-first strategy to development. The first focusing on requirements, the second focuses on getting those requirements delivered faster ... for validation by stakeholders.
Continuous testing helps with not getting an explosion of RC's. If you test (and fail fast) you can address any defects that the team has created within the current sprint (from the PBI implementation) during that same sprint, after all if you create defects whilst implementing a PBI you could hardly call the PBI done until the defects are resolved. Some defects, may be that your new implementation have uncovered 'old' defects in other (or the same) area and they would have to be taken to the PO and SM immediately for a decision on fix or prioritize. Ideally (but not always) you would hope to uncover this during the PBI design and planning phase prior to the sprint ... of course, that doesn't always happen.
Is the build number the only thing what the testers get?
This sounds like you want to code something then throw it over a fence to a tester. If this is the case, you might want to rethink your strategy (and discuss this with your SM). The developer writing the tests should be working closely with the developer writing the functional implementation ... and they should be in the same room (if possible) working closely with each other.
TDD: Test is written, pushed to VCS, developer pulls test, writes code and runs test both on their PC and on build server when he pushes the code back.
NON TDD: Same as TDD but the test may not be written first.
In both cases, the test developer, implementation developer and build server should all be capable of running tests and validating the requirement at any point in time ... and the PBI is not marked done until this is all harmonious.
If your team is geo-located you can setup your pipeline to automate emails to team members based on conditions, like; a build failed, code linked to a PBI I am working on was committed.
Does the developer begin with tasks from the next sprint?
Not without clearing this with the PO and the SM. Ideally not, there is always something to do. Log checking, cleanup, documentation proofing. If all of that is too uninteresting or there is more time then spare jobs to do, then you would normally drag a PBI into the current sprint that is decided by the team ... and ideally can be
Done within that sprint so you are not breaking the sprint. If your team thinks in terms of "developers" and "testers" then you can always get your "developers" to help the "tester" write and validate tests.
As for bug fix, this can also be handled numerous ways. One way is to have your "normal" sprints run on implementing PBI's and already prioritized bugs. Then during planning bugs/defects are triaged and prioritized into the backlog for coming sprints. The triaging of the bugs can be done using a Kanban and either having another team perform this task (if you have a large number of bugs) or you can rotate 1 (or more) members out of the sprint to run the kanban, giving everyone a turn on the kanban instead of one poor sole undertaking bugfix for the rest of his natural life.
Bugs are well suited to Kanban as you cannot always estimate the time needed to fix something and once you are neck deep in the investigation it is just as easy to keep going. Bugs that can have their fix easily identified or ones that can be easily prioritized can either be taken immediately for high priority EBF or left in the backlog for low priority with easy or almost 0 investigation required.
EBF's (Emergency Bug Fix) should be branched from a stable main and PR'ed back to main ASAP to minimize merge conflicts of PBI's under development that are potentially in the same area of code.
@marstato beat me to explaining RC's so I won't mention that here.
Hope that helps.