Which statement best describes the Git workflow difference between GitHub Flow and Git Flow, and a key difference?

Which statement best describes the Git workflow difference between GitHub Flow and Git Flow, and a key difference?

• A. GitHub Flow relies on a rigid branching model with develop and release branches.
• B. Git Flow focuses on continuous deployment with short-lived feature branches.
• C. GitHub Flow uses feature branches and pull requests into main for frequent releases; Git Flow uses a structured set of branches (develop, release, hotfix) for planned release cycles.
• D. GitHub Flow avoids code reviews.

Answer: (C)

Git workflows differ in how they structure branches and releases. GitHub Flow favors rapid, continuous delivery: you create lightweight feature branches off the main line, open a pull request to merge back into main, review and merge, and deploy frequently. This keeps the main branch deployable and supports frequent releases. Git Flow, in contrast, uses a more formal set of branches—develop for integration, release branches for preparing a release, and hotfix branches for urgent fixes—designed to support planned release cycles with clear stages. The main difference is moving from a lightweight, continuous-delivery pattern to a structured workflow that gates releases through specific branches. The other statements don’t fit the real behaviors: GitHub Flow isn’t a rigid branching model, it typically involves code reviews via pull requests, and Git Flow isn’t focused on continuous deployment but on planned release management.

Git workflows differ in how they structure branches and releases. GitHub Flow favors rapid, continuous delivery: you create lightweight feature branches off the main line, open a pull request to merge back into main, review and merge, and deploy frequently. This keeps the main branch deployable and supports frequent releases.

Git Flow, in contrast, uses a more formal set of branches—develop for integration, release branches for preparing a release, and hotfix branches for urgent fixes—designed to support planned release cycles with clear stages. The main difference is moving from a lightweight, continuous-delivery pattern to a structured workflow that gates releases through specific branches.

The other statements don’t fit the real behaviors: GitHub Flow isn’t a rigid branching model, it typically involves code reviews via pull requests, and Git Flow isn’t focused on continuous deployment but on planned release management.