GitHub Basics Interview Q&A

Git is a distributed version control system that runs locally on your computer. It tracks changes to files, allows branching and merging, and maintains a complete history of your project. Git works entirely offline and doesn't require an internet connection.

GitHub is a cloud-based hosting service for Git repositories. It adds collaboration features on top of Git, including pull requests, issue tracking, project management, code review tools, GitHub Actions for CI/CD, and social features. While Git is the engine, GitHub is the platform where teams share code and collaborate.

Interview Tip: Emphasize that you can use Git without GitHub (local repos or other hosts), but GitHub requires Git. Understanding Git fundamentals is essential even when working on GitHub.

A repository (or "repo") is the most basic element of GitHub. It's a storage space where your project lives, containing all files, folders, and the complete revision history of those files. Repositories can be public (anyone can see) or private (only invited collaborators can see).

Each repository can have multiple branches, tags, issues, pull requests, and wiki pages. Repositories can also contain a README file (project documentation), a .gitignore file (specifies intentionally untracked files), and a LICENSE file.

A README file is the first thing people see when they visit your repository. It should explain what your project does, how to install and use it, how to contribute, and any other relevant information. READMEs are written in Markdown (.md) format.

Good READMEs include: project title and description, installation instructions, usage examples, contribution guidelines, license information, and badges showing build status, test coverage, or version. A well-written README makes your project more accessible and professional.

A branch is an independent line of development. Branches allow you to work on features, bug fixes, or experiments without affecting the main codebase. The default branch (usually called "main" or "master") represents the production-ready code.

