GIT Revert | need to practice *

The git-revert manpage actually covers a lot of this in its description. Another useful link is this git-scm.com section discussing git-revert.

If you decide you didn't want to revert after all, you can revert the revert (as described here) or reset back to before the revert (see the previous section).

You may also find this answer helpful in this case:
How can I move HEAD back to a previous location? (Detached head) & Undo commits

 

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

When you do a git pull origin master,
git pull performs a merge, which often creates a merge commit. Therefore, by default, pulling from the remote is NOT a harmless operation: it can create a new commit sha that didn’t exist before. This behavior can confuse a user, because what feels like it should be a harmless download operation actually changes the commit history in unpredictable ways.

To avoid this, you need

git pull --ff-only

(or not? read on to see which one fits your requirements)

With git pull --ff-only, Git will update your branch only if it can be “fast-forwarded” without creating new commits. If this can’t be done, git pull --ff-only simply aborts with an error message.

You can configure your Git client to always use --ff-only by default, so you get this behavior even if you forget the command-line flag:

git config --global pull.ff only

Note: The --global flag applies the change for all repositories on your machine. If you want this behaviour only for the repository you're in, omit the flag.

Taken from here

In Git 1.7.0 and later, you can checkout a new branch:

git checkout -b <branch>

Edit files, add and commit. Then push with the -u (short for --set-upstream) option:

git push -u origin <branch>

Git will set up the tracking information during the push.

It's also worth noting that if you have an existing tracking branch already set on the branch you're pushing, and push.default is set to upstream, this will not do what you think it will do. It will try to push over the existing tracking branch. Use: git push -u origin mynewfeature:mynewfeature or do git branch --unset-upstream first.

git pull is the same as git fetch followed by git merge.

To create a local branch tracking a branch on a remote, first fetch from the remote and then run git checkout with the name of a branch that matches that on the remote:

git fetch <remote>
git checkout <branch>

• <remote> is the name of the remote, for instance origin.
• <branch> is the name of a branch on that remote. If git branch -r shows a branch name origin/foo, Git should set this up correctly if you do git checkout foo.

Note first that your question shows a bit of misunderstanding. origin/HEAD represents the default branch on the remote, i.e. the HEAD that's in that remote repository you're calling origin. When you switch branches in your repo, you're not affecting that. The same is true for remote branches; you might have master and origin/master in your repo, where origin/master represents a local copy of the master branch in the remote repository.

origin's HEAD will only change if you or someone else actually changes it in the remote repository, which should basically never happen - you want the default branch a public repo to stay constant, on the stable branch (probably master). origin/HEAD is a local ref representing a local copy of the HEAD in the remote repository. (Its full name is refs/remotes/origin/HEAD.)

I think the above answers what you actually wanted to know, but to go ahead and answer the question you explicitly asked... origin/HEAD is set automatically when you clone a repository, and that's about it. Bizarrely, that it's not set by commands like git remote update - I believe the only way it will change is if you manually change it. (By change I mean point to a different branch; obviously the commit it points to changes if that branch changes, which might happen on fetch/pull/remote update.)

Edit: The problem discussed below was corrected in Git 1.8.4.3; see this update.

There is a tiny caveat, though. HEAD is a symbolic ref, pointing to a branch instead of directly to a commit, but the git remote transfer protocols only report commits for refs. So Git knows the SHA1 of the commit pointed to by HEAD and all other refs; it then has to deduce the value of HEAD by finding a branch that points to the same commit. This means that if two branches happen to point there, it's ambiguous. (I believe it picks master if possible, then falls back to first alphabetically.) You'll see this reported in the output of git remote show origin:

$ git remote show origin
* remote origin
  Fetch URL: ...
  Push  URL: ...
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    foo
    master

Oddly, although the notion of HEAD printed this way will change if things change on the remote (e.g. if foo is removed), it doesn't actually update refs/remotes/origin/HEAD. This can lead to really odd situations. Say that in the above example origin/HEAD actually pointed to foo, and origin's foo branch was then removed. We can then do this:

$ git remote show origin
...
HEAD branch: master
$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/foo
$ git remote update --prune origin
Fetching origin
 x [deleted]         (none)     -> origin/foo
   (refs/remotes/origin/HEAD has become dangling)

So even though remote show knows HEAD is master, it doesn't update anything. The stale foo branch is correctly pruned, and HEAD becomes dangling (pointing to a nonexistent branch), and it still doesn't update it to point to master. If you want to fix this, use git remote set-head origin -a, which automatically determines origin's HEAD as above, and then actually sets origin/HEAD to point to the appropriate remote branch.

https://stackoverflow.com/questions/1463340/how-to-revert-multiple-git-commits

