In software engineering, branches are used in version control to separate work done on a project by contributor or by feature and to prevent conflicts.
In Git, master is a pointer to commit at tip of branch. By convention, it’s the most important and longest lived branch. Sometimes called main. head is also a pointer, except to the branch we’re working on. Each developer has their own head.
Creating a new branch means work can proceed independently. Visually it’s like we create a new path in a tree. Then we can do git merge to purely merge files. But what if files have changed? We can do: git rebase branch-usually-master. This “replays” branch commits on the specified branch and can make git log easier to understand. Can cause more conflicts than merge if we rebase infrequently.
Versioning
What’s the point?
Release branches are used to stabilise, do final testing and fixes on, before we release the final executable to customers and we don’t want new features coded and integrated during this time. New development continues on the master branch. Release branches are long lived (Quartus 18.1, MS Word 2022).
Or feature branches during development. We make a new branch for a new feature. Develop, test, iterate. When it works well, we merge or rebase onto the master branch. Should be short lived. The longer the branch lives, the more we get conflict changes.
A good guideline to follow for software libraries is semantic versioning, which follows a version number MAJOR.MINOR.PATCH. We increment:
- MAJOR version when there’s incompatible API changes.
- MINOR changes when functionality is added in a backward compatible manner.
- PATCH for when there’s backward-compatible bug fixes.
See also
- Branch, a conditional statement in computer organisation