Maintenance and data recovery

Git Maintenance and Data Recovery

Git, as a distributed version control system, excels in its powerful data recovery capabilities. Even if code is lost due to accidental operations, historical records can be retrieved through various mechanisms. The key lies in understanding Git's object model and reference system, which form the foundation of data recovery.

Understanding Git's Object Model

A Git repository consists of four core object types:

1. Blob objects: Store file contents
2. Tree objects: Record directory structures and filenames
3. Commit objects: Contain commit messages, author information, and timestamps
4. Tag objects: Label specific commits

Each object has a unique SHA-1 hash as its identifier. For example, to view information about the most recent commit object:

git cat-file -p HEAD

Sample output:

tree 92b8b6ffb019482d5a2e4e5f0c0e0e7e0a9a8b7c
parent 6d8a9f6b0e9c4d2b1a0f8e7d6c5b4a3e2d1f0e
author John Doe <john@example.com> 1625097600 +0800
committer John Doe <john@example.com> 1625097600 +0800

Initial commit

Reference and Log Mechanisms

Git tracks commit history through references (refs):

• HEAD: Current branch or commit
• Branch references (refs/heads/): e.g., master, develop
• Remote references (refs/remotes/): Track remote branches
• Tag references (refs/tags/): Mark important versions

Viewing the reference log is the first step in data recovery:

git reflog
# Or more detailed logs
git log -g

Sample output:

6d8a9f6 HEAD@{0}: commit: Fix login bug
92b8b6f HEAD@{1}: checkout: moving from feature to master

Common Data Recovery Scenarios

Recovering Unstaged Changes

When files in the working directory are accidentally deleted or modified:

# Check file status
git status

# Recover a single file
git checkout -- filename.js

# Recover entire working directory
git checkout -- .

Retrieving Staged but Uncommitted Content

If changes were added to the staging area but not committed:

# Create a temporary branch to save current state
git branch temp-branch

# Or use stash
git stash save "temp changes"

Restoring Deleted Branches

After deleting a branch, its commits still exist in the object database:

# Find the last commit of the deleted branch
git reflog | grep "branch-name"

# Restore branch via commit hash
git branch recovered-branch 6d8a9f6

Advanced Recovery Techniques

Using fsck to Detect Dangling Objects

Git doesn't immediately delete objects but leaves them in a "dangling" state:

git fsck --lost-found

This will find recoverable objects in the .git/lost-found directory.

Direct Recovery via Hash Values

If you know the specific object's hash value:

# Check object type
git cat-file -t 6d8a9f6

# View object content
git cat-file -p 6d8a9f6 > recovered-file.js

Risk Management in Reset Operations

Three reset modes and their differences:

1. soft: Only moves HEAD reference

   git reset --soft HEAD~1
   

2. mixed (default): Resets staging area

   git reset HEAD~1
   

3. hard: Completely discards changes

   git reset --hard HEAD~1
   

Before hard reset, consider creating a backup branch:

git branch backup-branch

Advanced Recovery Cases

Restoring Overwritten Merge Commits

When complex merges are incorrectly reset:

# Find merge commits
git log --merges

# Use ORIG_HEAD reference
git checkout ORIG_HEAD

# Or retrieve from reflog
git reflog | grep "merge"

Repairing Corrupted Repositories

When repository metadata is corrupted:

# Reindex objects
git fsck --full
git prune
git gc

# Recover from remote repository
git fetch origin
git reset --hard origin/master

Preventive Maintenance Measures

Regular Repository Maintenance

# Compress historical objects
git gc --aggressive

# Clean untracked files
git clean -fd

Configuring Automatic Backups

Add backup scripts to .git/hooks/post-commit:

#!/bin/sh
rsync -avz . /backup/location/$(date +%Y%m%d)

Using Tags to Mark Important Nodes

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin --tags

Automated Recovery Script Example

Create a script to restore recent commits:

// restore.js
const { execSync } = require('child_process');

function restoreLastCommit() {
  try {
    const lastCommit = execSync('git rev-parse HEAD').toString().trim();
    const branchName = `backup-${new Date().toISOString()}`;
    
    execSync(`git branch ${branchName} ${lastCommit}`);
    console.log(`Created backup branch: ${branchName}`);
    
    return true;
  } catch (error) {
    console.error('Restore failed:', error.message);
    return false;
  }
}

module.exports = { restoreLastCommit };

Git Maintenance Best Practices

1. Frequent commits: Small commits reduce risk
2. Branch strategy: Develop on feature branches, keep main branch stable
3. Remote backups: Regularly push to multiple remote repositories
4. Hook scripts: Use pre-commit/pre-push for checks
5. Documentation: Maintain CHANGELOG.md for significant changes

Example pre-push hook check:

#!/bin/sh
# .git/hooks/pre-push

remote="$1"
url="$2"

# Prevent direct pushes to main branch
while read local_ref local_sha remote_ref remote_sha
do
  if [ "$remote_ref" = "refs/heads/master" ]; then
    echo "Direct push to master is prohibited"
    exit 1
  fi
done