My coworker was on one branch, I was on the other. When she merged her branch with mine, my changes did not get in. The source files were "M" (Modified) in Xcode and not "C" (Conflict) so we assumed it was ok. I went back to my branch and I saw that the the code I changed was still there and my code was working fine. Then we thought to try the merge again but being on my branch from my desktop. Same thing showed up where the files were "M" and none were "C".
Again my changes got overriden. So now I'm trying to go back a merge. I tried using the Github tool I downloaded from http://mac.github.com/ by clicking on the most recent commit, and rolling back to that commit, but my changes still seemed to be gone. I do not see the merging of the branches in the history. Is that because I haven't committed after merging?
How can I get back to my branch before I merged?
I haven't used Xcode's version control GUI nor Github tool. If you know the sha1 of the commit which had your changes, you can do this at the command line:
git reset --hard <the sha1>
That will reset your current branch to be at your commit. It will also reset the files in the working tree. Be careful. If you have uncommitted changes, they will be lost.
You can reset the last n number of unpushed commits(commited yet but not pushed). Then command you need to use is
git reset HEAD -- will omit the last commit
git reset HEAD^n -- will omit the n number of last unpushed commits.
Related
-
I working on project in bitbucket and I tried to pull my partner commit put I got this
You (or the editor) have made local change, so you cannot simply pull.
If you want to discard any local change, then before pull, reset all files by typing
git reset --hard
If you want to save these changes, then commit it, pull, and then resolve conflicts if there is any.
If you are not sure or not familiar with git, backup the two files indicated to somewhere else, and use 1. to reset them.
In my opinion, if you do not remember any change you made, simply use 1.
I had made a few new views in a new branch off of the master branch and had finally finished making those and was ready to merge back to to master branch but xcode crashed right in the middle of the merge and now source control says my last commit was 14 days ago and has reverted to that version even though i have been committing it every day. Does anyone know how to get the files back and get my source control to remember the most recent commits. Thanks.
Try "git reflog" to see if you see all your previous commits.
Use "git reset --hard HEAD^" to go back to that commit. "HEAD^" in this case is the commit hash you will see with "git reflog".
I have 2 branches master, testing. I git checkout testing and added an exclusion in .git/info/exclude
I added this into exclude: MyProject/MyProject.xcodeproj/project.pbxproj
I did this so it wouldnt prompt me to add it and commit it everytime because it changes whenever I change tab or stuff like that.
I committed this to testing and pushed, then I git checkout master and git merge testing.
In the terminal it said this: delete mode 100644 MyProject/MyProject.xcodeproj/project.pbxproj
And after this I cant open my xcode project anymore, it says cannot be opened because it is missing its project.pbxproj file
And now I cant seem to get it back, I cant find it in my github under commits. ;_;
Usually you put this stuff in your .gitignore rather than .git/info/exclude.
To get it back you could check out the commit right before removing it (assuming there is such a commit), move it someplace safe, and then re-add it after switching back to master.
If it's a file that is needed in the repository, then making git ignore it doesn't really make any sense (think of the guy cloning a fresh copy). Perhaps you'll have to live with either committing changes to it all the time, or get into the habit of leaving that file unstaged most of the time.
I'm using Git Gui and Gitk on Windows. How do I undo a hard reset from within the past two hours?
(Is it possible to do this from these applications, without using the command line?)
I saw this SO post, which says that undos are possible before git's garbage collection occurs. I might have quit and reopened one or both of these applications.
If you had changes in your working tree that were not committed when you did git reset --hard, those changes are gone for ever. You have to use your memory (in your head) to recreate them.
Changes that were committed after the commit to which you switched are not lost. They likely have no reference pointing to them, making them more difficult to locate. The tool to list all low-level changes to the repo is git reflog.
After you locate the commit which you want to revert to observe the hash number in the first row and use git reset --hard #hashnumber or git checkout #hashnumber to get the changes.
I found this useful line on http://quirkygba.blogspot.com/2008/11/recovering-history-with-git-reflog.html:
gitk --all $(git reflog | cut -c1-7)
This will display all the hidden changes in gitk, where you can comfortably view, point, click and create new branches.
As you mentioned the unreferenced commits are normally being kept in the repository for 30 days.
EDIT: I have to add stuff here so that my edit is at least 6 characters. I know, sometimes code fixes are less than 6 characters, but there might, after all, be something else to improve in this post.
See the answers by Brian Riehman and Pat Notz in the link in the question.
One solution is to use the command line.
In Windows, open DOS in the directory containing your .git directory.
Type something like the following to see what commit you want to go to:
"c:\Program Files\Git\bin\git.exe" reflog
To go to a certain commit, type something like the following, where the last expression is the SHA1 code of that commit:
"c:\Program Files\Git\bin\git.exe" reset --hard 5eb4080
I don't think you can undo a hard reset to get uncommitted changes back - you can undo a rebase because the blobs are still available, but if you never committed your newest changes to Git ever, anything it overwrote is most likely history. I'd love to find out that I'm wrong though!
Using TortoiseGit (I'm trying to avoid command line usage) how does one delete all commits that accended from a certain commit, and "get back in the past" (example usage: continued doing something, figured I didn't like where it was going, and decided to go "back" disregarding all in between).
In short I wish to go 5 commits "back", and delete them afterwards.
Go to TortoiseGit -> Show log. Select the most recent commit you want to keep, everything above will be erased. Then right click on it and select "Reset "master" to this" and choose Hard. Be careful though because once you do this all the commits after it will be forever lost unless they are stored off in another branch somewhere.
I've never used Tortoise anything (unless you count the electronica group), but I'll give you this info in case you don't find a way to do it with the GUI or you end up deciding to go CLI after all.
As #Tuxified mentions, you can accomplish this with git reset --hard <COMMIT>. You need to specify a commit, which can be done in any of an intimidating panoply of possible ways; the most common have forms like HEAD~4, which specifies a commit 4 commits before the head of the current branch, and deadbeef42, which specifies a commit whose SHA1 starts with 0xdeadbeef42. If you're running linux or OSX, you can get the full details on commit specifiers via man git-rev-parse, under "SPECIFYING REVISIONS".
You can also rename the current branch (git branch -m new_branch_name) and then create a new branch with its head at the place you want to revert to. The advantage is that if you end up wanting to use all or some of the stuff you did there, you can still readily access it; and if you typo the commit, you're saved from a big holycrap moment. Plus git branches are super lightweight so the only real downside is that there will be another branch listed. To make the new master branch you would use git branch master <COMMIT>, and then you check it out. So the net effect here is the same as the first option, except that you still have your old changes saved in the branch new_branch_name. You can even merge those changes back in later, after new commits to master, if you feel like it.
Note that either of these techniques are considered "rewriting history" and will cause issues if you're sharing your repo with others. If you're being smart and pushing to a backup repo in cloud city or another pc, you will have to fix things on that end before you can push to it again.
This is probably way more info than you need right now, but if you end up using git a lot you'll probably want to learn this stuff at some point. Sorry I don't know how to use Tortoise...