A repository (repo) is a storage location where Git keeps all project files, including the commit history, branches, and configuration.
Imagine you just created a new folder on your machine and want to start tracking your code with Git. What actually happens under the hood when you run git init, and where does Git store your project's history?
You've cloned a repository from GitHub, made some local commits, but your teammate says they can't see your changes on the remote. Walk me through how your local repository interacts with the remote repository to make those changes visible.
You accidentally copied a massive 2GB database file into your project folder, but you haven't run git add yet. Is that file part of your Git repository? How does Git distinguish between your working directory and the repository itself?
A developer on your team accidentally committed a 500MB database backup file to the repository three commits ago, and then deleted it in the latest commit. The repository size is still huge. How would you completely purge this file from the repository's history so it doesn't slow down clones?
You're working on a feature branch and your local machine suddenly crashes. After rebooting, Git tells you that your repository is corrupted or that a HEAD ref is broken. How would you go about diagnosing and recovering your work without losing your uncommitted changes?
We have a shared library that multiple projects use. We're debating whether to pull this library into our main repository as a Git submodule or keep it as a completely separate repository published to an internal package registry. What are the practical trade-offs of both approaches during daily development?
Our main application repository has grown to over 50GB with millions of commits, causing git clone and git status to take several minutes. What strategies or Git features would you implement to improve developer experience and speed up local repository operations?
We need to merge three historically separate repositories (frontend, backend, and shared-types) into a single monorepo while preserving the complete commit history, author metadata, and branch structures of all three. How would you execute this migration?
Your CI/CD pipeline is running slowly because it clones the entire repository on every build. How would you configure the runner's Git fetch/clone behavior to minimize network overhead and disk usage while still ensuring a clean build environment?
As we scale our engineering organization to 500+ developers, we are facing a critical decision: migrate our 150 microservice repositories into a single monorepo, or keep a polyrepo architecture and invest in custom tooling. How would you evaluate this decision, and what are the long-term architectural and cultural implications of each?
We are migrating a legacy, multi-gigabyte SVN repository with complex branch structures and custom access controls to Git. Walk me through your strategy for mapping SVN concepts to Git repositories, handling large binary assets, and ensuring zero-downtime for the engineering team during the transition.