I am currently working on a second branch called NC12-changePassword.
There have been changes made to master branch which handle decrypting of a string. I required these new changes to be able to implement a new feature on my branch so I merged the changes.
I did a git pull and there were no conflicts. When I run git log it shows the merge commit. Also when I run git merge master it tells me everything is up to date.
However my code is not working and when I run git diff NC12-changePassword master it lists what's in master that isn't in NC12-changePassword. This doesn't make sense to me because I have merged the changes and therefore the everything that is in master should be in NC12-changePassword.
My understanding is that my branch should function like master and the code should work fine. Or am I missing something :-\ .
and therefore the everything that is in master should be in NC12-changePassword
That's not what "merge" means, and therefore not what git merge does.
Let's take a very simple example for illustration. Suppose you made a branch off master and, as part or even all of that branch, you deleted a block of code and committed the result.
Then, after you've done that, suppose Fred modifies master to add a second block of code—perhaps in a different file entirely—that only does something useful if the first block of code exists. He commits that to master.
Later, you obtain Fred's work in master and use git merge to bring his-changes-to-master into your branch. Git will not put back the code you deleted: it assumes you knew what you were doing then. All it will do is discover that Fred added a new block of code, and it will add that same block to your branch, where it does nothing because it depends on the block you deleted.
If you now compare your branch to Fred's master, you will still have a deleted block of code: the block you deleted. You won't have everything that's in that master. (Your own master will probably not have Fred's changes either, because in the above, we've never mentioned you getting on to your master and bringing in his changes from his master.)
In complicated situations, you must use your own knowledge (which will always exceed git's) to fix up merges that are semantically incorrect. Git will, at most, notice syntactic collisions, things like: "hey, you deleted this block of code, but Fred made a change to that same block, so since I, git, know nothing of semantics, you will have to resolve this conflict". But this happens only if you are lucky enough to have a syntactic conflict. If Fred's changes "fit in" despite your changes, but do nothing because of your changes, git won't even notice that.