Expanding what I wrote in a comment

The general rule is that you should not rewrite (change) history that you have published, because somebody might have based their work on it. If you rewrite (change) history, you would make problems with merging their changes and with updating for them.

So the solution is to create a new commit which reverts changes that you want to get rid of. You can do this using git revert command.

You have the following situation:

A <-- B  <-- C <-- D                                  <-- master <-- HEAD

(arrows here refers to the direction of the pointer: the "parent" reference in the case of commits, the top commit in the case of branch head (branch ref), and the name of branch in the case of HEAD reference).

What you need to create is the following:

A <-- B  <-- C <-- D <-- [(BCD)-1]                   <-- master <-- HEAD

where [(BCD)^-1] means the commit that reverts changes in commits B, C, D. Mathematics tells us that (BCD)-1 = D-1 C-1 B-1, so you can get the required situation using the following commands:

$ git revert --no-commit D
$ git revert --no-commit C
$ git revert --no-commit B
$ git commit -m "the commit message for all of them"

Works for everything except merge commits.

Alternate solution would be to checkout contents of commit A, and commit this state. Also works with merge commits. Added files will not be deleted, however. If you have any local changes git stash them first:

$ git checkout -f A -- . # checkout that revision over the top of local files
$ git commit -a

Then you would have the following situation:

A <-- B  <-- C <-- D <-- A'                       <-- master <-- HEAD

The commit A' has the same contents as commit A, but is a different commit (commit message, parents, commit date).

Alternate solution by Jeff Ferland, modified by Charles Bailey builds upon the same idea, but uses git reset. Here it is slightly modified, this way WORKS FOR EVERYTHING:

$ git reset --hard A
$ git reset --soft D # (or ORIG_HEAD or @{1} [previous location of HEAD]), all of which are D
$ git commit

$ git reset --hard A
$ git reset --soft D # (or ORIG_HEAD or @{1} [previous location of HEAD]), all of which are D
$ git commit

Share

Improve this answer

Follow

edited Oct 12 '20 at 17:20

rogerdpack

51.7k3131 gold badges218218 silver badges338338 bronze badges

answered Sep 24 '09 at 8:44

Jakub Narębski

272k5959 gold badges209209 silver badges228228 bronze badges

• 50

  If you added files in B, C or D. the git checkout -f A -- . Will not delete these, you will have to do it manually. I applied this strategy now, thanks Jakub – oma Mar 31 '11 at 14:56

• 19

  Those solutions are not equivalent. The first one doesn't delete newly created files. – m33lky Jan 26 '12 at 5:57

• 10

  @Jerry: git checkout foo might mean checkout branch foo (switch to branch) or checkout file foo (from index). -- is used to disambiguate, e.g. git checkout -- foo is always about file. – Jakub Narębski Jan 23 '13 at 2:34

• 121

  In addition to great answer. This shorthand works for me git revert --no-commit D C B – welldan97 Aug 9 '13 at 12:34

• 10

  @welldan97: Thanks for a comment. When writing this answer git revert didn't accept multiple commits; it is quite new addition. – Jakub Narębski Aug 9 '13 at 18:39

Find commit you are set at on head

Use the command:

git rev-parse HEAD

For the short version:

git rev-parse --short HEAD

a899d14f

git reset --hard <SOME-COMMIT>

git reset --hard 1a35d478

https://stackoverflow.com/questions/9529078/how-do-i-use-git-reset-hard-head-to-revert-to-a-previous-commit

First, it's always worth noting that git reset --hard is a potentially dangerous command, since it throws away all your uncommitted changes. For safety, you should always check that the output of git status is clean (that is, empty) before using it.

Initially you say the following:

So I know that Git tracks changes I make to my application, and it holds on to them until I commit the changes, but here's where I'm hung up:

That's incorrect. Git only records the state of the files when you stage them (with git add) or when you create a commit. Once you've created a commit which has your project files in a particular state, they're very safe, but until then Git's not really "tracking changes" to your files. (for example, even if you do git add to stage a new version of the file, that overwrites the previously staged version of that file in the staging area.)

In your question you then go on to ask the following:

When I want to revert to a previous commit I use: git reset --hard HEAD And git returns: HEAD is now at 820f417 micro

How do I then revert the files on my hard drive back to that previous commit?

If you do git reset --hard <SOME-COMMIT> then Git will:

• Make your current branch (typically master) back to point at <SOME-COMMIT>.
• Then make the files in your working tree and the index ("staging area") the same as the versions committed in <SOME-COMMIT>.

HEAD points to your current branch (or current commit), so all that git reset --hard HEAD will do is to throw away any uncommitted changes you have.

