How to Master Advanced Git Techniques

Advanced Git Techniques

Version control has evolved from a simple necessity into a sophisticated craft that separates competent developers from exceptional ones. The difference between someone who merely uses Git and someone who truly masters it can mean the difference between hours of frustration and seamless collaboration across distributed teams. Advanced Git techniques aren't just about knowing more commands—they're about understanding the underlying architecture, anticipating problems before they occur, and maintaining a clean, comprehensible project history that serves as documentation for your entire development journey.

Beyond the basic commit-push-pull workflow lies a rich ecosystem of powerful capabilities that can transform how you approach software development. Git mastery encompasses everything from surgical precision in rewriting history to sophisticated branching strategies that accommodate complex release cycles. These techniques provide developers with the confidence to experiment boldly, the tools to collaborate effectively, and the skills to recover from seemingly catastrophic mistakes.

This comprehensive guide will take you through the advanced territories of Git, exploring interactive rebasing, cherry-picking strategies, advanced merging techniques, submodule management, and workflow optimization. You'll discover how to leverage Git hooks for automation, master the reflog for disaster recovery, understand the internal object model, and implement branching strategies that scale with your team. Whether you're managing a small open-source project or coordinating development across multiple enterprise teams, these techniques will elevate your version control proficiency to professional levels.

Understanding Git's Internal Architecture

Before diving into advanced techniques, understanding how Git stores and manages data fundamentally changes how you approach version control. Git isn't just a version control system—it's a content-addressable filesystem with a version control interface built on top. Every object in Git is stored as a blob, tree, commit, or tag, each identified by a SHA-1 hash that serves as both identifier and integrity check.

The object database forms the foundation of everything Git does. When you commit changes, Git doesn't store differences between versions; instead, it creates snapshots of your entire project at that moment. This snapshot model, combined with Git's clever use of compression and object sharing, makes operations incredibly fast while maintaining complete history. Understanding this architecture helps you grasp why certain operations are instantaneous while others require more consideration.

"The moment you understand that Git is fundamentally a directed acyclic graph of commits, everything else starts making perfect sense."

The working directory, staging area (index), and repository represent three distinct states in Git's model. The staging area serves as a crucial intermediary, allowing you to craft exactly what goes into each commit. This three-stage architecture enables powerful workflows where you can selectively stage portions of files, review changes before committing, and maintain atomic, logical commits that tell a clear story of your development process.

The Power of Git References

References in Git are simply pointers to commits, but they enable the entire branching and tagging system that makes Git so flexible. Branches are nothing more than movable references to commits, which explains why creating and switching branches is so lightweight. Tags, on the other hand, are fixed references, typically used to mark specific points in history like release versions.

HEAD is perhaps the most important reference—it points to the current branch reference (or directly to a commit in detached HEAD state). Understanding HEAD's behavior is essential for navigating Git's more advanced features. When you commit, HEAD moves forward; when you checkout, HEAD points to a different reference. This simple mechanism underlies much of Git's power and flexibility.

Interactive Rebasing for History Refinement

Interactive rebase stands as one of Git's most powerful features for maintaining a clean, comprehensible project history. Unlike regular rebasing, which simply replays commits onto a new base, interactive rebasing gives you complete control over how commits are applied, combined, edited, or removed. This capability transforms messy development history into a clear narrative that future developers (including yourself) can easily understand.

The interactive rebase interface presents you with a list of commits and a set of commands: pick, reword, edit, squash, fixup, exec, break, drop, and label. Each command serves a specific purpose in reshaping history. Squashing combines multiple commits into one, perfect for consolidating related changes. Reword allows you to improve commit messages without changing content. Edit lets you pause the rebase to modify a commit's contents entirely.

"Clean commit history isn't vanity—it's a form of documentation that makes debugging, code review, and understanding project evolution infinitely easier."

When approaching an interactive rebase, strategy matters. Start by identifying logical groupings in your commits. Experimental commits, debugging commits, and work-in-progress commits should typically be squashed into meaningful units. Each final commit should represent a single logical change that could theoretically be reverted independently without breaking the codebase. This atomic commit philosophy makes bisecting bugs, cherry-picking features, and reviewing changes dramatically more manageable.

Practical Interactive Rebase Workflows

