Answer: Git is a free, open-source distributed version control system (DVCS) designed to handle everything from small to very large projects with speed and efficiency. Unlike older centralized systems (like SVN or CVS), every Git clone is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server.

Why it is Used:#

• Speed & Performance: Most operations are local, making them incredibly fast.
• Distributed Architecture: Developers work offline and commit locally. A failure of the central server doesn't halt work or lose history.
• Data Integrity: Git uses SHA-1 hashing to verify the integrity of every file and commit, making history modification virtually impossible without detection.
• Branching & Merging: Highly efficient branching models allow developers to create isolated workspaces for features and merge them seamlessly.

Answer: Version Control is a system that records changes to a file or set of files over time, allowing developers to recall specific versions, track history, revert mistakes, and collaborate concurrently on the same codebase. It is a core pillar of DevOps because it:

• Enables Collaboration: Allows multiple engineers to branch off, develop features, and merge changes via Pull Requests (PRs).
• Acts as the Source of Truth: Houses all infrastructure manifests (IaC) and application source code.
• Powers Automation: Commits and merges act as automatic triggers for CI/CD pipeline builds.
• Facilitates Safe Rollbacks: If a bug is deployed, reverting to a previous stable Git commit restores the system state.

Answer:

• Git:
  • An open-source command-line tool and version control software installed locally on your machine.
  • Manages files, commits history, handles branches, and performs merges locally.
• GitHub:
  • A cloud-based SaaS platform built around the Git tool.
  • Hosts Git repositories online, providing team access controls, graphical interfaces (GUIs), pull requests (PRs), code reviews, project boards, and automation tools (like GitHub Actions).

Answer: When you execute git commit -m "commit message", Git performs several actions behind the scenes:

1. Gather Staged Files: Git looks at the staging area (index) to compile the snapshot.
2. Create tree objects: Creates directory structure records mapping file names to their corresponding file hashes (blobs).
3. Create a commit object: Writes a metadata file containing:
   • The hash of the root tree object.
   • The hash of the parent commit(s) (unless it is the initial commit).
   • Author and Committer names, emails, and timestamp.
   • The commit message.
4. Generate SHA-1 hash: Generates a unique 40-character SHA-1 (or SHA-256) hash identifying this commit.
5. Move HEAD pointer: Updates the pointer of the current active branch (and HEAD) to point to this new commit hash.

Answer: Git is a content-addressable key-value database stored inside the .git/objects directory. All data is compressed and indexed by a 40-character SHA-1 hash. There are four primary types of Git objects:

• Blob (Binary Large Object): Stores only the file contents (no metadata like file name, permissions, or directory paths).
• Tree: Represents a directory. It contains directory listing rows mapping hashes to blobs (files) or other nested trees (subdirectories), along with file names and permissions.
• Commit: Points to a single root tree object representing the repository state at that commit, lists parent commit hashes, and contains metadata (author, message, timestamp).
• Tag: A reference pointing to a specific commit object, containing tag name, creator, and message.

Answer: In Git, a branch is not a duplicate directory copy; it is simply a lightweight, mutable pointer to a specific commit.

How it works:#

• When you create a branch, Git creates a new pointer file inside .git/refs/heads/ containing the 40-character SHA-1 hash of the commit you branched from.
• As you make new commits, the branch pointer moves forward automatically to point to the latest commit.
• This design makes branching and switching branches almost instantaneous, regardless of the size of the repository.

Answer: Both commands integrate changes from one branch into another, but they do it in fundamentally different ways:

• git merge:
  • Combines the histories by executing a three-way merge and creating a new merge commit (if not fast-forward).
  • Pros: Preserves the complete, chronological history of what happened and when. Non-destructive.
  • Cons: Can result in a cluttered history graph with many overlapping merge lines.
• git rebase:
  • Moves the entire base of the feature branch to begin at the tip of the target branch, effectively rewriting history. It plays back commits one-by-one onto the new base.
  • Pros: Results in a perfectly clean, linear history graph without unnecessary merge commits.
  • Cons: Rewrites history. Golden Rule of Rebasing: Never rebase branches that have been pushed to a public/shared repository, as it corrupts collaborators' local histories.

Initial State:
      A---B---C  (main)
           \
            D---E  (feature)
After git merge main into feature:
      A---B---C  (main)
           \   \
            D---E---F  (feature, F is a merge commit)
After git rebase main on feature:
      A---B---C  (main)
               \
                D'---E' (feature, commits D and E are rewritten)

Answer: git cherry-pick <commit-hash> is a command that allows you to select a specific commit from one branch and apply its changes as a new commit onto your current active branch.

Common Use Cases:#

• Hotfixes: Porting a critical bug fix committed on a development branch directly to the production branch without merging the entire development history.
• Undoing Commits: Applying a commit that was accidentally committed to the wrong branch onto the correct branch.

Answer: A squash merge takes all the individual commits from a feature branch, condenses (squashes) them into a single commit, and applies that single commit onto the target branch (e.g., main).

Why it is used:#

