I am working on a Rails project!
Excuse for not adding .gitignore
I have accidentally committed and pushed 'database.yml' in to my feature branch. A pull request was created from the feature branch to master branch a few days ago and is not yet merged. There are multiple commits done as part of this pull request and the commit containing 'database.yml' is the fourth last commit.
Others are also working as part of this project and they are merging the changes to master and we are pulling those changes in to our feature branch in-between. Thus, in our feature branch, we have got commits from others which are done after the faulty commit.
so I wish to do a 'git rm' and 'git push' the same file again to resolve this issue (as the PR is not yet merged). Will that create problem?
If you remove the database.yml that will be another commit on top, and nobody will be affected.
Notice, however, that the database.yml will still be part of the history and can be accessed via git log. If that file contains sensitive information, it will be findable by others.
Delete the file from your local system then add the changes to a commit using
git add <FILE_PATH> command and then commit and push the changes and it should be fine.
The right way to remove it properly is to reverse the changes you made to the file and commit it.
Another, dirtier way, is to open the commit and remove the changes and force push it to the repo. But you need the proper rights for this. Others will also have problems if they try to pull changes then.
About a week ago, I was pushing my .gitignore file to my repository and was running into small issues with that, and finally figured it out, but noticed that all my storyboards were in the repository too. In a stroke of genius, I looked into getting them out of there and found out about the above git reset command and just put that into my terminal and patted myself on the back and life went on. I just realized today after installing some cocoapods that all my storyboards I spent weeks working on are gone and put two and two together. I've spent the last hour reading through the similar questions, but haven't found anything after reading for a while and am wondering if any other xcode users have run into the same issue and can help.
I should also add that I had only added the storyboards to the stage and hadn't committed them yet at the time of the reset, so today I was using the git reflog command in hopes that they were in the lost and found. I had read that the garbage collection doesn't happen for a month so I don't think (I hope) they're just gone
I downloaded the AWS SDK today and that's all the git reflog command seems to be showing at the moment. Do I need to roll back the git rest HEAD{} command further?
Thank you very much!
You note in a comment that you did a git stash
This is a crucial bit of information, which changes everything. Fortunately, it also makes recovering much easier. In particular it means that your missing files are not "dangling blobs" and do have their original names saved. (Note, by the way, that git stash means git stash save; I'll use the longer form below to distinguish it from other git stash commands.)
The simplest way to recover is to use git stash branch. Pick a new branch name, one that you do not yet have. For illustration I will use saveme, which is a terrible name and you should choose a better one.
git stash branch saveme
This will take your existing git stash, create a new branch using the commit that was current when you ran git stash save. It will then restore your index (staging area) to the way it was at the time you ran git stash save, and restore your work-tree to the way it was at the time you ran git stash save. You can now commit the index:
git commit -m 'save index as a commit'
and then commit the rest of the work-tree if there is anything else to commit:
git add --all
git commit -m 'save everything else as a commit too'
I will add, at the end of this answer (in another edit), a pictorial diagram of what happens with this entire sequence, starting from the first git adds and going through the git stash save and git reset --hard HEAD^ and on to the final git stash branch.
There is one caveat: your index and work-tree must be clean to use git stash branch. If you have uncommitted work, you probably should commit it now, or throw it all out with git reset --hard. Of course, either one has consequences:
If you run another git stash save, the earlier saved stash gets "pushed up" from stash#{0} to stash#{1}. You will then have to use:
git stash branch saveme stash#{1}
to convert that stash to a branch.
If you choose to use git reset --hard, you lose any uncommitted work you have, so be sure that this is OK.
Pictorial diagram
Let's take a look at a hypothetical terminal session, and see what happens with your commits and branches as you work.
$ cd my-git-project
At this point, you are in a Git work-tree. The work-tree is where your files are in their normal form, that the rest of the computer (and you) can work with, instead of their Git-only form, where Git saves every version of every file you or anyone else has ever committed. You are on some branch—let's say master, just for concreteness. This branch has some set of commits, ending in what Git calls the tip commit of that branch. The branch name remembers the hash ID of this tip commit:
...--F--G--H <-- master
Each uppercase letter represents a normal, ordinary commit. (In other words, these stand in for the incomprehensible hash IDs that are the actual names of each commit.) Commit H is the latest one. If your index / staging area and work-tree are "clean", the files in them match those in commit H.
Now you make some changes, and stage some or all of them:
$ ... edit some files ...
$ git add file1 file2 ...
The staging area, aka index, is now not "clean": it no longer matches commit H. Instead, it has copies of the edited and added files.
Your work-tree may or may not match your index. If it does match your index, and if you were to run git commit, Git would make a new commit out of your index (that's what the index / staging-area is for, mainly: to build the next commit), and then your index would match your commit and be clean. If your work-tree matches your index, that too would then be clean. This would look like:
...--F--G--H--I <-- master
where I is the new commit, made from your index.
Instead, though, you ran git stash save. What this does is make two commits, neither of which is on the branch:
...--F--G--H <-- master
|\
i-w <-- stash
The first (lowercase i) commit is the same commit that git commit would have made. It's just not on branch master; it's part of this two-commit "stash bag". The second commit, w, is peculiar: it looks to the rest of Git like a merge commit, but in fact it's just a commit of your work-tree state, even if that's the same as the index state in i.
After making these two stash-bag commits, git stash resets (cleans) your index and work-tree, a la git reset --hard HEAD. So now your index and work-tree match commit H again.
Next, you say you ran git reset --hard HEAD^. This does three things: it resets the index and work-tree state to the state of the selected commit, which is the one just before H; and it makes the name master point to the selected commit as well. So now your repository looks like this:
...--F--G <-- master
\
H [remembered in reflogs, *and* preserved via the stash]
|\
i-w <-- stash
Note that the stash-bag is still there, and still find-able by the name stash. The two stash-bag commits remember commit H by its hash ID. Meanwhile, the name master now remembers the hash ID for commit G instead—and your index and work-tree are "clean", i.e., match that for G.
If you now run git stash branch saveme, this is what Git does in terms of commits:
...--F--G <-- master
\
H <-- saveme
|\
i-w [abandoned]
The index is re-loaded from the i commit, and the work-tree is re-loaded from the w commit. If you now run git commit you get:
...--F--G <-- master
\
H--I <-- saveme
since Git saves the index as a new commit I. The work-tree remains unchanged; if it's clean with respect to I, it's now all clean, and if not, you can git add any remaining changes and commit them:
...--F--G <-- master
\
H--I--J <-- saveme
and now everything is saved permanently (or until you delete the saveme branch) in plain, ordinary commits that you can work with in the usual ways. Note that commit H, which you threw into the recycling bin with git reset --hard HEAD^, has come back on the new branch.
Original answer
I should also add that I had only added the storyboards to the stage and hadn't committed them yet at the time of the reset ...
This makes things harder, because:
... so today I was using the git reflog command
git reflog looks only at abandoned commits.
... in hopes that they were in the lost and found.
They may still be! The "lost and found" is separate from the reflogs.
I had read that the garbage collection doesn't happen for a month so I don't think (I hope) they're just gone
The 30-day grace period is specifically for commit objects that are remembered in reflogs, which these are not. However, all objects get a 14-day grace period. The clock starts at the time you git add the file to the staging area. (Even once the clock runs out, it takes a later git gc --auto to make the files go away, but it's hard to know when that will happen.)
Actually finding your files is a bit trickier. Run:
git fsck --lost-found
which, as the documentation says:
--lost-found
Write dangling objects into .git/lost-found/commit/ or
.git/lost-found/other/, depending on type. If the object is a blob,
the contents are written into the file, rather than its object
name.
Since you did git add these files, and they presumably never were in any commit, they will be "dangling" objects of type "blob". The git fsck command will print a bunch of incomprehensible hash names. You can then change into the .git/lost-found/other/ directory and examine all the files there, which all have these hash names. In amongst all these files, the contents you git added will appear.
For each such file, figure out whether it should be saved away under which sensible file name, and move the file out of the lost-found/other area to one of that name, and you have that file back.
I am doing git pull, It says
error: Your local changes to the following files would be overwritten by merge:
Gemfile
Please, commit your changes or stash them before you can merge.
Aborting
I don't remember doing any changes to gemfile.
On git status nothing is shown apart from all the files that I have removed.
How can I fix it. And How can I remove all the deleted files being shown while I do git status.
Please help.
For this scenario you have to use git stash refer this link (https://git-scm.com/book/no-nb/v1/Git-Tools-Stashing)
Removal of files is also a change from the previous commit, so commit your changes by using first git add(the files you have edited, not sure about removed) then then git commit. After that, take merge, or,
You can also write git checkout gemfile before taking merge, if you are sure that you haven't made any changes to it. This will restore gemfile to previous commit. Then take the merge.
I've made a stupid error which has messed up my database on a Rails App I'm working on. Luckily I'm on a branch and haven't committed any changes so the version on Git is in working order.
How do I now pull through the Git version and update to Sublime so I can carry on working as if nothing happened?
I've just done git pull origin master but it says up to date so I've obviously done something wrong.
I'm not keen on a db:drop so I'd rather do it this way if possible.
You can't pull again, because you already pulled every commit from your remote.
Add changes, stash them, remove the stash:
git add --all && git stash && git stash drop
This will remove every uncommited change and bring you back to the latest commit on the current branch.
git checkout 01h5y77d (find this in git, a version of the app which works)
This would print "HEAD is now at 01h5y77d..."
You don't have to commit because you did not commit the mistakes yet :)
So i am learning to ever so slowly use git to get me the latest update of RestKit as the old version has retain cycles...fair enough HOWEVER, when i pull using the gitHub Client it does not give me the AFNetworking files, which i was then told use the command
git submodule update --init --recursive
which i do, problem is that i noticed that after running that i run
git submodule status
It has taken me off the master branch and put the HEAD back in thus reverting me to old stuff. and hence back to leaks and stuff.
So i thought maybe i could install using cocoapods or perhaps put a submodule within the restkit submodule for AFNetworking...all did not seem to work and now i have followed this guide How do I remove a submodule? up until the last step as i dont know what committing will do? i hope it does not commit the fact that i deleted everything onto the restkit site? i am so confused, initially all i wanted to do was switch the current branch submodule i have to the master.
Assistance would be much appreciated.
EDIT:
Okay as to answer what Commit does, commit only affects your copy of the repository and will in no way affect the remote "main" repository everyone else gets their code from, so in essence i was able to commit it, then run a brand new submodule from the branch i wanted, But the question still remains Is there a way to switch the branch you pull your data from when using the update with --recursive?
Simply go in th e RestKit directory and type:
git pull origin master
(if you use the master branch of course)
Also, if you need to update all your submodules, just go to the root of your project, and type:
git submodule foreach git pull
git submodule update is confusing, here what it really does:
When you invoke git submodule update it looks in the parent repository for a SHA for each submodule, goes into those submodules, and checks out the corresponding SHAs.
As would be the case if you checked out a SHA in a regular repository, this puts the submodule into a detached HEAD state.
EDIT
To switch branch of a submodule simply, let say 'development', simply do in the submodule git checkout development and then you should be able to do git pull origin development