To understand the why part, let's think about another situation where you are working in a team where different people contribute to different pieces existing in your project.
Your entire team recently launched phase one of your project and is working towards phase two. Unfortunately, a bug that was not identified by the quality control department in the earlier phases of testing the product pops up after the release of phase one (yeah, been there, faced that!).
All of a sudden your priority shifts to fixing the bug first, thereby dropping whatever you've been doing for phase two and quickly doing a hot fix for the identified bug in phase one. But switching context derails your line of work; a thought like that might prove very costly sometimes. To handle these kind of situations you have the branching concept (refer to the next section for visuals), which allows you to work on multiple things without stepping on each other's toes.
There are a bunch of naming conventions that Git enforces on its branch names; here's a list of frequently made mistakes:
- A branch name cannot contain the following:
- A space or a white space character
- Special characters such as colon (:), question mark (?), tilde (~), caret (^), asterisk (*), and open bracket ([)
- Forward slash (/) can be used to denote a hierarchical name, but the branch name cannot end with a slash
For example, my/name is allowed but myname/ is not allowed, and myname will wait for inputs to be concatenated
- Strings followed by a forward slash cannot begin with a dot (.)
For example, my/.name is not valid
- Names cannot contain two continuous dots (..) anywhere
- Strings followed by a forward slash cannot begin with a dot (.)