A branch is an independent line of development within a project. The Pro Git book describes branching as the ability to diverge from the main line of work and keep making changes separately, without disturbing that main line. When two branches have each had their own commits, the project’s history is said to diverge into parallel paths.
Merging is the reverse step: combining the work done on separate branches back into one. Pro Git explains that because the history records which commits came before which, a version-control system can find the right common starting point for two branches and bring their changes together. When the same lines were edited on both sides, the merge needs a decision about which change to keep, which is called a conflict.
Branching and merging are old ideas in version control, not inventions of Git. Tichy’s 1985 RCS paper already describes RCS handling revision trees with multiple branches, so that a fix could be developed on a side branch and later folded back into the main sequence of revisions.
What changed over time was the cost. In early systems, branching could be heavy, so it was used sparingly. Pro Git points out that Git makes a branch almost free - a small pointer to a commit - which is why modern teams branch constantly: a separate branch for each feature or fix, merged back when the work is ready. This pattern is the core of how teams now work on the same codebase in parallel.