Git Workflows Unpacked: GitFlow vs Trunk-Based Development Quiz

Explore the key differences and best practices of GitFlow and Trunk-Based Development workflows in git. This quiz helps you understand branching models, release strategies, and team collaboration techniques fundamental to efficient version control.

1. Branching Models Comparison

   Which Git workflow typically uses a 'develop' branch in addition to 'main' or 'master' to handle feature integration?

   1. GitFlow
   2. Trunk-Based Development
   3. Feature Branch Workflow
   4. Forking Workflow

   Explanation: GitFlow utilizes both a 'develop' and a 'main' branch to organize features and releases, making the integration process more structured. Trunk-Based Development discourages long-lived branches like 'develop', focusing mainly on a single shared branch. Feature Branch Workflow and Forking Workflow do not necessarily prescribe a 'develop' branch explicitly. This makes GitFlow unique in its explicit branching model.

2. Release Management Practices

   In Trunk-Based Development, how are releases usually managed when the team needs to ship production-ready code frequently?

   1. By cutting release branches only when necessary
   2. By maintaining separate long-lived release and develop branches
   3. By allowing direct pushes to the release branch only
   4. By tagging the staging branch before merging

   Explanation: Trunk-Based Development minimizes branch complexity by using temporary release branches only when needed for stabilization or deployment. GitFlow, by contrast, maintains permanent release and develop branches. Directly pushing to release or tagging staging branches are not best practices in this context and can introduce integration risks. Keeping minimal branching is core to Trunk-Based Development.

3. Team Collaboration Approaches

   What is a primary advantage of Trunk-Based Development for large teams working on a single product?

   1. It reduces merge conflicts by requiring short-lived feature branches.
   2. It requires each feature to be developed on long-lived branches.
   3. It delays integration until features are finished.
   4. It avoids using any branching strategies at all.

   Explanation: Trunk-Based Development encourages frequent integration to a common branch, which reduces the duration and risk of merge conflicts. Keeping feature branches short-lived ensures rapid feedback and smoother collaboration. Long-lived feature branches, delayed integration, and avoiding branching entirely can all create bigger issues for large teams. Thus, short development cycles are key in Trunk-Based Development.

4. Feature Flags Usage

   Why are feature flags often used alongside Trunk-Based Development in rapid delivery environments?

   1. They allow incomplete features to be merged without affecting all users.
   2. They ensure all branches stay up to date with 'develop'.
   3. They replace the need for code reviews.
   4. They automatically resolve all merge conflicts.

   Explanation: Feature flags enable teams to integrate partially completed features safely by controlling visibility to end users. This compatibility supports continuous delivery in Trunk-Based Development. They do not keep branches synced, serve as a replacement for code reviews, or resolve merge conflicts. Feature flags offer flexibility for shipping code safely and incrementally.

5. Release Frequency and Suitability

   In which scenario would GitFlow be more appropriate than Trunk-Based Development?

   1. A small team needs to support multiple parallel release versions for different customers.
   2. A team releases code to production multiple times daily.
   3. A project requires constant hotfixes applied directly to trunk.
   4. A solo developer working on quick, experimental changes.

   Explanation: GitFlow is designed for projects that require maintaining and supporting several release versions simultaneously, which is useful for teams dealing with different customer requirements. Trunk-Based Development is suited for frequent, rapid deployments and is not ideal for parallel release management. Applying hotfixes directly to trunk or experimental solo workflows would not benefit from GitFlow's structure. Therefore, GitFlow stands out when parallel version support is required.