Use Cases

  • Small teams or individual developers
  • Simple projects with basic version control needs
  • Projects just starting to adopt git
  • When continuous integration is not in use

Components

  • master (main-branch): The main branch that always reflects production-ready code
  • feature branches (supporting-branch): Short-lived branches for developing specific features
  • merge policy (policy): Two schools of thought exist. Fast-forward (--ff) merges produce a linear history but lose the branch topology. Merge commits (--no-ff) preserve the fact that commits belonged to a feature branch, which aids tools like GitHub and GitLab that surface per-branch history. Teams should consciously choose one and enforce it.

Steps

  1. Step 1: Create feature branch: Create a new branch from master with a descriptive name (e.g., feature/user-authentication)
  2. Step 2: Develop feature: Commit changes to the feature branch as work progresses
  3. Step 3: Merge to master: When the feature is complete and tested, merge the branch back into master. Fast-forward merge gives clean linear history; merge commit (--no-ff) preserves branch context in the history graph. Choose based on your team's needs.
  4. Step 4: Delete feature branch: Delete the feature branch after successful merge to keep branch list clean

Workflow Diagram

gitGraph commit id: "A" branch feature/user-auth checkout feature/user-auth commit id: "B" commit id: "C" checkout main merge feature/user-auth id: "D"
Step 1 of —

Common Gotchas

  • Long-lived feature branches: Feature branches that exist for weeks or months can become difficult to merge as master diverges, leading to painful conflict resolution important
  • No explicit release preparation: Since all features go directly to master, there's no staging area to prepare releases or test feature combinations important
  • Difficult to ship partial features: Feature flags or conditional logic are required if you need to merge incomplete features mild
  • Hotfixes go through same workflow: There's no dedicated hotfix workflow, so urgent fixes must wait for normal feature branch process or bypass code review entirely important
  • Fast-forward merges lose branch topology: If using fast-forward merges, git log cannot show which commits were on a feature branch. Tools like GitHub show merged branch history, but raw git log looks identical to direct trunk commits. --no-ff merge commits preserve this context. mild

Best Practices

  • Keep feature branches short-lived (preferably less than a few days)
  • Use descriptive branch names (feature/description or bugfix/description)
  • Pull from master into feature branch regularly to stay current and reduce merge pain
  • Delete merged branches immediately to keep the branch list clean
  • Use pull requests for code review before merging, even on small teams
  • Decide on --ff vs --no-ff merge strategy explicitly and enforce it in branch settings

Pros and Cons

Pros

  • Simple to understand and implement
  • Works well for small teams and individual developers
  • No complex branching rules to remember
  • Easy to trace feature history through branch names
  • Low overhead compared to more complex workflows

Cons

  • Doesn't scale well to large teams — no integration branch means all merges land directly in master
  • Difficult to manage simultaneous long-running features without conflicts
  • No structured release process or release stabilization period
  • No built-in hotfix workflow
  • No explicit environment-based branching

Real-World Examples

  • Small startups and solo developers: Almost every team that graduates from "everyone commits to main" starts here. GitHub's own Getting Started documentation uses this model as the introductory workflow, making it the default starting point for millions of developers.
  • Open-source projects with few maintainers: Many small OSS projects (single maintainer or 2-3 collaborators) use feature branches and merge directly, without the overhead of Gitflow. A typical pattern is feature/fix branches from main, PR review, then fast-forward or squash merge.