Principles of Product Management: Version Control (Git Concepts, Branching, PRs – What PMs Need to Know)

Version Control (Git Concepts, Branching, PRs – What PMs Need to Know)

Version Control (Git Concepts, Branching, PRs – What PMs Need to Know)

What This Is

Version control (Git) is the system that tracks changes to code, enabling teams to collaborate safely, experiment with features, and roll back mistakes. For PMs, understanding Git workflows—like branching, pull requests (PRs), and merges—isn’t about writing code but orchestrating how features are built, tested, and shipped. Example: A fintech startup launching a "One-Click Checkout" feature might use Git branches to isolate the work (e.g., feature/one-click-checkout), test it in staging, and merge it to main only after security reviews and user testing. Without Git, teams risk overwriting work, deploying broken code, or losing track of what’s live.

Key Terms & Frameworks

• Git: Distributed version control system (VCS) that tracks code changes. Think of it as "Google Docs for code," where every change is saved as a snapshot.
• Repository (Repo): A project’s folder where Git tracks all changes. Can be local (on your machine) or remote (e.g., GitHub, GitLab).
• Branch: A parallel version of the code. Example: main (production-ready code), feature/x (work in progress), hotfix/y (urgent bug fixes).
• Commit: A saved change to the code (like a "save point"). Each commit has a unique ID (hash) and a message (e.g., "Fix login button alignment").
• Merge: Combining changes from one branch into another (e.g., merging feature/x into main).
• Pull Request (PR) / Merge Request (MR): A request to merge a branch into another, with a discussion thread for code review. PMs use PRs to track feature progress and unblock engineers.
• Conflict: When Git can’t automatically merge changes (e.g., two engineers edit the same line of code). Requires manual resolution.
• Staging Environment: A replica of production where code is tested before release. PMs often demo features here to stakeholders.
• CI/CD (Continuous Integration/Continuous Deployment): Automated pipelines that test and deploy code. Example: GitHub Actions runs tests on every PR before allowing a merge.
• Trunk-Based Development: A workflow where engineers merge small, frequent changes into main (vs. long-lived feature branches). Reduces merge conflicts and speeds up releases.
• Git Flow: A branching model with main, develop, feature, release, and hotfix branches. Overkill for most modern teams (trunk-based is preferred).
• Semantic Versioning (SemVer): MAJOR.MINOR.PATCH (e.g., 2.5.1). PMs use this to communicate release impact (e.g., "This is a MINOR update with new features, no breaking changes").

Step-by-Step / Process Flow

How a PM Engages with Git Workflows (Example: Launching a "Dark Mode" Feature)

1. Align on the Branch Strategy
2. Work with engineering to define branches (e.g., feature/dark-mode for the new feature, main for production).

3. PM Action: Document the branching strategy in the PRD (Product Requirements Doc) so stakeholders know where to test.

4. Track Progress via PRs

5. Engineers open a PR when the feature is ready for review. PMs:

   
   
   • Add the PR link to the Jira ticket/Asana task.
   • Check the PR description for demo links (e.g., a staging URL to test the feature).
   • Pro Tip: Use GitHub’s "Reviewers" feature to tag QA, design, or other PMs for feedback.

6. Coordinate Testing in Staging

7. Once the PR is merged into develop (or a staging branch), test the feature in the staging environment.

8. PM Action: Run a quick user test (e.g., 5 internal users) and log bugs as GitHub issues.

9. Greenlight the Merge to main

10. After QA signs off, the PR is merged to main and deployed to production.

11. PM Action: Update the release notes (e.g., "Dark Mode now available in Settings!") and notify customer support.

12. Monitor Post-Launch

13. Use tools like Sentry or Datadog to track errors. If bugs arise, engineers create a hotfix branch.
14. PM Action: Monitor metrics (e.g., adoption rate of Dark Mode) and prioritize follow-up work (e.g., "Dark Mode for mobile").

Common Mistakes

• Mistake: Assuming "merged to main" = "shipped to users." Correction: Merging to main often triggers a CI/CD pipeline (e.g., automated tests, deployment to staging). PMs should confirm the feature is live in production (e.g., check the app/website).

• Mistake: Ignoring PRs until the last minute.
  Correction: PRs are a PM’s early warning system. Review them early to catch misaligned work (e.g., an engineer building a "Dark Mode" toggle in the wrong place).

