10 Git & GitHub Interview Questions — সহজ Bangla Answer

Git is a distributed version control system created by Linus Torvalds in 2005. It tracks changes to source code, allows multiple developers to work on the same project in parallel, and enables you to revert to previous versions at any time.

"Git is the most widely-used version control system in software development. It's distributed, meaning every developer has a full copy of the project history on their machine — not just the latest version. This makes it fast, reliable, and works offline. Git tracks file changes through snapshots called commits, allowing teams to collaborate, review code, and maintain a complete audit trail of who changed what and when."

Git is a software that runs on your computer to track code changes locally. GitHub is a web platform that hosts Git repositories online and adds collaboration features like Pull Requests, Issues, and code review tools.

"Think of Git as the engine and GitHub as the dashboard. Git handles version control locally on my machine — it can work without internet. GitHub is owned by Microsoft and provides a cloud-based home for Git repositories. It adds features like Pull Requests for code review, Issues for bug tracking, Actions for CI/CD, and Pages for free hosting. There are alternatives like GitLab and Bitbucket, but GitHub is the industry standard."

A commit is a snapshot of your project at a specific point in time, with a unique ID, author, timestamp, and message describing the change.

"When I make changes to files and want to save them permanently in Git history, I create a commit. Each commit captures the exact state of all tracked files at that moment. It has a unique SHA-1 hash like a3f2c1b, my name and email, a timestamp, and a commit message explaining what changed and why. Commits form a chain — each one references its parent — creating the full project history."

A branch is an independent line of development that lets you work on new features or fixes without affecting the main codebase.

"Branches let teams work in parallel safely. The main branch holds production-ready code. When I work on a new feature, I create a feature branch like feature-login, do my work there, commit changes, and only merge back to main when it's ready and reviewed. This keeps main stable, allows multiple developers to work simultaneously without conflicts, and supports the standard pull request workflow used by every modern tech team."

Merge is the process of combining the changes from one branch into another, typically merging a feature branch back into the main branch.

"When my feature branch is complete, I merge it back to main. Git combines the commit history from both branches. There are different merge types — a fast-forward merge happens when there are no new commits on main since the branch was created. A three-way merge creates a new merge commit combining both histories. If two branches modified the same lines, Git will raise a merge conflict that I have to resolve manually."

A Pull Request is a formal request to merge changes from one branch into another, typically used for code review before merging to main.

"A PR is GitHub's collaboration cornerstone. After pushing a feature branch, I open a PR which shows the diff between my branch and the target branch. My teammates can review the code line by line, leave comments, suggest changes, and approve or request modifications. Once approved, the maintainer merges the PR. PRs enable code review, knowledge sharing, and catch bugs before they hit production. They're standard practice at every tech company I know of."

A merge conflict happens when Git cannot automatically combine two changes to the same line of code. You resolve it by manually editing the file, choosing which version to keep, then committing.

"Merge conflicts occur when two branches modify the same lines differently. Git marks the conflict with <<<<<<<, =======, and >>>>>>> markers, showing both versions. To resolve: I open the file, decide which version to keep — or combine them — remove all conflict markers, save the file, then run git add and git commit to finalize. VS Code has a built-in conflict resolver that makes this easier. Conflicts are normal — every developer faces them weekly."

git pull fetches the latest changes from the remote repository and merges them into your current local branch.

"git pull is actually two commands combined: git fetch downloads new commits from the remote without changing local files, and git merge integrates those changes into the current branch. I always run git pull before starting work each day to make sure I'm working on the latest version. If I skip this and teammates have made changes, I'll likely face conflicts when I try to push."

git push uploads your local commits to a remote repository (typically GitHub), making them available to teammates.

"After committing my changes locally, git push sends those commits to the remote. The first time I push a new branch, I use git push -u origin branch-name to set the upstream — then subsequent pushes just need git push. If someone else has pushed changes to the same branch since my last pull, Git will reject my push and ask me to pull first to integrate their changes."

Git enables parallel development, code review, version history, safe experimentation, and backup/recovery — making team collaboration possible at any scale.

"Git solves the fundamental problem of multiple people changing the same code. Key benefits: (1) Parallel work — everyone has their own branch and doesn't block others. (2) Code review — PRs catch bugs and share knowledge. (3) History & audit — we know exactly who changed what and why. (4) Rollback — bad changes can be reverted instantly. (5) Backup — every developer has a full copy. (6) Branching for experiments — try risky ideas without breaking main. That's why every modern tech company from Google to startups uses Git."

git fetch downloads remote changes but doesn't merge — safe to inspect first. git pull = fetch + merge in one step. I use fetch when I want to preview changes before integrating; pull when I trust the changes.

git reset rewrites history by removing commits (use for local-only commits). git revert creates a new commit that undoes a previous commit (safe for pushed commits). I use revert in shared branches to avoid breaking teammates' history.

stash temporarily saves uncommitted changes when I need to switch branches urgently. git stash saves them, git stash pop brings them back. Useful when an emergency bug fix interrupts my work.

Merge preserves both branch histories and creates a merge commit. Rebase rewrites the feature branch's commits on top of main, creating linear history. Rebase = cleaner history but rewrites commits (don't do it on shared branches).

I use the imperative mood ("Add login button" not "Added"), start with a capital letter, keep under 50 characters, and explain what and why, not how. Example: Fix mobile navigation alignment. Some teams use Conventional Commits format: feat:, fix:, docs: prefixes.