So, suppose the good commit that you want to go back to is f414f31. (You can find that via git log or any history browser.) You then have a few different options depending on exactly what you want to do:

• Change your current branch to point to the older commit instead. You could do that with git reset --hard f414f31. However, this is rewriting the history of your branch, so you should avoid it if you've shared this branch with anyone. Also, the commits you did after f414f31 will no longer be in the history of your master branch.

• Create a new commit that represents exactly the same state of the project as f414f31, but just adds that on to the history, so you don't lose any history. You can do that using the steps suggested in this answer - something like:

  git reset --hard f414f31
  git reset --soft HEAD@{1}
  git commit -m "Reverting to the state of the project at f414f31"
  

https://docs.gitlab.com/ee/user/project/merge_requests/revert_changes.html

Reverting changes all tiers

You can use Git’s powerful feature to revert any commit by clicking the Revert button in merge requests and commit details.

Reverting a merge request

The Revert button is available only for merge requests created in GitLab 8.5 and later. However, you can still revert a merge request by reverting the merge commit from the list of Commits page.

The Revert button is shown only for projects that use the merge method “Merge Commit”, which can be set under the project’s Settings > General > Merge request. Fast-forward commits can not be reverted by using the merge request view.

After the merge request has been merged, use the Revert button to revert the changes introduced by that merge request.

After you click that button, a modal appears where you can choose to revert the changes directly into the selected branch or you can opt to create a new merge request with the revert changes.

After the merge request has been reverted, the Revert button is no longer available.

Reverting a commit

You can revert a commit from the commit details page:

Similar to reverting a merge request, you can opt to revert the changes directly into the target branch or create a new merge request to revert the changes.

After a commit is reverted, the Revert button is no longer available.

When reverting merge commits, the mainline is always the first parent. If you want to use a different mainline, you need to do that from the command line.

Here’s an example to revert a merge commit using the second parent as the mainline:

git revert -m 2 7a39eb0

https://docs.gitlab.com/ee/topics/git/rollback_commits.html

Rollback commits all tiers

Undo Commits

• Undo last commit putting everything back into the staging area:

  git reset --soft HEAD^
  

Add files and change message with:

git commit --amend -m "New Message"

Undo last and remove changes:

git reset --hard HEAD^

Same as last one but for two commits back:

git reset --hard HEAD^^

Don’t reset after pushing

Reset Workflow

1. Edit file again ‘edit_this_file.rb’
2. Check status
3. Add and commit with wrong message
4. Check log
5. Amend commit
6. Check log
7. Soft reset
8. Check log
9. Pull for updates
10. Push changes

Commands

# Change file edit_this_file.rb
git status
git commit -am "kjkfjkg"
git log
git commit --amend -m "New comment added"
git log
git reset --soft HEAD^
git log
git pull origin master
git push origin master

Note

• git revert vs git reset
• Reset removes the commit while revert removes the changes but leaves the commit
• Revert is safer considering we can revert a revert

# Changed file
git commit -am "bug introduced"
git revert HEAD
# New commit created reverting changes
# Now we want to re apply the reverted commit
git log # take hash from the revert commit
git revert <rev commit hash>
# reverted commit is back (new commit created again)

HOW TO REVERSE A COMMIT - GITLAB

https://stackoverflow.com/questions/40245767/delete-commit-on-gitlab

Supose you have the following scenario:

* 1bd2200 (HEAD, master) another commit
* d258546 bad commit
* 0f1efa9 3rd commit
* bd8aa13 2nd commit
* 34c4f95 1st commit

Where you want to remove d258546 i.e. "bad commit".

You shall try an interactive rebase to remove it: git rebase -i 34c4f95

then your default editor will pop with something like this:

 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

just remove the line with the commit you want to strip and save+exit the editor:

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

git will proceed to remove this commit from your history leaving something like this (mind the hash change in the commits descendant from the removed commit):

 * 34fa994 (HEAD, master) another commit
 * 0f1efa9 3rd commit
 * bd8aa13 2nd commit
 * 34c4f95 1st commit

Now, since I suppose that you already pushed the bad commit to gitlab, you'll need to repush your graph to the repository (but with the -f option to prevent it from being rejected due to a non fastforwardeable history i.e. git push -f <your remote> <your branch>)

Please be extra careful and make sure that none coworker is already using the history containing the "bad commit" in their branches.

Alternative option:

Instead of rewrite the history, you may simply create a new commit which negates the changes introduced by your bad commit, to do this just type git revert <your bad commit hash>. This option is maybe not as clean, but is far more safe (in case you are not fully aware of what are you doing with an interactive rebase).