How to undo git pull origin command?. i connected to the amazon server ec2-instance using ssh and pemfile. and i navigated to the project directory on this server. And ran the "git pull origin". i want to undo this operation on this aws instance. how can i do this. this is a ruby on rails application
The answers mentioning only git reset --hard are not correct. Once you have done a pull, your HEAD has moved forward to the new point you updated to. The implied ref for git reset is HEAD, so that command will just reset you to... the place you already are.
JonasJR was closer when mentioning reflog. The reflog is a local history of every action you take. If you just performed a pull, it might look something like this.
$ git reflog
6dd1a7b93 HEAD#{0}: pull: Fast-forward
e45d35313 HEAD#{1}: checkout: moving from feature to master
... more ...
Here I have the last two actions I have taken. A pull, and just prior to that I used checkout to change branches.
To go back to the state before the pull, I can use its ref (HEAD#{1}).
git reset --hard 'HEAD#{1}'
Now if I look in the reflog, it will show I reset to that prior state. The reset itself has become part of the history, so you can also use reflog to undo a mistaken undo, if you need to.
$ git reflog
e45d35313 HEAD#{0}: reset: moving to HEAD#{1}
6dd1a7b93 HEAD#{1}: pull: Fast-forward
e45d35313 HEAD#{2}: checkout: moving from feature to master
As you can see, we've now gone away from 6dd1a7b93 and gone back to the previous state, e45d35313 (which is both HEAD#{2} and HEAD#{0} at this point).
Note that the reflog is local to this copy of the repo. If you checkout a copy somewhere else, it has its own completely independent reflog. This is not shared with other people on your project, etc.
The usual disclaimer with reset --hard apply here. If you have uncommitted changes at the moment, this command will wipe them out. In that case, use git stash to set them aside while you do your reset.
You want to undo the merge. Run this command:
git reset --hard
You can also reset to a specific state by running the same command and adding the SHA1 of the decired state. Run:
git reflog
to find out more about it!
Related
I did a mistake in the code and pushed it in to heroku master. I am not able to identify the problem in the code I have locally. I did a heroku rollback to previous version - it worked and previous version is visible on heroku.
However I am struggling to pull the code (as heroku clone:app name gives me an old code). I tried heroku releases to get the release number which I then used for git pull heroku af5c366b, however getting err:
fatal: Couldn't find remote ref af5c366b
How can the code be restored?
I am completely now to Heroku.
You should be able to simply run...
$ git checkout af5c366b
Which should bring you to a "detached head" state with this helpful message..
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
Once you checkout the branch you can merge that branch into master.
$ git checkout master
$ git merge new-branch-name
Maybe I misunderstood how GIT works.
I've run git rebase -i HEAD~10 and I could squash 10 commits into one. The issue is that all squashed commits are still there, and I thought they were going to be dropped after merging them all into one.
Is this the expected result? If so, can I rewrite the history to remove useless commits (since these changes are already in the commit which all previous commits were squashed)?
When you began your interactive rebase session, you should have been prompted with a list of the last 10 commits from the current branch:
git rebase -i HEAD~10
pick as2i8dw first commit
pick ee361eb second commit
...
pick b2762sx most recent commit
You need to change this file to the following:
pick as2i8dw first commit
squash ee361eb second commit
...
squash b2762sx most recent commit
Then you need to do a git commit to save the changes. Now when doing a git log you should only see the as2i8dw commit and none of the other ten.
That being said, is this what you did?
The issue is that all squashed commits are still there
If those commits are still accessible by any other reference (other branch or tag), there would still be visible, even after the current branch is rebased.
Try instead squashing the commits with a git reset --soft.
If HEAD does still reference your 10 commits:
git reset --soft HEAD~10
git commit -m "squashed 10 commits"
I faced the similar issue and figured out the actual cause for it:
The flow:
git rebase -i HEAD~10
# Retain the first commit from below( as pick) and change the rest of the `pick` to `squash`
# After your rebase is successful
git log
# You can see all your commits squashes to one commit
Then now when you git pull from your remote branch, it will pull the rest of the commits which is not there in local ( basically all the commits you had squashed previously, since it is now present in one commit) and hence you are seeing the previous commits as well.
Better way is to git push -f to your remote branch, if you are confident that you have no new changes added there.
P.S: If you have any new changes in the remote branch, better to:
git rebase origin remote_branch
and then squash your commits.
I have reset my master to a certain commit (hard) in the sourceTree. The master has been reset but I still get the a message to pull (4 behind). On pull all the previous unwanted changes has been added to my repo. How can I ignore any pull requests after Hard rest?
This is because those changes are on your remote. A hard reset will just discard the changes in your local branch and in your working copy.
To fix this you'd either have to do a force push, but this isn't recommended as it's dangerous and pisses off other devs working on that repo, and is generally dangerous. Your other option is going to be resetting the changes to a particular commit. This would look something like this:
git reset -q <SHA> -- <filename>
git checkout <SHA> -- <filename>
Where is the commit which you'd want to revet to, and is the file.
You can do this in SourceTree by context-clicking on a file at a specific commit and hitting "Reset to commit".
Hope that helps.
I have run into trouble with a recent production (well, staging actually but we'll keep calling it 'production') deployment.
I'd like to (read: need to) roll back the deploy to a previous commit. Actually, I'd like to go back a ways and then move forward cap deploying each commit one by one until I see the problem materialize. I know I can use cap -S revision=8c9ffa787b22cff019b27f71194637aa85506f9c deploy to deploy a specific commit.
My question is, when I FIND the commit I want to stick with how can I reset HEAD and master, etc. so that basically, master points to that commit and, ideally, all the subsequent commits are captured in a new branch of some name, say rabbithole?
Need to do this w/out fouling the git repos in development, GitHub and then the cached-copy that Capistrano automatically creates on production server.
Hope I'm making sense. If not please ask for more information.
Thanks!
I'd say you want to revert all commits between you stable commit and you HEAD. Check this
git checkout master
git revert XXSHAXX..HEAD
Where XXSHAXX is your stable commit.
This will create a bunch of new commits - one for each after stable. As a result you'll have a new commit equivalent to you stable in HEAD and none of your history will be lost.
P.S. and you wont be beaten by others who works in same repo.
To rollback to a previous commit
cap deploy:rollback
To rollback to a previously deployed commit
cap deploy:rollback:code
Once you've found a commit that you want to keep at master, you can do a rebase. Not sure if this is the best route, as you should always be wary of forcing an update on master.
I would temporarily change the branch where my staging environment is pulling from, rather than push a forced update on master upstream.
Ok, warnings aside:
$ git checkout master; git checkout -b master-backup-before-rebase; git checkout master
There might be a quicker/simpler way to do this, but we basically ensure we're on master, create a new branch called master-backup-before-rebase, and then go back to master.
$ git rebase -i head~XXX
Replace ~XXX with however many commits back you want to remove + 1.
Next, a text editor window will open - remove the lines of all commits you want to delete. Save, and close the window.
$ git push origin master -f
Voila.
Be very careful with this, and ensure that your backup branch exists before rebasing, lest you accidentally remain on the Master branch because you had uncommitted local changes or something.
I created a local Git repo on my laptop and then pushed the source to Heroku creating a remote branch. After a few days of commits and pushes, I need to rollback to an earlier commit. Here's what I did.
cd <app root>
git checkout 35fbd894eef3e114c814cc3c7ac7bb50b28f6b73
Someone told me that doing the checkout created a new working tree and not the branch itself, so when I pushed the rollback changes to Heroku, it said everything is up to date and nothing was pushed. How do I fix this situation? Thanks for your help in advance.
When you checkout a direct commit name (using the SHA-1 hash of the commit object) instead of checking out a branch name, you end up with a “detached HEAD”. HEAD is the “ref” that keeps track of what is currently checked out. It becomes detached when you directly checkout a commit instead of a branch (it is not attached to any branch). No branches are updated when you detach a repository's HEAD. You might think of the detached head state as if you had an anonymous branch checked out.
To reattach your repository's HEAD, you will want to save the current HEAD as a branch and check that branch out:
To save the current HEAD in a new branch do this:
git branch <new-branch-name>
To overwrite an existing branch you need to use --force:
git branch --force <existing-branch-name>
Then, reattach your repository's HEAD by checking out the new/updated branch:
git checkout <branch-name>
(where <branch-name> is the same as <new-branch-name> or <existing-branch-name>, depending on which of the above two commands you used)
This sequence (git branch to make a ref point to the current HEAD commit, then git checkout that updated branch) will carry forward any uncommitted content that you might have in your working index and/or tree.
In the future, if you want to ‘roll back’ the current branch to some previous commit, you should use this instead of detaching your repository's HEAD:
git reset --hard <commit>
This will reset the current branch (or your detached HEAD, if it is already detached) to the named commit, and make the index and the working tree reflect that commit (i.e. it throws away any commits since the specified commit along with any uncommitted content).
The detached HEAD state is useful for revisiting old states, and sometimes for short-term work that you are not sure you will keep. Other than that you probably want to avoid it.
You want to reset:
git reset --hard 35fbd894eef3e114c814cc3c7ac7bb50b28f6b73