git恢复master中已删除的文件，保持功能正常运行

Question

While working in a local 'myfeature' branch, I deleted some files and committed them locally. Along the way, those commits were then merged with remote origin/master. I needed to get those deleted files back, so I did a git pull for the latest on master and cut a 'hotfix' branch where I:

git revert <commit id>

in reverse chronological order of those bad commits and got those deleted files back. I'm basing on the git-flow branching model so correct me if I'm wrong, I should now merge the 'hotfix' into master, as well as any 'release' branches, develop, and any other 'feature' branches?

Do I need to do anything to my currently still in-progress 'myfeature' branch where I want to keep those said files deleted? Will those files stay deleted once I merge 'myfeature' or will those files resurrect when I merge?

I'm not using git-flow, just the model.

Answer 1

About getting back deleted files :

If your history looks like this :

* aa1234 last commit
* bb2345 commit
* cc3456 commit
* dd4567 deleted fileC dirD/fileD & made other changes
* ee5678 deleted filA  dirB/fileB & made other changes
* ff6789 commit

and you want to get back file A,B,C,D as they were when you deleted them, you can check them out one by one, using git checkout <hash> -- <path/to/file> :

git checkout ee5678 -- fileA
git checkout ee5678 -- dirB/fileB
git checkout dd4567 -- fileC dirD/fileD

That way, you keep your other modifications safe.

About the flow : I didn't quite get which flow you are using, but if you create a commit whose action is to recreate the files you have deleted, then yes, merging this commit in other branches will apply the same action.

Answer 2

If you revert commits then yes, all changes of that commit are reverted, but other than that nothing else. So if you bad changes are isolated within commits, you can simply revert those while leaving the good commits in place.

If you however have commits where good and bad actions are mixed, then you would also lose those good actions when reverting them like that, so I'd suggest you not to do that.

Instead you should do partial reverts. In general you have more control over the reverts, when doing them with the -n flag. That way Git won't create a reverting commit for you and you can manipulate the changes first and then commit it yourself. In addition this allows you to make multiple reverts at once. So ideally when there are multiple commits that together introduced a change you no longer want, you can revert them all in a single commit to fix it.