Benefits of branching include: isolation of work (changes in one branch don't affect others), parallel development (multiple team members can work simultaneously), experimentation (try ideas without risk), and cleaner history (each feature has its own branch). The typical workflow is: create a branch, make commits, open a pull request, merge after review, and delete the branch.

A fork is a complete copy of a repository that lives under your own GitHub account. Forks are independent—changes in your fork don't affect the original repository. Forks are commonly used for open source contribution: you fork a project, make changes, then submit a pull request to propose those changes to the original.

A branch is a lightweight pointer within the same repository. Branches are part of the same repository and share the same commit history. Branches are used for collaboration within a repository you own or have write access to.

Key difference: Forks create a server-side copy under a different account; branches are within the same repository. Use forks when you don't have write access; use branches when you do.

GitHub Flow is a lightweight branching strategy designed for continuous delivery. It has simple rules: the main branch is always deployable. Create descriptive branches off main for features, fixes, or experiments. Open pull requests early to start discussions. Review and merge via PRs after tests pass. Deploy immediately after merging to main.

Unlike Git Flow (which uses multiple long-lived branches like develop, release, hotfix), GitHub Flow keeps things simple with only one main branch. This works well for teams practicing continuous deployment where features are deployed as soon as they're ready. GitHub Flow encourages small, frequent changes—each PR focuses on a single logical change.

A Pull Request is a GitHub feature that lets you propose changes from one branch to another. When you open a PR, you're asking maintainers to "pull" your changes into their branch. PRs are the primary mechanism for code review and collaboration.

The workflow: create a branch, make commits, push the branch to GitHub, open a PR comparing your branch to the target branch (usually main). Team members review the code, leave comments, request changes, and approve. PRs can trigger automated checks (tests, linters, security scans) via GitHub Actions. Once approved and all checks pass, the PR can be merged.

PRs also serve as documentation—they capture the discussion, rationale, and review process for each change.

In Git, a "remote" is a reference to another copy of the repository. By convention, we use specific names:

origin is the default name for your own fork of a repository. When you clone a repository, Git automatically creates a remote called "origin" pointing to the URL you cloned from. This is where you push your changes.

upstream is the conventional name for the original repository that you forked from. You need to add this remote manually: git remote add upstream <original-repo-url>. You pull from upstream to keep your fork synchronized with the original project.

Workflow: git pull upstream main to get latest changes, git push origin main to push to your fork.

To keep a fork synchronized, add the original repository as an upstream remote, then regularly pull changes from it. Steps: add upstream remote (git remote add upstream <url>), fetch latest changes (git fetch upstream), merge into your local branch (git checkout main && git merge upstream/main), and push to your fork (git push origin main).

GitHub also provides a "Fetch upstream" button in the web interface for your fork. This only syncs the default branch. For other branches, use the command line. Keeping your fork in sync is crucial for open source contribution—if your fork diverges too much, pull requests may have difficult merge conflicts.

git fetch downloads new data from the remote repository but does not integrate it into your working files. It updates remote-tracking branches (like origin/main) so you can see what has changed, but your local branches and working directory remain unchanged. This is safe and allows you to inspect changes before merging.

git pull is a combination of git fetch followed by git merge. It downloads new data AND merges it into your current branch immediately. For beginners, git pull is simpler, but many experienced developers prefer to git fetch first, inspect changes, then manually merge to avoid unexpected conflicts.

A remote is a reference to another copy of your Git repository, typically hosted on a server like GitHub. Remotes allow you to synchronize your local work with others. Each remote has a name (like "origin") and a URL.

Common remote commands: git remote -v (list all remotes), git remote add <name> <url> (add a new remote), git remote remove <name> (delete a remote), git remote rename <old> <new> (rename a remote), and git remote set-url <name> <new-url> (change a remote's URL).

You can have multiple remotes. After forking, you have "origin" pointing to your fork and "upstream" pointing to the original. This lets you pull from upstream and push to origin.

git status displays the state of your working directory and staging area. It shows which changes have been staged, which haven't, and which files aren't being tracked by Git. It's one of the most frequently used commands because it gives you a clear picture of what's happening in your repository.

The output shows: changes to be committed (staged), changes not staged for commit (modified but not added), and untracked files (new files not yet added). Run this command often to avoid surprises before committing.

git add stages changes—it tells Git which files you want to include in the next commit. Staging allows you to selectively choose which changes to commit. You can stage specific files (git add file.js) or all changes (git add .).

git commit creates a snapshot of all staged changes, along with a commit message describing what changed. Commits are permanent records in your repository's history. The two-step process (add then commit) gives you fine-grained control over what goes into each commit.

git log displays the commit history of your repository. By default, it shows each commit's hash, author, date, and message in reverse chronological order.

Useful variations: git log --oneline (compact one-line per commit), git log --graph (ASCII graph of branch structure), git log --author="name" (filter by author), git log -p (show patches/diffs), git log --since="2 weeks ago" (date filter), and git log --grep="pattern" (search commit messages).

To undo the last commit while keeping changes in your working directory, use git reset --soft HEAD~1. This removes the commit but leaves your changes staged.

To undo the last commit AND unstage changes (but keep file changes), use git reset HEAD~1 (or git reset --mixed HEAD~1).

To completely discard the last commit and all changes, use git reset --hard HEAD~1 (dangerous—loses all changes).

To change only the commit message, use git commit --amend -m "New message".

GitHub Actions is a CI/CD automation platform built into GitHub. It allows you to create workflows that automatically run when events occur—pushes, pull requests, scheduled times, or manual triggers. Workflows are defined in YAML files stored in .github/workflows/.

Common uses: running tests on every PR, building and deploying applications, linting code, security scanning, publishing packages, and sending notifications. GitHub Actions supports Linux, Windows, and macOS runners, plus self-hosted runners for custom environments. The marketplace offers thousands of pre-built actions.

GitHub Pages is a static site hosting service that takes HTML, CSS, and JavaScript files from a repository and publishes them to a website. It's completely free with no server setup required.

There are three types: user sites (username.github.io), organization sites, and project sites (username.github.io/repository). GitHub Pages supports Jekyll (static site generator) natively, and you can use custom domains with automatic HTTPS via Let's Encrypt.

GitHub Issues are a built-in project management tool for tracking tasks, bugs, features, and discussions. Each issue has a title, description, labels, assignees, milestones, and comments.

Issues can be referenced in commits and pull requests (e.g., "Fixes #42"), which automatically links and closes issues. You can create issue templates to standardize bug reports or feature requests. Issues integrate with GitHub Projects (Kanban boards) for visual workflow management.

Protected branches prevent direct pushes and require pull requests with passing status checks and approvals before merging. Common protection rules include: require pull request before merging, require status checks to pass, require linear history, and restrict who can push.

Protected branches protect critical branches like main from accidental or unreviewed changes. They enforce code review policies, ensure CI passes before merging, and maintain a clean, auditable history. This is essential for team collaboration and production stability.

Dependabot is GitHub's automated dependency management tool. It monitors your project's dependencies for security vulnerabilities and version updates. When a vulnerability is discovered, Dependabot creates an alert and automatically opens a pull request to update the vulnerable package.

You can configure Dependabot to check for version updates daily, weekly, or monthly. It supports many ecosystems: npm, pip, Maven, NuGet, RubyGems, Go modules, and more. Dependabot helps keep your project secure and up to date with minimal manual effort.

A merge conflict occurs when two branches have changed the same lines in a file, and Git cannot automatically determine which change to keep. Conflict markers (<<<<<<<, =======, >>>>>>>) show both versions.

To resolve: edit the file to keep the correct version, remove all conflict markers, stage the file (git add), and complete the merge (git commit). For simple conflicts, use GitHub's web editor. For complex conflicts, resolve locally in your editor or using a merge tool like VS Code's built-in merge editor.

Use git revert <commit-hash> to create a new commit that undoes the changes from a previous commit. This is safe for shared branches because it doesn't rewrite history—it just adds new history. After creating the revert commit, push it normally with git push.

Unlike git reset (which rewrites history and requires force push), revert is the recommended way to undo changes on branches that others may have pulled. You can also revert a range of commits: git revert HEAD~3..HEAD.

Detached HEAD occurs when HEAD points directly to a commit instead of a branch. You enter this state by checking out a commit hash, tag, or remote branch. Git warns you that you're not on any branch.

This is useful for exploring old code or testing experimental changes. However, commits made in detached HEAD are not attached to any branch and can be lost if you switch away. To save work, create a branch: git branch new-branch. To recover lost commits, use git reflog to find the commit hash.

The reflog (reference log) records every movement of your branch pointers—commits, checkouts, merges, rebases, resets. It's a local safety net that allows you to recover lost commits. Git keeps reflog entries for about 90 days.

Use git reflog to: recover after an accidental hard reset, find commits from a deleted branch, undo a rebase that went wrong, or restore work done in detached HEAD. Once you find the commit hash, create a branch at that commit: git branch recover <hash>.

Use interactive rebase: git rebase -i HEAD~N where N is the number of commits to review. In the editor, change "pick" to "squash" (or "s") for the commits you want to combine. Save and close. Git will combine the commits and prompt you for a new commit message.

This is useful for cleaning up a feature branch before merging. Only squash commits that haven't been pushed to a shared branch, as it rewrites history. After squashing, force push if needed (git push --force-with-lease).

A .gitignore file specifies which files and directories Git should ignore and not track. Common ignored items: build artifacts (dist/, build/), dependencies (node_modules/), environment files (.env), IDE settings (.vscode/), logs, and operating system files (.DS_Store).

Using .gitignore prevents committing sensitive information (API keys), reduces repository size, and avoids cluttering the repository with generated files. GitHub provides template .gitignore files for many languages and frameworks.

Tags mark specific commits as important, typically for software releases. Create lightweight tags with git tag v1.0.0 or annotated tags (recommended) with git tag -a v1.0.0 -m "Release message". Annotated tags store metadata (tagger, date, message).

Push tags to remote with git push --tags or git push origin v1.0.0. Tags are often used with GitHub Releases to provide downloadable archives and release notes. To delete a tag: git tag -d v1.0.0 (local) and git push origin --delete v1.0.0 (remote).