Branches are usually parallel development flows that are independent of each other. Like a timeline. Here is a software project with several branches.
You may have a branch that contains all of your stable work, for example, and another that contains experimental work. You may have another intermediate branch between which is used to qualify changes from the experimental branch before moving it to a stable one. These are all branching strategies . Different teams may have different branches, etc.
Depending on your version control system, the implementation and use of branches can be significantly different. In centralized version control systems (such as SVNs), a branch is essentially a copy of the whole source code during branching (similar to cp -R in the file system). After this, development will continue on this branch, independent of the main one. So you will have something like this
--o---0---o---o---o---- (parent branch) \ \---o---o---0--- (new branch)
o means commit, and 0 is the branch point. The branches that you make with this system are global (each of you can see them in the project), and they are quite heavy. You can merge return the new branch back to the parent branch. This may result in merge conflicts .
With decentralized VCs (I use git as an example), branches are much lighter. They simply indicate a position in the DAG that represents the history of your project. You can force them forward by creating a new commit. In addition, the branches will be local (i.e. only you can see them if you do not decide to publish them).
However, forking and merging have some conceptual content that you cannot understand without reading documents. I would suggest that you look at the VCS documentation you are using and return to the stack overflow with specific questions if you have any.