I usually also do a lot of very heavy history rewriting when converting some repository from Subversion or Mercurial over to Git, be it to enforce internal LF line endings, fixing committer names and email addresses or to completely delete some large folders from all revisions. Be it because of leaked sensitive information, to get rid of some very large files that should not have been there in the first place, or just because you want a clean history (I certainly do). However, sometimes you do want to rewrite the history. If they have local changes, they have to do some work to get in sync again work which requires a bit more knowledge on how Git works to do it properly. People cannot just pull your rewritten history as usual. People generally avoid history rewiriting, for a good reason: it will fundamentally diverge your repository from anyone who cloned or forked it. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit. Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one. Sometimes you may want to undo a whole commit with all changes. ![]() The bad commit remains there and accessible, but this is usually not a big deal, unless the file contains sensitive information. This is the most natural way to fix an error, always safe and totally non-destructive, and how you should do it 99% of the time. Simply remove or fix the bad file in a new commit and push it to the remote repository. But you should do it rather fast before anyone fetches the bad commits, or you won't be very popular with them for a while )įirst two alternatives that will keep the history intact: Alternative: Correct the mistake in a new commit So you've just pushed your local branch to a remote branch, but then realized that one of the commits should not be there, or that there was some unacceptable typo in it. If we run git log, we'll see our commit history has been restored all the way back to our initial commit.About Git HowTo: revert a commit already pushed to a remote repository May 2010 Or, with: git checkout -b initial-branch SHA For example: git branch initial-branch SHA We can do by passing a second argument to git branch. However, if you want to make changes to a previous version of the repository, it's better to create a branch from the previous version. This is useful if we want to browse a previous version of the repository. As noted, you can make commits, but Git will not track them unless you create a new branch. This sounds a little scary, but really all it means is we are not on a branch. Immediately we receive a warning that we are in a detached HEAD state. So I'll run git checkout and pass it the commit SHA. Let's demonstrate by using the same commit SHA to restore our repository to the initial commit. If we output the contents of File 1, we'll see that it's again empty just as it was in our initial commit.įinally, we can use git checkout to restore the repository to a previous point in time by passing it a commit SHA. ![]() Since git checkout accepts a commit, this means we could checkout a file from a previous commit.įor example, to checkout File 1 from our initial commit, we could run: When you omit the commit reference, it's best to use the path separator of - to avoid a scenario where the name of the file you want to checkout matches a branch name. However, HEAD can be omitted as it's the default. The command we ran was really a shorthand for git checkout HEAD file-2.txt. Let's take a second to break this command down. If we run git status again, we'll see that we are back to a clean state. Notice Git tells use we can use git checkout to discard these changes by running: git checkout - file-2.txt Let's demonstrate this by making some changes to a file and running git status. The first is to checkout a file from a previous commit. There are also two other uses for git checkout In init: git checkout we covered how do use git checkout to switch branches as well as create and switch branches in one step with the -b option. In this video, we'll look at some of the additional uses for git checkout.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |