Videos
Sorry for the noob question but all the google answers are spread out over 10 years and totally different answers. I can't find a common consensus on this and don't want to screw anything up.
I just need to go back to my last commit. I committed and everything was fine but recent code changes broke the site and I need to go back to when things were working.
It says in the terminal:
(use "git restore <file>..." to discard changes in working directory)
This is what I'm looking for right? If I do "git restore <file>" it will discard all my changes and go back to what the file was like before I made the breaking changes?
Also, if so, I have a lot of files to change, if I just do "git restore" without a specified file will it restore ALL the files that have been modified so I don't have to go one by one?
Hi, I would like to revert to a previous commit. I believe I did this correctly on my local repository using git reset --hard commit-hash. I would like to push this to github but of this results in
error: failed to push some refs to 'https://github.com/shmish/smartmark.git' hint: Updates were rejected because the tip of your current branch is behind
I am the only working on this repository, so I am not worried about conflicts, I am trying to move back one commit.
I pushed some js file (48324843) that was compiled mistakenly because webpack was running for some reason, and I pushed 2 other commits ( 96481703 and 23891991) and want to revert the 3 last commits so I can repush everything else manually. What's the best way to do this?
Hello everyone! I'm working on a project in a team. I'm using GUI git client Fork, while also learning command line git.
I finished a task and made a commit (not pushed), but soon realized that I didn't get it done properly, and that I needed to put more work into it. So I left my initial commit as it was, and just kept on working on the task. Right now I'm finally finishing it, but I'm asked to make only one commit with the whole task in it.
When I try to Revert the initial commit, it gives me an error:
Your local changes to the following files would be overwritten by merge Revert failed
What should I do to keep the changes in the initial commit and reapply the new ones? I may have rewritten some code from the initial commit, but not fully, so some parts must stay, and the new changes to be added.
Thank you for your attention!
Hello, I messed up my files and want to go back to my last commit on my local repository. I have not yet committed since this last commit, which commands do I use? I'm a complete noob so I am kind of lost. Is this situation is different from if I want to go back to several pervious commits? Thanks!
So as the title states, I don't really know what I'm doing with Git. It exists, my code is there, and I can commit......that's pretty much it.
I sort of took over as dev for an opensource game, which is kinda funny given that my knowledge of c++ is what i've managed to amass through trial and error, so not much, lol.
I'm using the GitWindows Gui, because I haven't a clue where to even start with the command line, and to date, the Gui has done what i needed, though I should start doing more, and don't know if it will be sufficient.
So anyways. Here's what I'm hoping to learn atm:
1. Can I revert the master branch back to a point prior to when I branched it, without harming the branches?
2a. How do I revert the master branch to a previous state? Preferably through the Windows Gui.
2b. Would branching from the older commit, and re-designating the master line be the better move in this instance? How might i do that?
3. At what points are a branch worthwhile?
4. How do you prefer to name the branches? Any Common themes that are generally applied?
5. How does one merge a branch, in part or whole?
ELI5?
1. Can I revert the master branch back to a point prior to when I branched it, without harming the branches?
So, up to this point, I've been guilty of having a linear progression. I've avoided posting commits that are incomplete because I haven't been branching and didn't want the repo to be broken for extended periods, since I wasn't branching so the master line would be, well, broken until i finished.
That leaves me where I am now, with an official build that is 22 commits behind the experimental state, in need of a patch, that is in the repo, but the current repo isn't ready for prime time as anything more than an experimental build
I'd need to revert to where the previous release was, then incorporate the commits that are ready so I could get it out there without an experimental and incomplete state being included.
Is it possible to branch now to protect the current state in the repo, then revert the master to a previous state, without affecting the branch? Is the "protective" branch even necessary? Might it be better to branch from the past commit, which becomes the new master line, and pull from the old master line(from then on the experimental line) to improve the complete state of the game?
If its better to branch from an older commit
2a. How do I revert the master branch to a previous state? Preferably through the Windows Gui.
To date, i've only operated within the Gui, as the command line confused me to the point that i didn't know what i was doing.
I'll use the command line if someone is willing to walk me through it, though I'd prefer to use the Gui if its capable of it. Unfortunately, I know its rather less capable than the command line, or at least it was when I first downloaded it.
What I'd like to do is:
branch the master to have an experimental branch which is the current latest state.
revert the master to a point 22 commits ago, the last "ready" state, without losing the complete experimental branch.
merge the bits from later commits that are ready to go, back into the master branch
release a new update, minus code that isn't ready for full release, which will continue to exist in full in the experimental branch, until its ready and I merge that into the master.
is it possible to download the previous state from 22 commits ago, drop it over my local repo, then sync with master to accomplish that without doing irreparable harm or causing weirdness that should be avoided?
2b. Would branching from the older commit, and re-designating the master line be the better move in this instance? How might i do that?
Since I have all the code already laid out where it is, reverting to reach old code may be overkill, and rather poor practice the more I think about it.
I would guess that that is sort of the point behind all of the old commits being accessible, the freedom to branch from a previous state to create a new state to work with?
If so, then what I'd like to do, rather than as in Q2a, would be:
branch from previous commit
re-assign master line to this new branch, so the master is always the core lineage.
merge the bits from later commits that are ready to go, into the master branch
release a new update with the completed little updates.
3. At what points are a branch worthwhile?
I need to start branching more often, simply because I would rather be able to take my experimental edits, and drop them into the main line when little bits are ready to go without having to wait on the main focus of that update to also be ready.
I'd also like to keep the latest state in the repo, without having the main line be broken and unable to build and/or operate effectively, which, is pretty much the point of branching if I'm not mistaken.
I was thinking that I should probably branch for every little thing I set out to do, in part because then the branch map would be rather illustrative of what happened and where it happened, and also because it allows me to walk away from something for a while knowing the master line is still fully functional.
I was also thinking it may be worth branching each time I move the version number, both as a more obvious reference point, and so that I can easily keep tabs on the state of a given installer if someone says they were using 1.26 for example.
Is this sensible, or would I just create a mess that would have half of you face-palm hard enough break bone?
4. How do you prefer to name the branches? Any Common themes that are generally applied?
Given that i was thinking of branching every time I go off on some tangent with a new bit of code, as well as when I reach a state worthy of a version bump, I was thinking it may be worth naming the branches to coincide.
So I might have (if i can rename the master line) Master 1.29, and branches off there for things like 1.29 Exp. feature a, 1.29.001 fix, and so forth. Then when I hit 1.30, branch the master again with Master 1.30, and go from there.
5. How does one merge a branch, in part or whole?
I suspect i will often have bits that are worthy, and bits that are not, so I may not want to merge the entire branch, and sometimes i will want to. Having not branched anything yet, if its straightforward and nearly idiot proof like making a commit is, feel free to simply say so and leave it there, that alone sets me at ease.
If its more involved though, I'd love to know what i'm doing before i get there.
I know its my repo, I can do with it as i wish, but I'd like a little input on good practices with a repo, so that I'm doing it 'right' so to speak, and if anyone experienced with git ever goes to give me a hand, they don't cringe at the sight of it. Good practice is typically good practice for a reason.
For the curious:
https://github.com/gcblue/gcblue
cringe in fear at my horrible grasp of c++ and git.....feel free to critique as warranted.
edit: appending a url of interest: https://windows.github.com/ that's the gui I'm using.
This depends a lot on what you mean by "revert".
Temporarily switch to a different commit
If you want to temporarily go back to it, fool around, then come back to where you are, all you have to do is check out the desired commit:
# This will detach your HEAD, that is, leave you with no branch checked out:
git checkout 0d1d7fc32
Or if you want to make commits while you're there, go ahead and make a new branch while you're at it:
git checkout -b old-state 0d1d7fc32
To go back to where you were, just check out the branch you were on again. (If you've made changes, as always when switching branches, you'll have to deal with them as appropriate. You could reset to throw them away; you could stash, checkout, stash pop to take them with you; you could commit them to a branch there if you want a branch there.)
Hard delete unpublished commits
If, on the other hand, you want to really get rid of everything you've done since then, there are two possibilities. One, if you haven't published any of these commits, simply reset:
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
If you mess up, you've already thrown away your local changes, but you can at least get back to where you were before by resetting again.
Undo published commits with new commits
On the other hand, if you've published the work, you probably don't want to reset the branch, since that's effectively rewriting history. In that case, you could indeed revert the commits. In many enterprise organisations, the concept of "protected" branches will even prevent history from being rewritten on some major branches. In this case, reverting is your only option.
With Git, revert has a very specific meaning: create a commit with the reverse patch to cancel it out. This way you don't rewrite any history.
First figure out what commits to revert. Depending on the technique chosen below, you want to either revert only the merge commits, or only the non-merge commits.
# This lists all merge commits between 0d1d7fc and HEAD:
git log --merges --pretty=format:"%h" 0d1d7fc..HEAD | tr '\n' ' '
# This lists all non merge commits between 0d1d7fc and HEAD:
git log --no-merges --pretty=format:"%h" 0d1d7fc..HEAD | tr '\n' ' '
Note: if you revert multiple commits, the order matters. Start with the most recent commit.
# This will create three separate revert commits, use non merge commits only:
git revert a867b4af 25eee4ca 0766c053
# It also takes ranges. This will revert the last two commits:
git revert HEAD~2..HEAD
# Similarly, you can revert a range of commits using commit hashes (non inclusive of first hash):
git revert 0d1d7fc..a867b4a
# Reverting a merge commit. You can also use a range of merge commits here.
git revert -m 1 <merge_commit_sha>
# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .
# Then commit. Be sure and write a good message describing what you just did
git commit
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
Lots of complicated and dangerous answers here, but it's actually easy:
git revert --no-commit 0d1d7fc3..HEAD
git commit
git push
This will revert everything from the HEAD back to the commit hash (excluded), meaning it will recreate that commit state in the working tree as if every commit after 0d1d7fc3 had been walked back. You can then commit the current tree, and it will create a brand new commit essentially equivalent to the commit you "reverted" to.
(The --no-commit flag lets git revert all the commits at once- otherwise you'll be prompted for a message for each commit in the range, littering your history with unnecessary new commits.)
This is a safe and easy way to rollback to a previous state. No history is destroyed, so it can be used for commits that have already been made public.
Note on merge commits:
If one of the commits between 0766c053..HEAD (inclusive) is a merge then there will be an error popping up (to do with no -m specified). The following link may help those encountering that: Why does git revert complain about a missing -m option? (thanks @timhc22 for pointing out)
I was trying to revert my work to the last commit after experimenting with stuff but instead reverted it to the commit before that because I didn't know which git command I'm supposed to use. How do I move the current head forward? How do I get the work that's currently last commited on Github?
Been learning to code for over a year and I still have no idea how git works. Most stackflow results make no sense to me, tbh. I just can't ever wrap my head around how git works, other than initializing, commiting, and pushing. Thanks a lot in advance, any help is much appreciated.
Hi guys,
I am stuck in another tricky situation.
When I discovered I have done certain commits that are wrong, then I did :
git reset --hard commitNo1
I went on to do the changes that I need to only to discover that the code is already mixed with some code-generation stuff. No choice, I then wanted to revert to a earlier version :
I did
git revert --no-commit commitEarlierNo..HEAD
following this suggestion :
https://stackoverflow.com/questions/4114095/how-do-i-revert-a-git-repository-to-a-previous-commit
and now I got this below message:
error: Your local changes to the following files would be overwritten by merge: Please commit your changes or stash them before you merge Aborting fatal: revert failed
Please help me now what can i do by aborting all the changes and I just want to revert to that even earlier version, and I am ok to discard changes I have made so far after I did that reset Hard to that commitNo1
Undo a commit & redo
$ git commit -m "Something terribly misguided" # (0: Your Accident)
$ git reset HEAD~ # (1)
# === If you just want to undo the commit, stop here! ===
[ edit files as necessary ] # (2)
$ git add . # (3)
$ git commit -c ORIG_HEAD # (4)
git resetis the command responsible for the undo. It will undo your last commit while leaving your working tree (the state of your files on disk) untouched. You'll need to add them again before you can commit them again.- Make corrections to working tree files.
git addanything that you want to include in your new commit.- Commit the changes, reusing the old commit message.
resetcopied the old head to.git/ORIG_HEAD;commitwith-c ORIG_HEADwill open an editor, which initially contains the log message from the old commit and allows you to edit it. If you do not need to edit the message, you could use the-Coption.
Alternatively, to edit the previous commit (or just its commit message), commit --amend will add changes within the current index to the previous commit.
To remove (not revert) a commit that has been pushed to the server, rewriting history with git push origin main --force[-with-lease] is necessary. It's almost always a bad idea to use --force; prefer --force-with-lease instead, and as noted in the git manual:
You should understand the implications of rewriting history if you amend a commit that has already been published.
Further Reading
You can use git reflog to determine the SHA-1 for the commit to which you wish to revert. Once you have this value, use the sequence of commands as explained above.
HEAD~ is the same as HEAD~1. The article What is the HEAD in git? is helpful if you want to uncommit multiple commits.
Undoing a commit is a little scary if you don't know how it works. But it's actually amazingly easy if you do understand. I'll show you the 4 different ways you can undo a commit.
Say you have this, where C is your HEAD and (F) is the state of your files.
(F)
A-B-C
↑
master
Option 1: git reset --hard
You want to destroy commit C and also throw away any uncommitted changes. You do this:
git reset --hard HEAD~1
The result is:
(F)
A-B
↑
master
Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.
Option 2: git reset
Maybe commit C wasn't a disaster, but just a bit off. You want to undo the commit but keep your changes for a bit of editing before you do a better commit. Starting again from here, with C as your HEAD:
(F)
A-B-C
↑
master
Do this, leaving off the --hard:
git reset HEAD~1
In this case the result is:
(F)
A-B-C
↑
master
In both cases, HEAD is just a pointer to the latest commit. When you do a git reset HEAD~1, you tell Git to move the HEAD pointer back one commit. But (unless you use --hard) you leave your files as they were. So now git status shows the changes you had checked into C. You haven't lost a thing!
Option 3: git reset --soft
For the lightest touch, you can even undo your commit but leave your files and your index:
git reset --soft HEAD~1
This not only leaves your files alone, it even leaves your index alone. When you do git status, you'll see that the same files are in the index as before. In fact, right after this command, you could do git commit and you'd be redoing the same commit you just had.
Option 4: you did git reset --hard and need to get that code back
One more thing: Suppose you destroy a commit as in the first example, but then discover you needed it after all? Tough luck, right?
Nope, there's still a way to get it back. Type this
git reflog
and you'll see a list of (partial) commit SHAs (that is, hashes) that you've moved around in. Find the commit you destroyed, and do this:
git checkout -b someNewBranchName shaYouDestroyed
You've now resurrected that commit. Commits don't actually get destroyed in Git for some 90 days, so you can usually go back and rescue one you didn't mean to get rid of.
Say you have this
commit A
commit B
commit C
commit D
where commit A is the earliest, and D is the latest commit.
You now realize that you made mistake in commit B. You want to revert the changes made in B but you do not want to revert the changes in commit C and D.
Hi I made several commits to a project last week and this morning I noticed that one of the feature is broken.
This feature was working fine 2 weeks ago.
So I guess one of the changes I made last week is the cause.
The fact is I made changes in almost every files, and the feature is kind of mysterious to me and it's hard to say in which file (if not multiples) it is originated.
So, what I would like to do, is come back to an old commit, try the app, check if the feature is working, if not try another commit, if still not try another commit, etc..., until I find the last commit where it was working.
What is the good way to do that ?
I'm currently doing like this:
Git log --oneline Git reset 450j8o5
If it's not the commit I was looking for I do:
Git log --oneline Git reset --hard 3987a65
Etc Until I want to comeback to where I was, my last commit:
Git reflog
Git reset --hard HEAD@{5}Is it how you would do it ? Am I doing something wrong ?
Thanks