Complete Guide to Deleting Non-HEAD Commits in GitLab: Interactive Rebase and Safe Operations

Problem Background and Scenario Analysis

In Git version control systems, developers often need to handle erroneous or sensitive commits in the commit history. When a commit is no longer at the HEAD of a branch, deletion requires special attention to the safety of history rewriting. Consider this typical scenario: assume your commit history is * 1bd2200 (HEAD, master) another commit, * d258546 bad commit, * 0f1efa9 3rd commit, * bd8aa13 2nd commit, * 34c4f95 1st commit, where d258546 is the "bad commit" to be deleted.

Detailed Interactive Rebase Operation

Interactive rebase is the preferred method for deleting non-HEAD commits. Execute the command git rebase -i 34c4f95, and the system opens the default editor with a list of commits:

pick bd8aa13 2nd commit
pick 0f1efa9 3rd commit
pick d258546 bad commit
pick 1bd2200 another commit

# Rebase 34c4f95..1bd2200 onto 34c4f95
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

To delete d258546 bad commit, simply remove the corresponding line and save and exit. Git will reapply the remaining commits, generating a new history: * 34fa994 (HEAD, master) another commit, * 0f1efa9 3rd commit, * bd8aa13 2nd commit, * 34c4f95 1st commit. Note that the hash values of subsequent commits will change, which is normal in history rewriting.

Remote Repository Synchronization and Force Push

If the bad commit has been pushed to the GitLab remote repository, after local history modification, use git push -f <remote> <branch> to force push. For example: git push -f origin master. Force pushing overwrites the remote history, so it is essential to ensure no other collaborators are working on branches based on the old history, as this could cause conflicts with the main branch.

Alternative Approaches: Reset and Revert Operations

Besides interactive rebase, consider other methods:

• Hard Reset: Use git reset --hard CommitId to move HEAD to a specified commit, deleting all subsequent commits. Combine with git push -f to sync remotely, but handle team collaboration impacts with care.
• Commit Revert: Execute git revert <bad commit hash> to create a new commit that undoes the changes of the bad commit. This method does not rewrite history, making it safer, but it leaves a revert record in the history, which may be less "clean."

Sensitive Data Handling and GitLab-Specific Considerations

Referencing auxiliary articles, when a commit contains sensitive information, merely deleting it from history may not suffice, as GitLab's blob view might still access content via SHA1. Similar to GitHub's handling, contacting support may be necessary for complete data removal. Before operating, always assess data sensitivity and employ additional measures if needed to protect information.

Best Practices and Risk Mitigation

Summarizing key practices: test history modification commands on private branches first; communicate force push plans with the team; backup important branches to prevent errors; for sensitive data, consider encryption or specialized cleaning tools. While interactive rebase is powerful, understanding its mechanisms and impacts is foundational to safe usage.