I was trying to add a repository to my xcode project, but instead of adding my project files to the repository, git removed my entire project. I think I can use 'git revert' option to revert the changes, but how do I know where to revert to?
Get the list of commits using
git log this will list out all the commits with its hash, to revert the commit use
git revert (part of the hash)
for example if the commit hash is adghgd356484fghfbht76, do
git revert adghgd3564
If you have not pushed your changes to remote, you can run git reset --hard which will undo all your local changes and you will loose those changes from the history as well
Related
I committed some changes in my Xcode project and tried to push them, but I am prompted with: "The local repository is out of date."
Then I tried to pull as they said, but then I am prompted with: "The working copy has conflicting, uncommitted changes."
I really need to commit these changes, and I am scared of losing them if I do any wrong step. What should I do?
Thanks
A opportunity is to git stash (cache) your local changes and then git pull the changes from remote. Then your local code is up-to-date with the remote.
After pulling, with git stash pop your stashed changes would be reapplied.
But be careful, there can be merge conflicts.
Now you are able to git commit and git push your local changes to the remote repository.
I imported an external project into my project by dragging its project file into mine. It didn't work. Now those files show up whenever I check something in. I don't want them and I never select them at checkin, but how do I get rid of them? I don't find them in the underlying file system, and I haven't found any controls that will get rid of them. They appear in the source control navigator under the changes tab as Local Changes.
As far as I understand, you have a project in the local area that you version control with git. You tried something new on the project after the last commit. But you want to cancel the changes and go back to when the last commit was made. In this case you can use the following commands:
# Undo changes made to tracked files
git reset HEAD --hard
# Delete untracked files
git clean -f
# Delete untracked files and directories
git clean -fd
If there is valuable data between the last commit and the current state, you will lose as a result of the above operations. To prevent this situation, you can choose the following way:
# Secure the difference between the last commit and the current state
git commit -m "recovery"
# Revert to two previous commits
git reset HEAD~2
References
How To Undo Last Git Commit
Reset all changes after last commit in git
I am working on a git repository with a master branch and another the topic branch. I have switched to topic branch and modified a file. Now, if I switched to the master branch, that same file is shown as modified.
For example:
git status in git-build branch:
# On branch git-build
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: cvsup_current
#
Switch to master branch
[root#redbull builder_scripts (git-build)]# git co master
M builder_scripts/cvsup_current
Switched to branch "master"
git status in master branch
[root#redbull builder_scripts (master)]# git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: cvsup_current
#
Why is that the file is shown as modified in the master branch even though it was modified in git-build branch?
My understanding was that the branches are independent of each other and when I change from one branch to another the changes do not "spill over" from one branch to another. So I am obviously missing something here.
Has anyone got a clue stick?
Why is that the file is shown as modified in master branch even though it was modified in git-build branch?
The key to remember is that the file was not modified in the git-build branch. It was only modified in your working copy.
Only when you commit are the changes put back into whichever branch you have checked out
If you want to temporarily store your changes to one branch while you go off to do work on another, you can use the git stash command. It's one of the amazing little unsung perks of using git. Example workflow:
git stash #work saved
git checkout master
#edit files
git commit
git checkout git-build
git stash apply #restore earlier work
git stash stores a stack of changes, so you can safely store multiple checkpoints. You can also give them names/descriptions. Full usage info here.
This is the default behaviour of git.
You can use -f flag to checkout to do "clean checkout" if you like.
The modified files are not put in the repository until you add and commit them. If you switch back to your topic branch and commit the file, then it won't appear on the master branch.
It is not like git branches are dependent on each other but also they
do not have a complete code base separately for each branch either.
For each commit, Git stores an object that contains a pointer to the
changes. So each branch points to its own latest commit and HEAD points to the branch currently you are in.
When you switch the branch, the HEAD pointer points to that
particular commit of the branch. So if there are modified files, the
default behavior is to copy over them.
You can do the following things to overcome this issue.
Use -f option to ignore the changes.
If you want to save the changes:
Commit the changes locally in the same branch and then switch the
branch.
Use git stash, switch the branch, do your work, switch back to the
original branch and do git stash apply.
In my experience this "spillover" problem arises because git does not protect "untracked" files from git checkout (only tracked but uncommitted files would be protected, i.e. user would be forced to git commit them before a git checkout is allowed to another branch).
If you switch back to the original branch that created these files (and "untracks" them), these files become "untracked" again and can be git add'ed or git rm'ed.
For me it looks like a bug: even "untracked" files should be protected from git checkout.
When git tfs could not create a merge commit, it says
warning: this changeset 7504 is a merge changeset. But it can't have been managed accordingly because one of the parent changeset 7494 is not present in the repository! If you want to do it, fetch the branch containing this changeset before retrying...
As per the documentation, Note: if you see a warning, you could correct that by reseting the tfs remote to a previous commit. Then fetch the merged branch and retry to fetch the branch.
Can anyone please elaborate on reseting the tfs remote to a previous commit. Though, I've now fetched the merged branch, I don't understand how do I reset it to previous commit to the failed one. I'm not sure but do I have to git checkout <hash of the previous commit>?
Yes, now git-tfs try to create merge commit when it encounter merge changesets (now that it has a satisfying branch support).
This message is just a warning message and when you see it, you have 2 options...
The first one is to do nothing because you know that it was, for exemple, an old feature branch that you will never work on that and MORE IMPORTANT that in the future you will never merge again in your parent branch.
The second one is if you really want to have this merge commit. Because you want a good history or MORE IMPORTANT because you still work on this branch and will have to merge it in the parent branch.
To do that, you will have to reset your tfs remote (because in fact the commit has already been created --to keep compatibility with how git-tfs works in previous version and for those that can't work with branches--).
To reset your remote, you must use reset-remote command.
Then intitialized the branch that is merged in the parent branch with branch --init.
Reset also the local branch to the tfs remote (due to an internal git-tfs optimization).
And fetch again the parent branch. Now that the merged branch exist and is fetch, git-tfs will find the parent changeset from the merged branch and you will have a beautiful merge commit in your git repository ;)
So, If you did this earlier
git tfs clone https://CompanyName.visualstudio.com/DefaultCollection "$/CompanyName/Main" KfGitMain --workspace="C:\TFS\Main"
cd GitMain
git tfs branch --init "$/CompanyName/Release/20140121.1" live20140121.1
git tfs branch --init "$/CompanyName/Release/20140121.1-hotfix" hotfix20140121.1
and if you received the warning for all the three due to code merges to and from each other, so you will have to
git checkout hotfix
git tfs reset-remote 5fb83335b8dfc6fbb96e0a54a48dc06c506e3277 ## previous commit of the first failed commit
git reset --hard tfs/hotfix
git tfs pull -i hotfix
git checkout live
git tfs reset-remote eba62a1446f3f81676d051336ca254fe54c37d74
git reset --hard tfs/live
git tfs pull -i live
git checkout master
git tfs reset-remote 72727737ec52f9b96d22d343770186a342c8b166
git reset --hard tfs/default
git tfs pull -i default
Note: if you don't have too many branches and/or strange tfs history, all that could be avoided using git clone with the option --with-branches that will init and fetch all the branches taking care of the merge changesets
In phpstorm how do you do a git pull --rebase? I can't seem to find an option to do it. I would like this to be the default behavior as we are all working off the same branch.
I am doing the pull by Version Control > Git > Pull Changes....
Just use the Version Control -> Update Project action.
There you may choose the way of update: via merge (git pull) or via rebase (git pull --rebase) or via the default way for the current branch (it is merge by default).
The action also has more capabilities than Pull: it stashes/slelves your uncommitted changes if you have them, and restores them after update.