What is Git, and why is it used?

Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005. It is used to track changes in source code during software development, allowing multiple developers to work on the same project simultaneously without conflicts.

Git is used for several key reasons:

• Version tracking: Maintains a complete history of all changes made to files
• Collaboration: Enables multiple developers to work on the same codebase simultaneously
• Branching and merging: Supports parallel development workflows through lightweight branching
• Distributed nature: Every developer has a complete copy of the project history
• Data integrity: Uses SHA-1 hashing to ensure data corruption is detectable
• Performance: Optimized for speed in common operations like commits, branches, and merges

References:

• Pro Git Book - Chapter 1: Getting Started
• Git Official Documentation

What is HEAD in Git?

HEAD is a special pointer in Git that refers to the current branch reference, which in turn points to the last commit made on that branch. It represents the current state of your working directory and staging area.

Key characteristics of HEAD:

• Current position: Points to the tip of the currently checked-out branch
• Symbolic reference: Usually points to a branch reference (like refs/heads/main), not directly to a commit
• Detached HEAD: When HEAD points directly to a commit instead of a branch, you're in "detached HEAD" state
• Movement: HEAD moves automatically when you make new commits or switch branches

References:

• Git Internals - Git References
• Understanding HEAD in Git

What is the difference between git add and git commit?

git add is used to stage changes from your working directory to the staging area (also called the index). This command prepares files to be included in the next commit but doesn't actually create a commit yet. You can stage specific files, directories, or all changes.

git commit creates a snapshot of the staged changes and permanently stores it in the Git repository history. It takes the files from the staging area and creates a new commit object with a unique SHA hash, commit message, author information, and timestamp.

The workflow is: Working Directory → git add → Staging Area → git commit → Repository

References:

• Pro Git Book - Git Basics
• Atlassian Git Tutorial - Saving Changes

What are the different ways to revert or undo a commit?

git revert (recommended for shared repositories): Creates a new commit that undoes the changes from a previous commit without rewriting history.

git revert <commit-hash>

git reset (use with caution):

• git reset --soft <commit-hash>: Moves HEAD but keeps changes staged
• git reset --mixed <commit-hash>: Moves HEAD and unstages changes (default)
• git reset --hard <commit-hash>: Moves HEAD and discards all changes

git rebase -i (interactive rebase): Allows you to edit, delete, or squash commits in history.

References:

• Atlassian Git Tutorial - Undoing Changes
• Git Documentation - git revert
• Git Documentation - git reset

What is a branch in Git, and why is branching useful?

A branch in Git is a lightweight, movable pointer to a specific commit in the repository's history. It represents an independent line of development that diverges from the main codebase. The default branch is typically called main or master.

Why branching is useful:

• Parallel Development: Multiple developers can work on different features simultaneously without interfering with each other
• Feature Isolation: Each feature or bug fix can be developed in isolation, preventing unstable code from affecting the main branch
• Experimentation: Developers can try new approaches or experimental features without risking the stability of the main codebase
• Release Management: Different versions and releases can be maintained on separate branches
• Code Review: Changes can be reviewed before merging into the main branch through pull/merge requests

References:

• Git Branching - Branches in a Nutshell
• Atlassian Git Branching Tutorial

How do you handle merge conflicts?

Merge conflicts occur when Git cannot automatically resolve differences between branches during a merge. This happens when the same lines of code have been modified differently in both branches.

Steps to handle merge conflicts:

1. Identify conflicts: Git will mark the conflicted files and pause the merge process

# Check status to see conflicted files
git status

2. Open conflicted files: Look for conflict markers in the code

<<<<<<< HEAD
// Changes from current branch
const message = "Hello from main branch";
=======
// Changes from merging branch
const message = "Hello from feature branch";
>>>>>>> feature-branch

3. Resolve conflicts: Edit the file to keep desired changes and remove conflict markers

4. Mark as resolved: Add the resolved files to staging area

git add <resolved-file>

5. Complete the merge: Commit the resolution

git commit

Tools for conflict resolution:

• Built-in Git merge tool: git mergetool
• IDE integrations (VS Code, IntelliJ IDEA, etc.)
• Specialized tools like KDiff3, Beyond Compare, or Meld

Best practices:

• Communicate with team members about overlapping changes
• Keep feature branches up-to-date with main branch
• Make smaller, focused commits
• Use descriptive commit messages

References:

• Git Branching - Basic Merging and Conflicts
• Atlassian Git Merge Conflicts Tutorial
• GitHub Resolving Merge Conflicts

Can you explain the difference between a merge and a rebase?

Merge and rebase are two different approaches to integrating changes from one branch into another:

Merge:

• Creates a new merge commit that combines the histories of both branches
• Preserves the original branch structure and commit history
• Results in a non-linear history with multiple parent commits
• Safer option as it doesn't modify existing commits

Rebase:

• Replays commits from one branch onto another branch
• Creates a linear history by moving the entire branch to start from the tip of the target branch
• Rewrites commit history by creating new commits with the same changes
• Results in a cleaner, linear project history

Example comparison:

# Merge approach
git checkout main
git merge feature-branch

# Rebase approach
git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch  # Fast-forward merge

When to use each:

• Merge: When you want to preserve the context of feature development and branch history
• Rebase: When you want a clean, linear history and are working on private branches

References:

