AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Git undo pushed commit2/8/2024 ![]() Most of the discussion on this page touched on deeper topics that are more thoroughly explained on pages specific to the relevant Git commands. It's important to remember that there is more than one way to 'undo' in a Git project. We covered many high-level strategies for undoing things in Git. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. A revert is safer than a reset because it will not remove any commits from a shared history. The preferred method of undoing shared history is git revert. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. This safely isolates the removal of commits from other branches that may be in use by other developers. A reset should be used when undoing changes to a private branch. Git reset should generally be considered a 'local' undo method. When working on a team with remote repositories, extra consideration needs to be made when undoing changes. For more information and examples review our in-depth git checkout discussion. Let's look at some other 'undo' strategies. Unfortunately, if you need the previous branch, maybe it was your main branch, this undo strategy is not appropriate. At this point, we can continue work on this new branch in which the 872fa7e commit no longer exists and consider it 'undone'. The repo is now on a new history timeline in which the 872fa7e commit no longer exists. This will create a new branch named new_branch_without_crazy_commit and switch to that state. To prevent orphaned commits from being garbage collected, we need to ensure we are on a branch.įrom the detached HEAD state, we can execute git checkout -b new_branch_without_crazy_commit. The garbage collector runs on a configured interval and permanently destroys orphaned commits. Orphaned commits are up for deletion by Git's garbage collector. In a detached state, any new commits you make will be orphaned when you change branches back to an established branch. This means you are no longer working on any branch. Checking out a specific commit will put the repo in a "detached HEAD" state. Using the git checkout command we can checkout the previous commit, a1e8fb5, putting the repository in a state before the crazy commit happened. This is called a “detached HEAD” state, and it can be visualized as the following: During the normal course of development, the HEAD usually points to main or some other local branch, but when you check out a previous commit, HEAD no longer points to a branch-it points directly to a commit. Git checkout is an easy way to “load” any of these saved snapshots onto your development machine. When you have found a commit reference to the point in history you want to visit, you can utilize the git checkout command to visit that commit. One of these branch names can then be logged using git log. Invoking the command, git branch -a will return a list of all known branch names. The command git branch is used to view and visit other branches. You can view all commits across all branches by executing git log -branches=*. It is entirely possible that the commit you're looking for is on another branch. ![]() By default, git log will only show commits for the currently selected branch. These IDs are used to travel through the committed timeline and revisit commits. resetting unpublished changes on your local machine.Įach commit has a unique SHA-1 identifying hash. First, it shows you how to explore old commits, then it explains the difference between reverting public commits in the project history vs. This tutorial provides all of the necessary skills to work with previous revisions of a software project. When 'undoing' in Git, you are usually moving back in time, or to another timeline where mistakes didn't happen. Additionally, multiple timelines can be managed through the use of branches. Commits are snapshots of a point in time or points of interest along the timeline of a project's history. ![]() This nomenclature includes terms like reset, revert, checkout, clean, and more.Ī fun metaphor is to think of Git as a timeline management utility. Additionally, Git has its own nomenclature for 'undo' operations that it is best to leverage in a discussion. It will be beneficial to refrain from mapping Git operations to any traditional 'undo' mental model. It is first important to note that Git does not have a traditional 'undo' system like those found in a word processing application. In this section, we will discuss the available 'undo' Git strategies and commands.
0 Comments
Read More
Leave a Reply. |