You have to actively choose to install MSYS to get the make.exe. So you should always have at least (the native) mingw32-make.exe if MinGW was installed properly. And if you installed MSYS you will have make.exe (in the MSYS subfolder probably).

Note that many projects require first creating a makefile (e.g. using a configure script or automake .am file) and it is this step that requires MSYS or cygwin. Makes you wonder why they bothered to distribute the native make at all.

Once you have the makefile, it is unclear if the native executable requires a different path separator than the MSYS make (forward slashes vs backward slashes). Any autogenerated makefile is likely to have unix-style paths, assuming the native make can handle those, the compiled output should be the same.

The main difference I came across is that mingw32-make will use windows PATH. So if you try to run it from git bash it won't behave quite like you expect it to (namely, it will invoke bat scripts when you don't expect it to, and shims also don't quite work).

Setting SHELL := /bin/bash or anything similar won't have any effect (which you can debug by running make -d), but you can still make it use bash instead of sh by setting SHELL := bash.exe. That's doesn't solve the windows PATH problem though.

What I did notice however is that if I additionally set .SHELLFLAGS := -euo pipefail -c then it suddenly behaves properly in git bash, as if it starts using Unix-like paths (would be great if someone could confirm / explain why exactly).

So I ended up with the following in my Makefile:

ifeq ($(OS),Windows_NT)
    SHELL := bash.exe
else
    SHELL := /usr/bin/env bash
endif
.SHELLFLAGS := -eo pipefail -c

With that setup it appears to behave normally in git bash, just like on Linux.