How does a miner put his vote for certain BIP?

See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.

As for the actual mechanism used to signal, a number have been used in the past:

Time based: BIP16, BIP30

Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.

Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's scriptSig field, which is otherwise free for miners to put anything in.

Block-version signalling: BIP34, BIP65, BIP66

A later generation of softforks used the block header's nVersion field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).

Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number of higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.

Versionbits-based signalling: BIP68/112/113, BIP141/143/144, BIP91, BIP341/342

The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, BIP9. It specifies using one specific bit of the block header's nVersion field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.

Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.

The taproot extension is currently expected to activate around mid-November 2021. BIP341/342 use a modified versionbits-based activation mechanism with lower activation threshold, and minimum activation height, in what has been called the "speedy trial" approach.

The future?

Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).

For 100 blocks, a miner will include its yes or no, number of votes is proportional to the percentage of the hashing power of the network. If you have 20%, you’ll likely be able to vote approx 20 times. Developers make a proposal and miners vote on it. If the majority vote yes, the miners implement the code. Majority in this case is when over 55% of the miners vote for a specific change.

BIPs and this kind of infrastructure for cryptocurrencies in general, has sparked some interesting debates within the community. Some developers fear miners will vote based on vested interest rather than the good of the network.

Additionally there is a growing fear in the community towards the concentration of hashpower (which translates into voting power) as mining pools and big scale mining operations continue to grow. This system is still relatively new, so it will be interesting to see how BIPs progress and ultimately how they affect the development of other cryptos as a result of its successes and failures.