A common workflow involves creating many small commits during development, then using interactive rebase before pushing to clean up the history. This approach gives you the safety of frequent commits during development while maintaining a professional history in the shared repository. You might have twenty commits locally that represent your actual working process, but these get refined into three or four well-crafted commits that tell the story of what changed and why.

• 🔧 Squashing related commits: Combine multiple commits that address the same feature or bug into a single, comprehensive commit with a clear message
• ✏️ Rewording unclear messages: Improve commit messages written hastily during development to provide better context and explanation
• 🔄 Reordering commits: Arrange commits in a logical sequence that makes the development story clearer and more coherent
• ✂️ Splitting large commits: Break down commits that changed too many unrelated things into focused, atomic commits
• 🗑️ Dropping unnecessary commits: Remove commits that added temporary debugging code, experimental features that were abandoned, or changes that were later reverted

Advanced Rebase Techniques

The autosquash feature streamlines the interactive rebase workflow significantly. By creating commits with messages prefixed with "fixup!" or "squash!" followed by the target commit message, Git can automatically arrange and mark commits for squashing during an interactive rebase with the --autosquash flag. This technique allows you to maintain a clean workflow where you can quickly create fixup commits during development, knowing they'll be automatically consolidated later.

Rebase conflicts require careful handling. When a conflict occurs during rebase, Git pauses and allows you to resolve it. Unlike merge conflicts, rebase conflicts happen commit-by-commit, which can mean resolving similar conflicts multiple times. Understanding the rerere (reuse recorded resolution) feature can save enormous time by automatically applying previously recorded conflict resolutions to similar conflicts encountered during the rebase process.

Cherry-Picking Strategies and Selective Application

Cherry-picking allows you to apply specific commits from one branch to another without merging entire branches. This surgical precision proves invaluable when you need a specific bug fix from a development branch in production, or when you want to selectively apply features without bringing along unrelated changes. However, cherry-picking creates new commits with different hashes, which can complicate history if not used thoughtfully.

The primary use case for cherry-picking involves applying critical fixes across multiple branches. Imagine discovering a security vulnerability that affects several release branches. Rather than manually applying the same fix multiple times, you can create the fix once and cherry-pick it to each affected branch. This approach ensures consistency while maintaining independent branch histories.

"Cherry-picking is like precision surgery on your codebase—powerful when used appropriately, but capable of creating complications if applied carelessly."

When cherry-picking multiple commits, order matters. Git applies commits in the sequence you specify, and conflicts may arise if commits depend on changes introduced by other commits. The -x flag adds a reference to the original commit in the cherry-picked commit message, creating traceability between the original and copied commits. This documentation proves crucial when tracking down where changes originated.

Cherry-Pick Conflict Resolution

Conflicts during cherry-picking require the same careful resolution as any other conflict, but with additional context considerations. You're applying a change that was written in a different context, so the conflict might indicate that the change isn't appropriate for the target branch without modification. Sometimes the right solution is to abort the cherry-pick and create a branch-specific implementation instead.

The --continue, --abort, and --skip flags give you complete control over the cherry-pick process. After resolving conflicts, --continue proceeds with the cherry-pick. If you determine the cherry-pick was a mistake, --abort returns to the pre-cherry-pick state. The --skip flag allows you to skip a particular commit in a series of cherry-picks, useful when one commit in a range isn't applicable to the target branch.

Advanced Merging Techniques and Strategies

Merging represents the fundamental operation for integrating divergent work, but Git offers multiple merge strategies, each optimized for different scenarios. The default recursive strategy handles most cases well, but understanding when to use ours, theirs, octopus, or subtree strategies can prevent conflicts and maintain cleaner history. Strategy selection impacts not just the merge result but also how future merges will behave.

The recursive strategy, Git's default for two-branch merges, attempts to automatically resolve conflicts by finding the best common ancestor and performing a three-way merge. When conflicts occur, it leaves conflict markers in the files for manual resolution. However, the -X option allows you to specify strategy options like "ours" or "theirs" to automatically prefer one side's changes when conflicts occur, or "patience" for improved diff algorithm behavior.

Fast-Forward vs. No-Fast-Forward Merges

Fast-forward merges occur when the target branch hasn't diverged from the source branch—Git simply moves the branch pointer forward. While this creates the cleanest linear history, it erases evidence that work happened on a separate branch. The --no-ff flag forces creation of a merge commit even when fast-forward is possible, preserving the branch structure in history. This preservation can be valuable for understanding when features were developed independently.

