In January we created a release branch, named release_1.0 from master. After that, about 10 developers continued development in release_1.0 while supposedly making sure that every commit that made was also merged to master. Meanwhile another group of devs continued working on master on features for future releases. We released 1.0 in March. Right now, in April, we are getting ready to create a new release branch, release_2.0. Through testing we discovered that one 1.0 commit didn't get merged to master (the developer simply forgot to do it). We are now worried that other commits might not have been merged. Is there any way we can figure out if there are other such commits that haven't been merged?
Things I have tried: I tried merging the release_1.0 branch to master. There are no files that merge automatically. There are many, many reported conflicts. I have looked through the conflicts but until now I haven't found any hints that there is something that should be in master but is only in release_1.0. I also tried looking through all the release commits and see if they have been merged to master. They are about 200 hundred commits which doesn't sound like too much but they touch about 15-20 files each and every time I start looking into them I get lost after just 5 or 6 commits. A tool that could help with this would be great.
If commits were merged into master and there were no rebase in the release_1.0 after hand, the commits will have the same hash in both branches as they are the exact same ones.
What you could do is a git log on the release_1.0 branch and extract only the hash of the commits between the tip and the branching point from master. These are the commits that need to be present in the master branch. You can then do a git log on the master branch between the tip and the release_1.0 branching point and dump the result into a text file. Finally, do a text search of the previously extracted commit hashes from release_1.0 on the master branch log dump.