• Mistake: Letting engineers work in long-lived branches (e.g., feature/x for 3 months).
  Correction: Advocate for trunk-based development or short-lived branches (max 1–2 weeks). Long branches = merge hell and delayed feedback.

• Mistake: Not documenting the branching strategy.
  Correction: Add it to the PRD or team wiki. Example: "All features must be merged to develop by EOD Thursday for Friday’s release."

• Mistake: Treating Git as "engineering’s problem." Correction: Git workflows directly impact your roadmap. Example: If engineers are stuck resolving merge conflicts, your feature launch is delayed.

PM Interview / Practical Insights

1. "How would you handle a situation where a critical bug is found in production, but the team is midway through a major feature release?"
2. What they’re testing: Your ability to prioritize and understand Git workflows.

3. Answer: Advocate for a hotfix branch (e.g., hotfix/login-bug) to fix the bug immediately, then merge it to main and develop. The feature branch can continue separately. Use SemVer to label the hotfix (e.g., v1.2.1).

4. "An engineer says, ‘This PR is ready to merge.’ What questions do you ask?"

5. What they’re testing: Your attention to detail and cross-functional collaboration.

6. Answer:

   
   
   • "Has QA signed off?" (Avoid shipping bugs.)
   • "Is there a demo link or staging URL to test?" (Verify the feature works.)
   • "Are there any open discussions in the PR?" (Unblock engineers.)
   • "Does this align with the acceptance criteria in the PRD?" (Ensure scope is correct.)

7. "How do you decide when to merge a feature branch into main?"

8. What they’re testing: Your understanding of risk management and stakeholder alignment.

9. Answer: Use a checklist:

   
   
   • Code review passed.
   • QA tested in staging.
   • PM/demoed to stakeholders (e.g., design, legal).
   • Metrics are instrumented (e.g., analytics for the new feature).
   • No open high-priority bugs.

10. Tricky Distinction: "Feature Branch vs. Trunk-Based Development"

11. Feature Branch: Long-lived branches (e.g., feature/x for weeks). Slower, but safer for big changes.
12. Trunk-Based: Small, frequent merges to main. Faster, but requires strong CI/CD and testing.
13. When to use which: Feature branches for complex features (e.g., a new payment flow); trunk-based for iterative improvements (e.g., tweaking a button).

Quick Check Questions

1. Your team is using Git Flow, and the release/2.0 branch is delayed by 2 weeks. Marketing has already announced the launch date. What do you do?
2. Answer: Work with engineering to split the release into smaller batches (e.g., ship 2.0.0 with core features, then 2.0.1 with extras). Communicate the change to stakeholders and adjust marketing materials.

3. Why: Git Flow’s rigid structure can cause delays. Trunk-based development or feature flags are more flexible.

4. An engineer says, ‘We can’t merge this PR because of conflicts.’ What’s your next step?

5. Answer: Ask the engineer to resolve the conflicts locally, then rebase the branch onto main. If it’s complex, suggest a pair programming session or a code walkthrough.

6. Why: Merge conflicts block progress. PMs should unblock engineers by clarifying priorities (e.g., "Fix this now vs. later").

7. You’re launching a feature, but the PR is stuck in review for 5 days. How do you unblock it?

8. Answer: Identify the bottleneck (e.g., reviewer is OOO, unclear feedback). Escalate to the tech lead or assign a backup reviewer. If the feedback is vague, schedule a sync to clarify.
9. Why: PRs are a PM’s responsibility too—delays here = delays to your roadmap.

Last-Minute Cram Sheet

1. Git = "Google Docs for code" – tracks changes, enables collaboration.
2. Branch types: main (production), feature/x (WIP), hotfix/y (urgent fixes).
3. PR = Pull Request – request to merge code + discussion thread. PMs use this to track progress.
4. Merge conflict = Git can’t auto-merge changes (e.g., two engineers edit the same line).
5. Staging environment = replica of production for testing. PMs demo features here.
6. CI/CD = automated testing/deployment (e.g., GitHub Actions runs tests on PRs).
7. Trunk-based development = small, frequent merges to main (faster releases).
8. SemVer = MAJOR.MINOR.PATCH (e.g., 2.5.1). PMs use this to communicate release impact.
9. ⚠️ "Merged to main" ≠ "shipped to users" – check production!
10. ⚠️ Long-lived branches = merge hell – advocate for trunk-based or short-lived branches.