There are many ways to do this, when it comes to what is "best" that is determined by what you want out of the scheme, and security/performance tradeoffs. Maybe don't focus on the best method, but rather eliminating bad ones.
If the keyfile is large, it should be derived into a smaller key of appropriate size, such as 256-bits. I will call the keyfile $F$ and its derived key $K_F$, if $F$ is already an appropriate size, they are equivalent. The password $P$ and its derived key $K_P$.
You can use both derived keys as part of the encryption process. This can be done in a layered process, such as encrypting the data with $K_F$ and then with $K_P$. I am not a fan of this method. XEX modes of encryption that use one key for the X steps and one for the E steps may be more effective.
You can use $K_F$ as part of the password key derivation process. In this method you can use $K_F$ as the salt input to PBKDF2, making it a pepper rather than a salt. You can also use Ella's method of master key generation by hashing the derived keys together, either by concatenation or by using one as an HMAC key on the other.
As Luis says, what you do not want is a method that allows a single key to be easily recovered from the final master key if this and another derived key is known to the attacker. Say for example the attacker knows your password, and through some trickery was able to get the encryption key, they should not be able to recover $K_F$ through less than brute force. This may not seem important, as they already have the encryption key, but the more key material that remains secret the better, especially if you used the keyfile for something else. This means do not XOR the derived keys together to generate the master key.
The same rule applies to the password, if the keyfile is known, the workload on the password key derivation should not be decreased. This means not applying PBKDF2 to the keyfile, and then hashing that result with the password. The full password derivation process needs to be required to get the master key.
Whatever method you choose, you may want to change the password, or even the keyfile, at some future point in time. If you encrypt the data with the master key, you need to decrypt that data to change the password, and if you have gigabytes of data, this is a huge performance and time concern. The better method is to create a random data encryption key $K_D$, encrypt with that, then use the master derived key to encrypt that key. Now a password change only takes a fraction of a second longer than the key derivation process. It also means you get a true random key for your data encryption key, and you can use different keys for different pieces of data.
Combining that with the derivation process, we get something like this:
$K_F$ = SHA256($F$)
$K_P$ = PBKDF2($P$)
$K_M$ = SHA256($K_F$ || $K_P$)
$K_D$ = secure random 256-bits
$Dat_E$ = $E_{K_D}$(Data)
$Key_E$ = $E_{K_M}$($K_D$)
Now you store $Dat_E$ and $Key_E$, and use the keyfile and password to recover the data or to change the password.
For the keyfile, you can also do things to mess up attackers, like have 256 actual keyfiles on the flash drive, and choose 8 different files to derive $K_F$. This adds up to $2^{48}$ complexity to the derivation process, as there are more than 400 trillion different combinations to choose from. The files can be labeled 00.dat to FF.dat for example, and you need to choose the correct combo, such as FE 25 B6 A1 C8 D4 E9 0C. Think of it as a second password, but you would need to remember it. The software could even be programmed to display a dummy file if a specific combination of keyfiles is chosen, if you are worried about being forced to decode the data.