Tried to fix .gitignore on dev; reluctant to merge into master

I was having a problem with files in my .gitignore still being tracked on my dev server.
Did some Google searches and did the following:
git rm -r --cached .
git add .
git commit -m “fixing .gitignore”
and then I did a git push
I usually push from my dev server, open a pull request from github.com, review the changes, merge, and pull master down on my production server.
After performing the above, it now shows that over 4,150 files are changed and I see many that were in .gitignore and deleted on dev but not in master, so merging would delete them in master. There are also some subtle differences between them that would be nightmare to try and fix after merging and pulling.
(a) Can I revert dev back to what it was before I ran the above command?
(b) I have 2 commits - the .ignore “fix” and another small change, which I don’t care about - can I jump back to before those 2 commits occurred? Or is wiping the local index beyond the point of no return?
(c) It’s been a while - but - I’m thinking that simply creating a new branch from Master and working from it on the dev server would be the smartest move. I, in no way, want the Master branch to be affected by what I did.
Thoughts?
Thanks in advance.

git rm -r basically is “delete everything”, --cached means the change was applied only to the index, not your working tree. So it’s no surprise everything shows as deleted. That command would have worked right if you had applied it only to the files you want to stop tracking, not the whole directory (.). :wink:

Yes. Check git log to get the commit ID before the mess, and use either git reset COMMIT_ID to reset your current branch to that state, or git checkout -b new-branch COMMIT_ID to start a new branch from that commit. The second option would make it a little easier to cherry-pick any changes you made after the mistake and want to keep.

Awesome. Thanks for the info! Question - if I pushed the commit, what process would I take to remove it? Or, will reverting back to a good, known reset remove that?

1 Like

git reset is a local action, it’ll only change your local repository. If you want to push it you’ll have to “force-push” because you’ve now trying to push a history that doesn’t include the last commit in the remote repository. git push refuses to delete remote commits by default. The --force option overrides that check, so please double check to make sure you don’t loose anything you want to keep. :warning:

If you have any branch protection rules on the remote target branch you’ll have to (temporarily) disable them to be able to force-push.

THANK YOU! You’re a lifesaver. I appreciate your time and information. The git log, git reset, and git push --force solved my problem 100%.

1 Like