• Git Branching - Rebasing
• Atlassian Git Rebase Tutorial
• Merge vs Rebase - GitHub Blog

What's the difference between git pull and git fetch?

git fetch downloads changes from the remote repository but doesn't automatically merge them into your current branch. It updates your local repository's remote tracking branches without affecting your working directory.

git pull is essentially git fetch followed by git merge. It downloads changes from the remote repository and immediately attempts to merge them into your current branch.

# Fetch only downloads changes
git fetch origin

# Pull downloads and merges changes
git pull origin main

Use git fetch when you want to review changes before merging, and git pull when you want to immediately integrate remote changes.

References:

• Atlassian Git Tutorial - Git Fetch vs Pull
• Git Documentation - git-pull

What is gitignore, and how should it be used?

.gitignore is a file that tells Git which files and directories to ignore when tracking changes. It should be used to:

• Exclude build artifacts: Compiled code, build directories, and generated files
• Ignore IDE-specific files: Editor configurations, cache files, and workspace settings
• Skip dependency directories: node_modules/, vendor/, etc.
• Exclude sensitive files: Configuration files with secrets, private keys, certificates
• Ignore OS-specific files: .DS_Store, Thumbs.db, etc.
• Skip log files: Application logs, debug files, and temporary files

Best practices:

• Create a global .gitignore for personal/OS-specific files
• Use project-specific .gitignore for project-related exclusions
• Add patterns before committing files to avoid accidentally tracking them
• Use git check-ignore -v <file> to debug ignore rules

References:

• Official Git documentation on gitignore
• GitHub's gitignore templates

What are some best practices for commit messages?

Effective commit messages should follow these conventions:

Structure:

<type>(<scope>): <subject>

<body>

<footer>

Best practices:

• Use imperative mood: "Add feature" not "Added feature"
• Keep subject line under 50 characters: Be concise and descriptive
• Capitalize the subject line: Start with a capital letter
• No period at the end: Of the subject line
• Separate subject from body: Use a blank line
• Wrap body at 72 characters: For better readability
• Explain what and why: Not how (code shows how)
• Use conventional commits: Types like feat, fix, docs, style, refactor, test, chore

Example:

feat(auth): add JWT token validation

Implement middleware to validate JWT tokens for protected routes.
This ensures only authenticated users can access sensitive endpoints.

Closes #123

References:

• Conventional Commits specification
• Chris Beams' guide on commit messages

How do you manage sensitive information in Git (e.g., credentials or config files)?

Sensitive information should never be committed to Git repositories. Here are the best practices for managing such data:

• Use environment variables: Store sensitive data in environment variables and reference them in your code
• Configuration files: Use separate configuration files for different environments (dev, staging, prod) and keep them outside the repository
• Secrets management tools: Implement tools like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault
• Git hooks: Set up pre-commit hooks to scan for potential secrets before they're committed
• Template files: Use template configuration files with placeholder values and document the setup process

References:

• OWASP Secrets Management Cheat Sheet
• GitHub's guide on removing sensitive data

What is the purpose of cherry-picking a commit, and how do you do it?

Cherry-picking allows you to apply a specific commit from one branch to another without merging the entire branch. It's useful for:

• Applying bug fixes to multiple branches
• Selectively incorporating features
• Moving commits between branches

How to cherry-pick:

git cherry-pick <commit-hash>

Advanced options:

git cherry-pick -n <commit-hash>  # Don't auto-commit
git cherry-pick -x <commit-hash>  # Add reference to original commit
git cherry-pick <commit1>..<commit3>  # Cherry-pick range

Handling conflicts:

# Resolve conflicts manually, then:
git cherry-pick --continue
# Or abort the cherry-pick:
git cherry-pick --abort

References:

• Git Documentation - Cherry-pick
• Atlassian Git Tutorial - Cherry-pick

Can you explain how to squash multiple commits into one?

Squashing combines multiple commits into a single commit, useful for cleaning up commit history. Here are the main methods:

Method 1: Interactive Rebase

git rebase -i HEAD~3  # Squash last 3 commits

In the editor, change pick to squash (or s) for commits you want to combine:

pick abc1234 First commit
squash def5678 Second commit
squash ghi9012 Third commit

Method 2: Reset and Commit

git reset --soft HEAD~3  # Keep changes staged
git commit -m "Combined commit message"

Method 3: During Merge

git merge --squash feature-branch
git commit -m "Squashed feature implementation"

References:

• Git Documentation - Squashing Commits
• GitHub Guide - Squashing Commits

What is the "Gitflow" workflow, and when should it be used?

Gitflow is a branching model for Git that defines a strict branching structure designed around project releases. It was first published by Vincent Driessen and provides a robust framework for managing larger projects with scheduled releases.

Key branches in Gitflow:

• master/main: Contains production-ready code
• develop: Integration branch for features
• feature branches: For developing new features
• release branches: For preparing new releases
• hotfix branches: For critical fixes to production

When to use Gitflow:

• Large teams with multiple developers
• Projects with scheduled releases
• Applications requiring multiple versions in production
• When you need a formal release process
• Projects where stability is crucial

When NOT to use Gitflow:

• Small teams or solo projects
• Continuous deployment environments
• Projects with frequent releases
• Simple applications without complex release cycles

References:

• A successful Git branching model - Original Gitflow article by Vincent Driessen
• Gitflow Workflow - Atlassian Git Tutorial