Deciding between fast-forward and no-fast-forward merges depends on your team's workflow and history preferences. Feature branch workflows often benefit from --no-ff to maintain clear feature boundaries in history. Hotfix branches might use fast-forward to keep history linear. Some teams configure Git to always use --no-ff for certain branches, ensuring consistent history patterns across the project.

Merge Conflict Resolution Strategies

Effective conflict resolution goes beyond simply choosing between conflicting changes. Understanding the context of both changes—what each was trying to accomplish—enables you to create resolutions that incorporate the intent of both modifications. The git show :1:filename, :2:filename, and :3:filename syntax lets you examine the common ancestor, current branch, and merging branch versions of conflicted files, providing full context for resolution decisions.

"The best merge conflict resolution isn't about choosing sides—it's about understanding what both sides were trying to achieve and creating a solution that honors both intentions."

Merge tools can significantly improve the conflict resolution experience. Tools like vimdiff, meld, or kdiff3 provide three-way diff views that clearly show the base version, your changes, and their changes simultaneously. Configuring Git to use your preferred merge tool streamlines the resolution process and reduces errors. Some developers prefer text-based tools for their speed and integration with existing workflows, while others favor graphical tools for their visual clarity.

Submodule and Subtree Management

Managing dependencies and incorporating external repositories into your project presents unique challenges that Git addresses through submodules and subtrees. Submodules allow you to keep a Git repository as a subdirectory of another Git repository, maintaining separate histories while linking specific commits. Subtrees offer an alternative approach that integrates external repositories more seamlessly but with different trade-offs in terms of history and updates.

Submodules provide clean separation between projects. Each submodule maintains its own repository, branches, and history, while the parent repository simply tracks which commit of the submodule should be checked out. This separation prevents accidental modifications to dependencies and makes it clear which version of each dependency is being used. However, submodules require explicit updating and can complicate workflows, especially for team members unfamiliar with submodule operations.

Working with Submodules

Adding a submodule creates a .gitmodules file that tracks the submodule's URL and path, plus a special entry in the parent repository that records the specific commit the submodule should use. Cloning a repository with submodules requires additional steps—either using --recurse-submodules during clone or running git submodule init and git submodule update afterward. This extra complexity can trip up new team members, making clear documentation essential.

• ⚙️ Initializing submodules: After cloning a repository with submodules, you must explicitly initialize and update them to populate the submodule directories
• 🔄 Updating submodules: Pulling changes in the parent repository doesn't automatically update submodules—you must explicitly update them to pull in new commits
• 📌 Committing submodule changes: When you update a submodule to a new commit, you must commit this change in the parent repository to record the new submodule state
• 🌿 Branching with submodules: Submodules don't automatically follow parent repository branches, requiring careful coordination when working across branches
• 🔗 Managing submodule URLs: Submodule URLs can be updated when repositories move, but this requires coordination across the team to avoid broken references

Subtree Alternative Approach

Git subtrees offer a different approach to incorporating external repositories. Instead of maintaining separate repositories, subtree merges integrate the external repository's history directly into your project's history. This integration makes subtrees simpler for team members—they don't need to know they're working with an external dependency—but it complicates extracting updates or contributing changes back to the original repository.

The subtree merge strategy excels when you want to vendor dependencies directly into your repository or when you're forking an external project and don't expect to regularly synchronize with the upstream. Updates from the external repository are pulled as regular commits, and the entire history remains accessible within your project. This accessibility can be valuable for debugging but also increases repository size over time.

"Choose submodules when you need clean separation and independent versioning; choose subtrees when you want seamless integration and simplified workflows for your team."

Git Hooks for Workflow Automation

Hooks provide powerful automation capabilities by executing custom scripts at specific points in Git's workflow. Client-side hooks run on operations like committing and merging, while server-side hooks execute during network operations like receiving pushed commits. These hooks enable enforcement of coding standards, automated testing, commit message validation, and integration with external systems—all without requiring developers to remember manual steps.

Client-side hooks live in the .git/hooks directory of each repository. The pre-commit hook runs before a commit is finalized, perfect for running linters, formatters, or quick tests. The commit-msg hook validates commit messages against your team's conventions. The pre-push hook can run comprehensive test suites before allowing pushes to remote repositories. Each hook is simply a script that returns zero for success or non-zero to abort the operation.

