Git Branching Strategies: What main, Feature Branches, and PRs Are Actually For
Branches, feature branches, and pull requests are not busywork on top of git -- each one exists to solve a specific problem with working on shared code.
A git repository's main branch, or master, in older repositories, exists to be a known-good, deployable snapshot of the project at all times. The convention of protecting main, requiring changes to come in through something other than a direct push, exists so that anyone on the team, or any deploy process, can check out main at any moment and trust that it builds and passes its tests, rather than needing to know which recent commit was actually safe.
A feature branch is a copy of that history you branch off to make changes in isolation, under a name like feature/add-search or fix/login-timeout, before those changes are considered part of main. The point of branching instead of committing directly to main is that your in-progress work, which might be broken, half-finished, or actively being reviewed, never touches the branch other people and other systems depend on being stable. You can commit as many rough, exploratory changes as you want on a feature branch, then clean up the history before it ever reaches main.
A pull request, or merge request, depending on the platform, is the step that turns a feature branch's changes into a proposal rather than a fait accompli. Opening a PR does not merge anything by itself, it is a diff, attached to a conversation, that lets teammates read the actual changes, leave comments on specific lines, and request changes before anything lands. Most teams also wire continuous integration to run automatically against every PR, so tests, linting, and builds run against the proposed change before a human even has to look at it, catching obvious breakage before it becomes someone else's problem on main.
How long feature branches live, and how strict the review process is, is where different teams diverge, some favor short-lived branches merged within a day or two, closer to trunk-based development, while others use longer-lived branches for larger features, sometimes organized under a heavier convention like git-flow with separate develop and release branches. There is no single correct answer, but the underlying reasons for the split, protecting a shared stable branch, isolating unfinished work, and requiring review before merging, hold regardless of which specific workflow a team layers on top of them.