GitHub Foundations Free Sample Questions

Git is a distributed version control system (DVCS). When a developer clones a repository, they receive a full backup of all data, including the entire commit history, branches, and tags. This allows operations like log viewing and diffing to happen locally without a network connection, unlike centralized systems where history resides primarily on the server.

The standard Git workflow involves two steps: first, staging the changes using git add (which moves files from the working directory to the staging area), and second, committing those staged changes to the local repository history using git commit. Pushing is a separate step to sync with a remote.

A git pull performs a git fetch followed by a git merge. This downloads the new commits from the remote and merges them into the local branch. Once the merge is resolved (and any conflicts fixed), the local history includes the remote work, allowing a standard git push to succeed. git push --force would overwrite remote history, potentially causing data loss for others.

The 'Blame' view (often called 'Annotate' in other tools) in GitHub displays the file content alongside the commit hash, author, and date for the last modification of every single line. This is the primary tool for tracing the origin of specific code changes.

When 2FA is enabled, basic password authentication is disabled for Git over HTTPS. Users must generate and use a Personal Access Token (PAT) with the appropriate scopes (like repo) as their password. Alternatively, they could use SSH keys or the Git Credential Manager.

git rebase main rewrites the project history by creating new commits for each commit in the original branch, placing them after the last commit of the main branch. This creates a linear history, unlike git merge, which creates a special merge commit that ties the two histories together.

The .gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; it prevents new files (like log files, binaries, or .env files) from being accidentally staged and committed.

Forking creates a personal copy of the repository on your GitHub account. This is essential for contributing to open-source projects where you lack permission to push directly to the original (upstream) repository.

Forking is also used to take an existing project and diverge it into a new, separate project (often called a 'hard fork') that you manage independently.