Practical Hook Implementations

A pre-commit hook might run your code formatter to ensure consistent style across the codebase, then execute fast unit tests to catch obvious breakage before it's committed. This automation prevents the common problem of forgetting to run formatters and catching formatting issues during code review. The hook can be configured to automatically fix issues when possible or simply reject the commit with helpful error messages when manual intervention is required.

Commit message hooks enforce consistency in commit messages, which proves invaluable for automated changelog generation and project management integration. A commit-msg hook might verify that messages follow conventional commit format, reference valid ticket numbers, or meet minimum length requirements. These validations prevent the accumulation of unhelpful commit messages like "fix" or "wip" in the shared repository history.

Server-Side Hook Applications

Server-side hooks enable repository-wide policy enforcement that can't be bypassed by skipping client-side hooks. The pre-receive hook examines all commits being pushed and can reject the entire push if any commit violates policies. This capability enables enforcement of branch protection rules, required code review approvals, or prohibition of force pushes to protected branches. The post-receive hook triggers after successful pushes, perfect for deployment automation or notification systems.

Integration with continuous integration systems often happens through post-receive hooks. When commits are pushed to specific branches, the hook can trigger CI builds, run comprehensive test suites, or deploy to staging environments. This integration creates a seamless flow from local development through testing to deployment, all orchestrated automatically based on Git operations.

The Reflog: Your Safety Net for Recovery

The reflog (reference log) records every change to branch tips and HEAD, creating a complete audit trail of your repository navigation and modifications. This record proves invaluable for recovering from mistakes—whether you accidentally reset to the wrong commit, deleted a branch, or rebased away important work. The reflog makes Git remarkably forgiving, as virtually any operation can be undone if you know how to navigate the reflog.

Every entry in the reflog includes a timestamp, the operation that caused the change, and the resulting commit hash. This information allows you to see exactly what happened to your repository over time. The reflog is local to your repository—it doesn't get pushed to remotes—and entries expire after a configurable period (default 90 days for reachable commits, 30 days for unreachable ones). This expiration prevents the reflog from growing indefinitely while maintaining recent history for recovery purposes.

"The reflog is Git's time machine—it remembers where you've been even when you think you've lost your way."

Recovery Scenarios Using Reflog

Recovering from an accidental hard reset demonstrates the reflog's power. After running git reset --hard and realizing you've lost important commits, the reflog shows all previous HEAD positions. Finding the commit you want to return to is as simple as examining reflog entries and resetting to the appropriate hash. The commits weren't actually deleted—they were just no longer reachable from any branch—and the reflog provides the path back to them.

Deleted branches can be recovered similarly. When you delete a branch, the commits don't disappear immediately—they become unreachable. The reflog for that branch (accessed via git reflog show branchname) shows where the branch pointed before deletion. Creating a new branch at that commit effectively restores the deleted branch. This recovery capability removes much of the fear around deleting branches, as deletion is rarely permanent within the reflog retention window.

Advanced Reflog Navigation

Reflog entries can be referenced using special syntax: HEAD@{n} refers to the nth previous position of HEAD, while HEAD@{time} references where HEAD pointed at a specific time. This syntax enables powerful recovery commands like git reset --hard HEAD@{5} to return to the state five moves ago, or git diff HEAD@{yesterday} HEAD to see all changes made since yesterday. Time-based references prove particularly useful when you remember approximately when something happened but not the exact commit.

The reflog isn't just for recovery—it's also valuable for understanding repository history and debugging complex situations. When collaborating with team members and trying to understand how the repository reached its current state, the reflog provides a chronological view of operations that complements the commit history. This dual perspective helps piece together what happened, especially when multiple people are working on the same branches.

Advanced Branching Strategies and Workflows

Branching strategies provide the framework for how teams organize development, manage releases, and coordinate work across multiple developers. The right strategy balances flexibility for development with stability for production, enables parallel work on multiple features, and provides clear paths for hotfixes and releases. Popular strategies include Git Flow, GitHub Flow, GitLab Flow, and trunk-based development, each optimized for different team sizes, release cycles, and project types.

Git Flow, one of the most comprehensive strategies, defines specific branch types with clear purposes: master for production releases, develop for integration, feature branches for new work, release branches for preparing releases, and hotfix branches for production fixes. This structure provides clear guidelines for where work happens and how it flows through the system. However, the complexity can be overkill for smaller teams or projects with continuous deployment.