• Keeps the destination branch's history clean by hiding internal development iterations, WIP commits, and formatting corrections from the main branch history.
• Note: The source branch's detailed commit history is lost on the destination branch, but is still accessible in the Pull Request history on platforms like GitHub.

Answer: A fast-forward merge occurs when you merge a branch (e.g., feature) into a target branch (e.g., main), and the target branch has no new commits since the feature branch was created.

How it works:#

• Instead of creating a merge commit, Git simply moves the target branch pointer forward to point to the latest commit of the feature branch.
• You can prevent this by running git merge --no-ff <branch>, which forces Git to create a merge commit, preserving the visual branch boundary in the history log.

Answer: These commands are used to undo changes at different stages of the Git lifecycle:

• git reset: Moves the branch pointer and HEAD to a specified commit. It is destructive if history was pushed.
  • --soft: Keeps changes in the Working Directory and Staging Area.
  • --mixed (default): Keeps changes in the Working Directory but clears the Staging Area.
  • --hard: Discards all changes in the Working Directory and Staging Area, matching the target commit exactly.
• git revert: Creates a brand new commit that applies the exact opposite changes of a target commit. It does not rewrite history, making it completely safe for shared/pushed branches.
• git restore: Discards uncommitted changes in the Working Directory or Staging Area (e.g., restoring a modified file to match HEAD).

Answer: Even if a commit is deleted (e.g., via git reset --hard or branch deletion), the commit object remains in the .git/objects database for a period (usually 30 days) before Git's garbage collector (git gc) purges it.

Recovery Workflow:#

1. Run git reflog to view the history of HEAD pointer updates. Find the SHA-1 hash of the commit before the reset/deletion occurred.
2. Inspect the commit content using git show <commit-hash>.
3. Recover the state:
   • Create a branch at that commit: git branch recovery-branch <commit-hash>.
   • Or reset current branch: git reset --hard <commit-hash>.

Answer: git reflog (reference log) is a local tracking mechanism that records every update made to local branch pointers and the HEAD pointer. Unlike git log (which only shows the commit graph of the active branch), git reflog tracks commits, resets, checkouts, rebases, and merges. It acts as an undo history log for your local repository, allowing you to recover lost commits and branches.

Answer: A detached HEAD state occurs when the HEAD pointer points directly to a specific commit hash rather than to a branch pointer.

How it happens:#

• Running git checkout <commit-hash> instead of git checkout <branch-name>.

Implications:#

• You can make commits in this state, but if you switch branches, those commits will not belong to any branch, making them "dangling" and eligible for garbage collection.
• To save your work from a detached HEAD, create a branch immediately: git switch -c new-branch-name.

Answer: A deleted branch is simply a deleted pointer file. The underlying commits still exist.

Recovery Workflow:#

1. Run git reflog and locate the hash of the latest commit on the branch before it was deleted (usually labeled checkout: moving from <branch> to ...).
2. Recreate the branch pointing to that commit: git checkout -b <branch-name> <commit-hash>.

Answer: A merge conflict occurs when Git attempts to merge two branches, and changes in the branches conflict on the same lines of the same files, or a file was modified in one branch and deleted in the other. Git cannot automatically determine which version to keep and halts the merge process to request manual resolution.

Answer: Resolving merge conflicts involves a structured process:

1. Identify Conflicted Files: Git lists conflicted files. Run git status to view files marked both modified.
2. Open Files & Inspect Conflict Markers: Locate the standard Git conflict markers in the source file:

   <<<<<<< HEAD
   Changes on the current active branch (e.g., main)
   =======
   Changes from the branch being merged in (e.g., feature)
   

3. Edit Content: Manually edit the files to combine or select the desired changes, and remove all conflict markers.
4. Stage Files: Stage the resolved files: git add <file-name>.
5. Commit Resolution: Complete the merge operation: git commit -m "merge and resolve conflicts".

Answer: Git Flow is a structured branching model designed for project releases. It uses dedicated branches with specific roles:

• main: Holds the stable production-ready code.
• develop: The primary integration branch for features.
• feature/*: Temporary branches branched from develop for new features; merged back into develop.
• release/*: Branches used to prepare for a new production release, allowing for final bug fixes; merged into both main and develop.
• hotfix/*: Branches created directly from main to address critical production issues; merged back into both main and develop.

Answer: GitHub Flow is a lightweight, agile branching model designed for continuous deployment environments.

Core Workflow:#

1. Branch from main to create a descriptive feature branch (e.g., update-login-ui).
2. Make commits locally and push to GitHub.
3. Open a Pull Request (PR) to request feedback and trigger CI builds.
4. Discuss, review code, and commit revisions.
5. Merge the PR into main once tests pass, automatically triggering deployment to production.

Answer: Trunk-Based Development is a branching strategy where developers commit small, frequent changes to a single branch—the "trunk" (usually main)—multiple times a day.

Key Principles:#

• Avoids long-lived feature branches to eliminate merge pain.
• Feature branches are short-lived (usually less than a day).
• Relies heavily on automated testing (CI) to prevent trunk breakage.
• Uses Feature Flags (toggles) to merge incomplete features into production without exposing them to users.