Git Notes
Learn the Feature Branch Workflow where all development happens in dedicated branches. Understand the complete lifecycle from branch creation to merge.
The Feature Branch Workflow is the foundation of modern Git collaboration and the workflow most teams use today. The concept is beautifully simple: the main branch is always stable and deployable, and every piece of new work — whether a feature, bug fix, or experiment — happens in a dedicated branch. Changes reach main only through Pull Requests after code review and automated checks pass.
This workflow strikes an excellent balance between safety and simplicity. It is straightforward enough for junior developers to learn quickly, yet structured enough to prevent the disasters that come from pushing directly to production code.
Core Principles
- Main is always deployable — You could ship main to production at any moment without fear
- One branch per unit of work — Each feature, fix, or task gets isolation
- Pull Requests gate integration — No code reaches main without review
- Short-lived branches — Merge within days, not weeks, to avoid divergence
- Delete after merge — Keep your branch list clean and relevant
The Visual Flow
Each branch diverges from main, accumulates focused commits, and rejoins through a reviewed merge. The main branch maintains a clean, tested, working state at all times.
Step-by-Step Process
1. Start from Latest Main
git checkout main
git pull origin main # Always start with the latest code2. Create a Descriptive Branch
# Include the type and brief description
git checkout -b feature/user-notifications
# Good naming conventions:
# feature/JIRA-123-user-notifications
# fix/login-timeout-error
# refactor/extract-auth-middleware
# docs/api-authentication-guide3. Develop with Frequent Commits
# Make atomic, logical commits as you work
git add src/models/notification.js
git commit -m "feat: add notification data model"
git add src/services/notification-service.js
git commit -m "feat: implement notification delivery service"
git add src/components/NotificationBell.jsx
git commit -m "feat: add notification bell UI component"
git add tests/notification.test.js
git commit -m "test: add notification service unit tests"4. Push to Remote Regularly
# First push sets up tracking
git push -u origin feature/user-notifications
# Subsequent pushes
git pushPushing daily provides backup, visibility to teammates, and enables early feedback.
5. Keep Your Branch Updated
# Option 1: Rebase (preferred - clean linear history)
git fetch origin
git rebase origin/main
# If conflicts arise during rebase:
# Edit conflicted files, then:
git add .
git rebase --continue
# Option 2: Merge main into feature (simpler, noisier history)
git merge main6. Open a Pull Request
Create the PR on GitHub with:
- Clear title describing the change
- Description explaining WHY, not just what
- Screenshots for UI changes
- Link to the issue or ticket
- Self-review before requesting others
7. Address Review Feedback
# Make requested changes
git add .
git commit -m "fix: address review - add input validation"
git push
# PR updates automatically8. Merge and Clean Up
# After approval and CI passes, merge on GitHub
# Then locally:
git checkout main
git pull origin main
git branch -d feature/user-notificationsKeeping Branches Short-Lived
Long-lived branches are the enemy of smooth collaboration. Here is why:
# Branch created Monday, merged Friday (GOOD)
# - Small diff, easy to review
# - Few or no conflicts with main
# - Teammates see changes quickly
# Branch created January, merged March (BAD)
# - Massive diff, nobody wants to review 3000 lines
# - Major conflicts with months of main changes
# - High risk of integration bugs
# - Knowledge silos formIf a feature takes longer than a few days, break it into smaller mergeable pieces. Use feature flags to hide incomplete functionality.
Best Practices for Feature Branches
- Branch from latest main — Start with the most current code
- One purpose per branch — Do not mix features, refactoring, and bug fixes
- Push daily — Provides backup and team visibility
- Update from main regularly — At least once daily to catch conflicts early
- Write clear commit messages — Each commit should tell a story
- Keep PRs under 400 lines — Smaller reviews are faster and catch more bugs
- Delete branches after merging — Avoid stale branch accumulation
- Use draft PRs for work-in-progress — Signal that work is not ready for review
Common Mistakes
Mistake 1: Never updating from main. The longer you go without syncing, the worse your eventual merge conflict will be.
Mistake 2: Creating branches from other feature branches. This creates dependency chains that are hard to merge. Always branch from main unless absolutely necessary.
Mistake 3: Mixing unrelated changes in one branch. "While I was in there, I also refactored the auth module" makes PRs hard to review and impossible to revert cleanly.
Mistake 4: Letting branches grow too large. If your PR has 2000+ lines, you waited too long. Break features into vertical slices that can be merged independently.
Interview Questions
Q1: What is the Feature Branch Workflow?
A Git workflow where every feature, bug fix, or task is developed in a dedicated branch created from main. Changes are integrated back through Pull Requests after code review and CI checks pass. Main remains always deployable.
Q2: Why should feature branches be short-lived?
Long-lived branches diverge significantly from main, leading to large complex merges, more conflicts, and higher risk of integration issues. Short branches (1-3 days) produce smaller, manageable diffs that are easier to review and less likely to conflict.
Q3: How do you handle a feature that takes weeks to build?
Break it into smaller independently mergeable pieces. Use feature flags to hide incomplete work in production. Each piece gets its own short-lived branch and PR, keeping the main branch moving forward without blocking on one large effort.
Q4: Should you rebase or merge main into your feature branch?
Rebase produces cleaner linear history and is preferred for feature branches that have not been shared. Merge preserves exact history. Many teams standardize on rebase for feature branches and merge commits for integration into main.
Q5: What is the relationship between Feature Branch Workflow and GitHub Flow?
GitHub Flow IS the Feature Branch Workflow with the specific addition of Pull Requests for code review and the convention that main is always deployable. They are the same core workflow with GitHub's collaboration tooling layered on top.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Feature Branch Workflow - Isolate Development Work.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, real, world, workflows, feature
Related Git & GitHub Topics