GitHub Flow Simplicity

GitHub Flow simplifies the branching model dramatically: main is always deployable, all work happens on feature branches, and pull requests facilitate review and integration. This streamlined approach works exceptionally well for web applications with continuous deployment, where every merge to main triggers automatic deployment. The simplicity reduces cognitive overhead and makes the workflow accessible to developers of all experience levels.

The pull request (or merge request) serves as the central coordination point in GitHub Flow. Developers create feature branches, make their changes, then open pull requests to propose merging back to main. The pull request becomes a forum for discussion, code review, automated testing, and approval before integration. This process ensures code quality while maintaining rapid iteration, as features can move from development to production quickly once approved.

Trunk-Based Development

Trunk-based development takes simplicity further: developers work on short-lived branches (or directly on trunk) and integrate frequently—often multiple times per day. This approach minimizes merge conflicts by reducing the time branches diverge and encourages small, incremental changes over large, long-running feature branches. Feature flags enable deploying incomplete features to production without exposing them to users, allowing deployment and release to be decoupled.

The success of trunk-based development depends heavily on automated testing and continuous integration. With developers integrating frequently, comprehensive automated tests must catch regressions quickly. The CI system becomes the gatekeeper, running tests on every commit and preventing integration of broken code. This investment in automation pays dividends in reduced merge conflicts, faster feedback cycles, and increased confidence in the codebase.

Optimizing Git Performance and Repository Maintenance

As repositories grow, performance can degrade without proper maintenance. Git provides several tools for optimization: garbage collection, repacking, pruning, and shallow clones. Understanding when and how to use these tools keeps repositories fast and storage-efficient. Regular maintenance prevents common problems like slow operations, bloated repository sizes, and excessive disk usage.

Garbage collection consolidates loose objects into packfiles, removes unreachable objects, and optimizes storage. Git runs garbage collection automatically during certain operations, but manual execution with git gc can be beneficial for repositories with heavy activity. The --aggressive flag performs more thorough optimization at the cost of longer processing time, useful for repositories that have accumulated significant cruft over time.

Large File Management

Binary files and large assets present special challenges in Git repositories. Because Git stores complete snapshots, large files that change frequently can bloat repository size dramatically. Git LFS (Large File Storage) addresses this by storing large files externally while keeping lightweight pointers in the repository. This separation keeps the repository fast while still providing version control for large assets.

Implementing Git LFS involves installing the extension, initializing it in your repository, and configuring which file types should be managed by LFS. Once configured, Git LFS operates transparently—developers work with files normally, and Git LFS handles the storage and retrieval behind the scenes. This transparency makes LFS adoption relatively painless, though it does require server support and introduces external dependencies.

Shallow Clones and Sparse Checkouts

Shallow clones download only recent commit history rather than the entire repository history, dramatically reducing clone time and disk usage for large repositories. The --depth flag specifies how many commits to retrieve. While shallow clones work well for CI systems or situations where full history isn't needed, they limit certain operations like pushing or performing some types of merges. Converting a shallow clone to a full clone is possible but requires downloading the complete history.

Sparse checkouts allow working with only a subset of repository files, useful for monorepos or repositories with many components where developers typically work on only a few. Configuring sparse checkout involves specifying which paths to include, and Git only populates those paths in the working directory. This feature can dramatically reduce disk usage and improve performance when working with massive repositories.

Advanced Diff and Log Techniques

Git's diff and log commands offer far more power than their basic usage suggests. Advanced options enable precise history analysis, tracking code movement across files, identifying when bugs were introduced, and understanding code evolution. Mastering these tools transforms Git from a version control system into a powerful code archaeology platform that helps you understand not just what changed, but why and when.

The git log command accepts numerous flags for filtering and formatting output. --grep searches commit messages, --author filters by author, --since and --until bound by time, and -S searches for commits that changed the number of occurrences of a string. Combining these filters enables powerful queries like finding all commits by a specific author that mention a particular ticket number within the last month. These queries prove invaluable during debugging or understanding feature evolution.

Blame and Annotate for Code Attribution

