This really fails to understand the concept behind feature branches. The idea is NOT that a feature branch should go off by itself for 2 weeks at a time with no interaction, but rather than each developer should have their own control over when their code will not negatively impact others and when their code is in a state they can accept stable code from others.
In a well functioning feature branch flow, developers should be regularly pushing whenever their code is reasonably stable for the mainline branch they are working off of. Similarly, they should be pulling in changes from the mainline branch as often as possible to avoid long running conflicts developing.
What this means is that developers still get changes in a timely manner, but are exposed to significantly less thrash at inconvenient times. It does require developers to be responsible with understanding when their code is "stable enough" and to balance the risk of drift with the risk of both causing and receiving turbulence, but the alternative is to have things occur basically at random.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This really fails to understand the concept behind feature branches. The idea is NOT that a feature branch should go off by itself for 2 weeks at a time with no interaction, but rather than each developer should have their own control over when their code will not negatively impact others and when their code is in a state they can accept stable code from others.
In a well functioning feature branch flow, developers should be regularly pushing whenever their code is reasonably stable for the mainline branch they are working off of. Similarly, they should be pulling in changes from the mainline branch as often as possible to avoid long running conflicts developing.
What this means is that developers still get changes in a timely manner, but are exposed to significantly less thrash at inconvenient times. It does require developers to be responsible with understanding when their code is "stable enough" and to balance the risk of drift with the risk of both causing and receiving turbulence, but the alternative is to have things occur basically at random.