chadedgar
chadedgar

Reputation: 131

Get rid of several bad commits

I have repo where I don't track .gitignore, someone committed node_modules folder and later we decided to untrack it. Now same person(new to git) committed '.gitignore' for few commits before untracking it again. Now we have situation where if we checkout old commits, it deletes several files from repo that were not tracked and it also creates situation where 'vs code' slows down due to thousands of untracked files. What's the best way to handle this situation? I think I will need to squash those commits and keep them on seperate branch so no one checks it out accidentally. Do I have any other options?

As things happened,

.gitignore was never tracked
node_modules were tracked
.gitignore was tracked
node_modules was untracked
.gitingore was untracked

Upvotes: 1

Views: 128

Answers (1)

Marek R
Marek R

Reputation: 38092

Form what you have described top of master is fixed and problem is only is someone checks out old version of code where stuff are broken.

There is no easy way to fix it. For that you need rewrite whole history and make sure that all copies of repository are updated with new history. This is organization nightmare you will always miss one repo which will be pushed back to main repository and you will come back to initial state. So do not try that.

The only reasonable solution is address scenario when someone checks out old version of code. If this is some branch, like: release-1.x.x then just cherry pick a commit which fixes this issue to that branch.

If developers have to checkout code to specific version/commit, they have to live with this problem as long this version of code needs some maintenance.

Important is to learn some lesson from this kind of problems:

  • always create and check in .gitignore to repository when only you start new project.
  • git hooks are a bit harder to configure, but are great solution to protect repo from unwanted corruptions
    • note there are tools github/gitlab/bitbucket/... which allows you to configure pull requests and configure git hooks to protect specific branches. Passing pull request code review is great way to protect you from unexpected (not covered by .gitignore and git hooks) bad changes
  • when intern is joining a project make sure his git skills are at least a basic and he understands what should be tracked by repository and what should not be tracked.

Upvotes: 1

Related Questions