If you’re not sure what your branching strategy is, spend time with your team to understand how a feature gets built. That knowledge helps you empathize when things go wrong.
Git and GitHub are foundational tools that your engineering team uses daily to manage the product’s codebase. You will rarely write code yourself — 99% of the time, you won’t — but understanding how Git and GitHub work is essential to empathizing with your developers and anticipating blockers in your delivery pipeline.
Your actual job is to understand how the code evolves, how releases happen, and what can cause delays or conflicts. This allows you to plan better, communicate effectively, and avoid surprises.
What Git and GitHub really are
At its core, Git is a distributed version control system. Think of it as a system that tracks every change made to a collection of files — typically your product’s source code — over time. It allows developers to save snapshots of their work, revert to previous versions if needed, and collaborate without overwriting each other’s changes.
GitHub is a cloud-based platform built on Git. It hosts repositories — collections of code and their full history — making it easy for teams to collaborate remotely. GitHub adds tools like pull requests, code reviews, issue tracking, and continuous integration.
Imagine your codebase as a large set of text files and folders. When a developer writes code, they create a snapshot of those files and commit it to the repository. Each commit has a unique identifier and a message explaining the change.
This creates a timeline of changes. You can compare commits, see what was added or removed, and understand how the product evolved.
Product team sync with engineering
You (PM): “Can someone explain how you manage the code changes for our product?”
Neha (Engineering Lead): “Sure. We use Git to track all code changes. Every developer works on their own branch and creates commits as they progress.”
You (PM): “What’s a branch?”
Neha: “It’s like a separate workspace for a feature. Developers can work independently without affecting the main codebase.”
You (PM): “And GitHub?”
Neha: “GitHub hosts our repositories and lets us review code before merging it back to the main branch.”
This conversation sets the foundation for you to understand the delivery process better.
Understanding Git and GitHub bridges the gap between PM and engineering teams.
Branching strategies: how code changes flow into your product
A branching strategy defines how developers create and merge branches in Git. It shapes how features, bug fixes, and releases are managed. Different teams use different strategies, but common patterns include:
- Feature branches: Developers create a branch per feature. Once complete, they merge it into the main branch.
- Master/main branch: The stable production-ready code lives here.
- Hotfix branches: For urgent fixes to production.
- Release branches: For preparing a set of features for a release.
Knowing your team’s branching setup is critical. It helps you understand why a feature might be delayed or why merges sometimes cause conflicts.
If you don’t know what branching strategy your team uses, spend time with them to learn it. When a merge conflict arises or a feature is blocked, you’ll understand the root cause instead of being frustrated.
Release processes are your delivery heartbeat
Git and GitHub connect directly to your release process — the way your team pushes code changes into production.
Releases can be simple or complex. Some teams release daily or multiple times a day (continuous deployment). Others release weekly, monthly, or less frequently.
If you haven’t seen a release happen end-to-end, sit with your engineering team and watch. Ask:
- How long does a release take?
- How many engineers are involved?
- What manual steps exist?
- What are the common blockers?
If a release takes two days and four engineers, that’s a problem. It means your delivery pipeline is slow and fragile. This impacts your roadmap and your ability to respond to user needs quickly.
Continuous deployment — where every commit that passes automated tests goes live immediately — is the ideal state. It dramatically improves speed and reduces risk.
DevOps and the role of automation in your product delivery
DevOps is a culture and set of practices that automate and improve the software delivery process. Git and GitHub are part of the DevOps toolchain.
Ask your engineering team:
- Do you have a dedicated DevOps engineer?
- How automated are your build, test, and deployment pipelines?
- How do you handle production bugs and rollbacks?
A dedicated DevOps person helps optimize developer workflows. When merges fail or production bugs occur, they ensure quick resolution.
Without automation, your releases are slow and error-prone. That creates technical debt and delivery risk.
Sprint retrospective with product and engineering
You (PM): “We had three release rollbacks this sprint. What went wrong?”
Karthik (DevOps): “Our deployment scripts had manual steps prone to error. We’re working on automating them.”
You (PM): “How will automation help?”
Karthik: “It reduces human error and speeds up rollbacks. We aim for zero-downtime releases.”
You (PM): “Great. Can you share your roadmap so I can align feature plans accordingly?”
Karthik: “Will do.”
Manual release steps cause delays and risk. Automation is key to healthy delivery.
The PM’s role in bridging tech and product delivery
Your job is not to learn Git commands or write code. But you must understand enough to:
- Empathize with engineering challenges.
- Anticipate blockers caused by branching conflicts or slow releases.
- Include release cycles and DevOps capacity in your roadmap planning.
- Communicate realistically with stakeholders about delivery timelines.
This understanding helps you avoid the trap of overpromising and underdelivering.
- Schedule a session with your engineering lead or DevOps engineer.
- Observe a release cycle from code commit to production deployment.
- Document the steps involved, who is responsible, and typical duration.
- Identify manual steps and bottlenecks.
- Share your findings with your product team and update your roadmap assumptions accordingly.
Test yourself
You are a PM at a Bangalore-based SaaS startup preparing for a major feature release. Your engineering team uses feature branches and GitHub pull requests. One developer reports a merge conflict that blocks the release. The release process involves manual steps and takes two days with three engineers.
The call: How do you respond to this situation to keep the release on track and manage stakeholder expectations?
Your reasoning:
You are a PM at a Bangalore-based SaaS startup preparing for a major feature release. Your engineering team uses feature branches and GitHub pull requests. One developer reports a merge conflict that blocks the release. The release process involves manual steps and takes two days with three engineers.
Your task: How do you respond to this situation to keep the release on track and manage stakeholder expectations?
your reasoning:
Where to go next
- Learn how to collaborate effectively with engineering: Engineering Collaboration
- Understand product delivery workflows: Agile and Scrum for PMs
- Explore DevOps and automation basics: DevOps Fundamentals
- Improve your roadmap planning with technical constraints: Roadmap Planning and Execution