As I understand it, your situation is this:
- you have a feature branch with some commits we'll call X, Y, Z
- you have a master branch where the history shows those commits in between other commits, e.g. A, B, C, X, Y, Z, D, E, F
- the actual changes in X, Y, Z weren't applied, and now you want to apply those changes
The bad news is, as you've found, that a plain "git merge" will just tell you that everything on your feature branch is already on master.
The good news is that it should be fairly straight-forward to create a new feature branch, with all the changes, but as new commits. Then when you merge to master, it will merge the changes in as you expect.
The way to do this is with git rebase
, which takes a series of commits and re-creates them with a new parent. The argument you need to pass to git rebase is the last commit before the changes you want to rebase; there are a few ways to specify it:
- Find the relevant commit hash in the logs
- Find the first commit hash you do want to keep, and add "^" which means "parent of", e.g. "abc123^"
- Count the commits you want to keep, and use "~" notation, e.g. "HEAD~3" means "go back 3 commits"
To confirm what's going to be rebased, use the "-i" (interactive) flag; that will pop up an editor: save and exit to go ahead, or delete all the lines shown to abort the rebase.
git rebase -i HEAD~3