Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
A merge request isn't a git thing; It is an extension of some platforms. If you continue developing on the same branch as the mergerequest was issued for, github and gitlab will list your commits within the Merge Request once you have pushed them to your remote.
If you do not want this, you can simply branch off after issuing your merge request.
ok, so a "merge request" can be viewed as "merge of branch1 into master will happen at a time I cannot control".
Now, branch1 is checked out, if I do git switch -c branch2, it will start a new branch2 based on the last commit from branch1, right? I feel it's safer, since I don't know when branch1 will merge, server-side.
Exactly.
Depending on the upstream guidelines (check for a CONTRIBUTION file) you may open a MR with your initial development efforts. And reuse the branch until you have finished the feature. Then you request a review.
Or you may first mention your branch on a issue and only create the merge request once the entire feature is developed.
If you are developing another feature, use a dedicated branch.
In any case, the author merging may elect only specific portions of your change.
Also note that it is perfectly normal that a merge request will be open for months. So don't be discouraged. There may already be people profiting from your change. You just don't see it.
I think that you can add a WIP prefix to the MR title to prevent the maintainers from accidentally merging the branch prematurely.
If you have zero idea when but you assume it will be merged at some point, I think you've got the right idea.
Do you know the merge strategy of the remote? Is it fast forward only, merge commit, squash then merge commit?