Let’s understand Git and GitHub. This topic is not something you’ll do 99% of the time as a PM, but your developers will be using them constantly. You need to know what they are talking about and how to leverage the most of it.
Git and GitHub are foundational tools in software development. While you as a product manager won’t be writing code or managing Git commands day-to-day, understanding how these tools work is essential. Your developers use Git and GitHub constantly — they are the backbone of collaboration, version control, and release management.
This lesson teaches you what Git and GitHub are, why they matter, and how to use this knowledge to empathize with your engineering team and make better product decisions.
Git is a version control system that tracks your code history
At its core, Git is a distributed version control system — a tool that manages changes to a collection of files over time. Imagine your codebase as just a bunch of files and folders written in programming languages. Git tracks every change made to these files, creating snapshots called commits.
Each commit is a saved state of the entire project at a moment in time. This lets developers:
- Revert to previous versions if something breaks
- Experiment with new features safely by creating branches
- Collaborate without overwriting each other’s work
Git stores the full history locally on every developer’s machine. This distributed model means you can work offline, commit changes, and later sync with a central repository.
Team sync call with engineering
You (PM): “Can you walk me through how you manage code changes for this feature?”
Dev Lead: “Sure. We create feature branches off master. Each developer commits their changes locally, then pushes to GitHub. We open pull requests for code review before merging back to master.”
You (PM): “So if someone breaks something, you can revert to a previous commit?”
Dev Lead: “Exactly. Git keeps the full history, so we always have a safety net.”
This understanding helps you empathize when there are merge conflicts or deployment delays.
Understanding Git operations helps you collaborate better with developers and set realistic timelines.
GitHub is a web-based hosting service for Git repositories
GitHub builds on Git by providing a centralized, web-based platform to host Git repositories. Think of GitHub as a social network for developers:
- You can browse anyone’s code publicly
- You can fork (copy) repositories to your own account to experiment
- You can submit pull requests to suggest changes to others’ projects
- You can track issues, manage projects, and review code
GitHub acts as the “source of truth” for your team’s codebase and is tightly integrated with your software development workflow.
Key Git terminology every PM should know
Understanding these terms will help you follow conversations and appreciate engineering constraints:
| Term | Description |
|---|---|
| Repository | A folder tracked by Git that contains all project files and their history. |
| Branch | An independent line of development, like a parallel version of the codebase. |
| Fork | A personal copy of someone else’s repository, usually on GitHub, to experiment or contribute. |
| Clone | A copy of a repository stored locally on a developer’s machine. |
| Commit | A snapshot of changes made to files, identified by a unique ID and message. |
| Master/Main | The default development branch where stable code lives. |
Knowing these helps you understand developer workflows and the impact of changing code on different branches.
Git and GitHub power your release process
Git and GitHub are not just about code history — they directly tie into how your team ships software.
- Your branching strategy affects how features are developed and tested. For example, teams may use feature branches for new work, hotfix branches for urgent bug fixes, and release branches for preparing production releases.
- The release process depends on how code moves from development branches into production. Some teams deploy continuously; others bundle changes into scheduled releases.
- DevOps engineers optimize these workflows to minimize merge conflicts, reduce bugs in production, and automate deployments.
You should understand your team’s branching strategy
Every team’s branching strategy is different. It’s worth spending time with your engineers to learn:
- Do they use feature branches for every new feature?
- Is there a master/main branch that always reflects production-ready code?
- Are there hotfix branches for urgent bugs?
- How often do they merge code back to main?
- How do they handle release branches or staging environments?
Knowing this helps you empathize with merge conflicts, deployment delays, and QA bottlenecks.
- Schedule a 30-minute session with your engineering lead or DevOps engineer.
- Ask them to explain the branching strategy and how code flows from development to production.
- Take notes on branch types, merge policies, code review processes, and deployment frequency.
- Reflect on how this process impacts your product roadmap and release planning.
- Share a summary of your learnings with your product team.
Connecting to GitHub securely with SSH keys
Developers often connect to GitHub using SSH keys rather than passwords. SSH (Secure Shell) keys are cryptographic keys that authenticate your machine to GitHub without typing a password every time.
The typical process involves:
- Generating an SSH key pair on your machine
- Adding the SSH private key to the SSH agent
- Adding the SSH public key to your GitHub account
This setup enables secure and seamless communication between your local Git client and GitHub.
Onboarding new developer
You (PM): “I heard you set up SSH keys for GitHub access. Can you explain why?”
Dev: “Yes. It’s more secure than passwords and avoids repeated prompts. I generated my SSH key, added it to the ssh-agent, and then added the public key to GitHub.”
You (PM): “Good to know. I’ll make sure new hires get this setup guide.”
Secure GitHub access is essential for developer productivity and security.
How to generate an SSH key (developer workflow)
Developers typically use Git Bash or terminal to generate SSH keys with:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
This command creates a new RSA key pair labeled with the developer’s email. They then add the private key to the SSH agent and copy the public key to GitHub.
Steps:
- Open Git Bash or terminal.
- Run the ssh-keygen command with your email.
- Accept the default file location or specify a custom path.
- Enter a secure passphrase or leave empty.
- Start the ssh-agent and add your private key.
- Copy the public key (
id_rsa.pub) and add it to your GitHub account under Settings > SSH and GPG keys.
This process is usually done once per machine.
Why PMs should understand this workflow
You won’t run these commands yourself, but understanding the process helps you:
- Appreciate developer onboarding hurdles
- Recognize why SSH key misconfigurations cause access issues
- Communicate effectively with DevOps and engineering leads about developer productivity blockers
GitHub repositories are the central source of truth
Think of GitHub as the central repository where your team’s code lives. Developers clone repositories to their machines, make changes, commit them, and push back to GitHub.
Your team’s local Git repositories are copies of this central source. GitHub manages permissions, collaboration, pull requests, and version history.
Understanding this helps you:
- Know where to look for the latest code
- Understand how pull requests and code reviews fit into your process
- Track deployment versions and rollback points
Test yourself: Prioritizing release blockers
You are a PM at a Series A SaaS startup in Bangalore. The engineering lead reports that a critical hotfix branch has merge conflicts blocking deployment. The release was scheduled in 3 days, and the marketing team is planning a launch event in 5 days.
The call: How do you prioritize resolving the merge conflicts versus preparing marketing materials? How do you communicate the risks to stakeholders?
Your reasoning:
You are a PM at a Series A SaaS startup in Bangalore. The engineering lead reports that a critical hotfix branch has merge conflicts blocking deployment. The release was scheduled in 3 days, and the marketing team is planning a launch event in 5 days.
Your task: How do you prioritize resolving the merge conflicts versus preparing marketing materials? How do you communicate the risks to stakeholders?
your reasoning:
Where to go next
- Learn how to work with engineering teams: Engineering Collaboration
- Understand software release planning: Release Management
- Get hands-on with Git basics: Git for Beginners
- Explore DevOps fundamentals: DevOps and Continuous Delivery
- Improve your technical fluency: Technical Concepts for PMs
PL alumni now work at Flipkart, Razorpay, Swiggy, PhonePe, and other top tech companies.