Git blame shows which commit last modified each line of a file, providing context for why code exists in its current form. While the name suggests finding culprits, blame is actually about understanding context—seeing the commit message, author, and date for each line helps you understand the reasoning behind implementation decisions. The -L flag limits blame to specific line ranges, focusing analysis on relevant sections.

"Git blame isn't about assigning fault—it's about understanding the story behind every line of code, the decisions that led to current implementations, and the context that makes changes make sense."

Following code across renames and moves requires special flags. Git's default diff behavior doesn't detect when code moves between files, but the -M flag enables move detection, showing when code was relocated rather than deleted and recreated. Similarly, -C detects copies, identifying when code was duplicated across files. These options reveal the true nature of changes rather than showing superficial deletions and additions.

Bisect for Efficient Debugging

Git bisect performs binary search through commit history to identify which commit introduced a bug. You mark a known good commit and a known bad commit, and Git checks out commits halfway between them. After testing each commit and marking it good or bad, Git narrows the range until it identifies the first bad commit. This automated binary search is dramatically faster than manually checking commits, especially in repositories with extensive history.

Bisect can be automated with a test script. The git bisect run command executes a script that returns zero for good commits and non-zero for bad commits, automatically running the entire bisection process. This automation is particularly powerful for regressions caught by automated tests—you can identify the offending commit without any manual testing, even across hundreds or thousands of commits.

Security and Signing in Git

Security concerns in Git encompass commit signing, tag verification, and protecting against repository tampering. GPG signing provides cryptographic verification that commits and tags came from specific individuals, preventing impersonation and ensuring integrity. While not necessary for all projects, signing becomes increasingly important for open-source projects, security-sensitive applications, and compliance requirements.

Setting up commit signing requires generating a GPG key, configuring Git to use it, and uploading your public key to hosting platforms like GitHub or GitLab. Once configured, the -S flag signs commits, and signed commits display verification status in Git log and on hosting platforms. This verification provides assurance that commits came from who they claim to come from and haven't been tampered with since signing.

Verifying Repository Integrity

Git's content-addressable storage provides inherent integrity checking—each object's hash serves as both identifier and checksum. The git fsck command verifies repository integrity, checking for corruption, dangling objects, and broken references. Running fsck periodically ensures your repository remains healthy and can detect storage-level problems before they cause data loss.

Protecting sensitive data in repositories requires vigilance. Once committed, data persists in history even if removed in later commits. Tools like git-filter-repo enable rewriting history to completely remove sensitive data, but this rewriting changes commit hashes and requires coordinating with all repository users. Prevention through .gitignore configuration and pre-commit hooks that scan for patterns like API keys provides better security than attempting to remove data after the fact.

How do I recover a deleted branch in Git?

Use the reflog to find the commit where the branch pointed before deletion, then create a new branch at that commit using git branch branch-name commit-hash. The reflog maintains a history of all reference changes, making branch recovery straightforward as long as the deletion occurred within the reflog retention period.

What's the difference between git reset, git revert, and git checkout?

Reset moves branch pointers and optionally modifies the staging area and working directory, rewriting history. Revert creates new commits that undo previous commits, preserving history. Checkout switches branches or restores files without moving branch pointers. Reset and checkout are dangerous for shared branches, while revert is safe for collaborative work.

When should I use rebase instead of merge?

Use rebase for cleaning up local commits before pushing, maintaining linear history on feature branches, or updating feature branches with latest changes from main. Use merge for integrating completed features, preserving collaboration history, or when working on shared branches where rewriting history would disrupt other developers.

How can I split a large commit into smaller ones?

Use interactive rebase to mark the commit for editing, then reset to the previous commit while keeping changes in the working directory. Stage and commit changes in logical groups, creating multiple focused commits from the original large commit. This technique helps maintain atomic commits that are easier to review and revert if necessary.

What's the best way to handle merge conflicts?

Understand both sides of the conflict by examining the base version, your changes, and their changes using merge tools or Git's show command. Resolve conflicts by combining both intentions rather than simply choosing one side. Test thoroughly after resolution to ensure the merged code works correctly, as conflicts often indicate areas where integration requires careful attention.

How do I remove sensitive data from Git history?

Use git-filter-repo to rewrite history, removing the sensitive data from all commits. This process changes commit hashes, requiring coordination with all repository users who must re-clone or carefully rebase their work. After rewriting, force-push to remote repositories and consider rotating any exposed credentials, as data may persist in clones or backups.