How to Rollback a Git Push and Revert to a Previous Commit: A Guide

When working with Git, it’s common to accidentally push changes to the remote repository that you might want to undo. Fortunately, Git provides several methods to roll back a git push and revert to a previous commit. In this guide, we’ll walk through the steps to achieve this, ensuring that your repository stays clean and up to date.

The first step in rolling back is identifying the commit you want to revert to. You can do this by using the git log command. This command displays a list of previous commits, allowing you to locate the specific commit hash (a unique identifier) that corresponds to the version you want to revert to.

git log

Look through the log and copy the hash of the desired commit (e.g., abc1234).

Once you have the commit hash, you can reset your local repository to that commit. The git reset command offers different options, but to completely revert your repository and discard any changes, you’ll want to use the --hard flag. This ensures that the index and working directory are updated to match the target commit.

git reset --hard abc1234

This command will reset your repository to the state of the commit abc1234, including both tracked and untracked changes.

Since you’ve already pushed the unwanted commits to the remote repository, a regular git push won’t work. To synchronize your local repository with the remote one, you need to perform a forced push. This action rewrites the history in the remote repository to match your local one.

git push origin HEAD --force

The --force flag tells Git to overwrite the remote history with your local changes. Be careful when using this option, especially if other collaborators are working on the same branch, as it can remove commits they might depend on.

If you want to keep the Git history intact but undo the changes introduced by a specific commit, consider using git revert. This command creates a new commit that undoes the changes from a previous commit, without rewriting the commit history. Here’s how you can use it:

git revert abc1234

This command will create a new commit that effectively reverses the changes made in abc1234. This method is safer when working in a collaborative environment, as it avoids rewriting the history and minimizes the risk of conflicts.

Key Considerations

  • Use --force with caution: A forced push can overwrite the remote history, which can impact other developers working on the same branch. Always communicate with your team before using this option.

  • Consider git revert: When working in a shared repository, using git revert instead of git reset might be the safer choice, as it doesn’t rewrite the commit history.

  • Backup important work: Before making any destructive changes, consider creating a backup branch with git branch backup-branch-name to ensure you have a safety net.

Rolling back a git push and reverting to a previous commit can be achieved through various methods, depending on the complexity of the situation and the collaboration model in your team. Using git reset with a forced push is effective for quick fixes, while git revert is ideal for keeping the commit history clean and intact.

Whether you’re a beginner or an advanced Git user, mastering these rollback techniques is essential for effective version control in your projects.

Development checklist

The idea behind the following checklist is to ensures that all development tasks are properly documented, reviewed, and tested, maintaining a high standard of quality and clarity throughout the project

Guidelines for Development

  • Version Control:
    • Ensure that all changes are pushed to the appropriate branch following the branching strategy.
    • Commit changes regularly and use descriptive commit messages.
    • if it’s a UI change, or a new script, then update release page with the new ui branch to deploy or the script to execute for each env
  • API Integration Documentation in Confluence:
    • Provide a detailed description of any web service integration or Kafka events (see Mandatory Documentation section).
    • Include examples of request payloads and response payloads (see Mandatory Documentation section).
    • Document any callback responses, if applicable (see Mandatory Documentation section).
    • Provide an example of events sent or received, specifying their structure and content (see Mandatory Documentation section).

Code Review

  • Submit Code for Review:
    • Ensure that all implemented features and fixes are submitted for code review through the project’s code review tool.
  • Review Checklist:
    • Check for code efficiency, performance, and readability.
    • Ensure that the code is secure and free of vulnerabilities.
    • Confirm that appropriate test coverage is included (unit tests, integration tests, etc.), and not waiting for testers bugs 🙂
    • Validate that all required documentation has been created or updated in Confluence.
  • Feedback Implementation:
    • Address all feedback received during the code review.
    • Make necessary changes and update the code accordingly.
    • Resubmit the code for further review if required.

Testing and Validation

  • Unit Testing:
    • Create unit tests for all new functions or classes implemented.
    • Ensure that all unit tests pass before marking the task as complete.
  • Integration Testing:
    • Develop integration tests for any new integrations (APIs, services, Kafka events).
    • Confirm that the integration works as expected in the testing environments.
  • End-to-End Testing:
    • Execute end-to-end tests to validate the complete workflow and user interactions.
    • Ensure that all tests pass without errors or issues.

Mandatory Documentation in Confluence

  • API/Web Service Integration:
    • Include a detailed example of a request (JSON or XML format) and the corresponding response.
    • Provide an example of the callback response, if applicable.
    • Document the structure and content of any Kafka events sent or received, including headers and payload.
  • Diagrams:
    • Sequence Diagram: Create at least one sequence diagram to illustrate the interaction flow between different components or services for each user story.
    • Architectural Diagram: Develop an architectural diagram to show the system’s structure, highlighting how the new features or integrations fit into the existing architecture.
Checklist for Clear Task Definition

The task has to be ready to be started only when all the conditions below have been verified.
This in order to oblige the developer to understand what he/she needs to implement.
Many times developers start working on tasks without knowing what is the context and why what they do is needed.

  1. Task Description
    • Does the task have a clear and concise description that explains its purpose and expected outcome?
    • Are all necessary details provided to understand the task’s context (e.g., links to documentation, technical specifications, etc.)?
  2. Objectives and Expected Outcomes
    • Are the task’s objectives specifically and measurably defined?
    • Does the task have clear acceptance criteria that define when it can be considered “completed”?
  3. Priority and Dependencies
    • Is the task’s priority clearly indicated (e.g., high, medium, low)?
    • Are the task’s dependencies listed (i.e., other tasks or requirements that must be completed first)?
  4. Assignment and Responsibility
    • Is the task owner aware of their assignment and has accepted the task?
  5. Deadline and Timing
    • Does the task have a defined deadline or timeframe for completion?
    • Has the deadline been agreed upon with the task owner?
  6. Resources and Support
    • Are all necessary resources (documents, access, tools, etc.) listed to complete the task?
    • Has someone been identified to provide support or clarification if needed?
  7. Fixed Version Number
    • Has the fixed version number been specified in which the task will be resolved or implemented?
  8. Risks and Mitigations
    • Have potential risks or obstacles been identified that could prevent task completion?
    • Are there mitigation strategies in place to handle potential problems?