An effective branching strategy for a collaborative project keeps main always stable and deployable, while all active work happens on short-lived feature branches that are reviewed and merged through pull requests.
Key Points: • main (or master) holds only stable, tested code that's ready to deploy at any time. • Each developer creates a dedicated branch per task or ticket, keeping changes isolated and easy to review. • Pull requests gate every merge into main, giving the team a chance to review code, run CI checks, and catch issues before they land. • Branches are deleted after merging to keep the repository clean and avoid confusion about which ones are still active. • A consistent naming convention, like feature/, bugfix/, or hotfix/, makes it immediately clear what each branch is for.
Example: A developer picks up ticket JIRA-482, creates feature/482-add-search-filter off main, opens a pull request when done, gets it reviewed and merged after CI passes, and the branch is deleted automatically once merged.
Interview Tip: A concise interview answer is:
"I keep main always stable and deployable, with every piece of work happening on a short-lived branch named after the ticket or feature. Pull requests gate merges into main so nothing lands without review and passing CI, and branches get deleted once merged to keep things tidy."