You should work from a throw-away branch. Just merge the two branches. Continue making some commits on this throw-away branch. When both PRs are in master you just cherry-pick your commits on a fresh branch from master.
If you had to say one way which was 'standard' branching model for git it would be gitflow.
Many people find its not for them, but don't try to invent a new model until you've tried it.
Rebasing is bad, it deletes your commits and screws over anyone else using the branch. Never rebase. Especially never rebase if the only thing you don't like about merging ...
Install Git on the Linux VM and commit directly from there. Of course, your Linux VM must be able to connect to the central repo, but as you can read here, it is perfectly possible to use SSH for this. The server where the repo is located must provide an SSH access for this, of course.
If that is not possible for some reason, there is also the option of ...
Here is good branching strategy.
Use central repository and every new feature/bug fix should be in a new branch.
Other members can checkout branch they want to test. After they tested you can merge that branch in master or sprint or whatever method you are using.
Always keep in mind, master should be ...
When you work in common files, in either way you or your teammates need to resolve all conflicts before merging finishes hence at the first place please don't be upset. You are still doing project work and be proud of your work. Now to make a smarter move, you can follow some suggestions below.
Divide tasks independently:
Before you start your work, plan ...
If your project is meant to be open source and it's addressed to the community, whether you like them or not, it's good to follow the "standards" or common practices adopted by the community for your specific stack.
Even if it's not OS, it's good to adopt them, especially if someone else has to work on it.
If you dislike the way the community organise ...
This question was asked a really long time ago, but saying as you didn't mark a solution, I think I'll add a contribution.
Basing of my experience with open source, you should consider a few things before setting up structure.
Things to consider
Language and Technology: Frameworks and languages dictate a lot of what your structure should look like. For ...
The purpose of pull merge request code reviews for my team is to reduce the blast radius of team members so they don't break everyone involved. Ideally they should be small, but there's generally enough trust on the team that as long as it works and you own up to any issues we usually do away with the reviews.
However, when a developer isn't sure about ...
Caveat: There is not really a good answer to your immediate question. The real issue is that you have an organisational/team bottleneck that is causing risk and potential rework.
Use team knowledge: Is there a local strategy for dealing with this in your organisation? Which of the other branches was created second and how did the author deal with this ...
I would see if the code is going public or not.
When projects stay private:
I would recommend to not squash and see the making of the sausage. If you use good and small commits, tools like git bisect are super handy and people can quickly pinpoint regression commits, and see why you did it (because of the commit message).
When projects go public:
I feel I should prefix my answer by saying that I'm not a fan of Git Flow - I think it overcomplicates things, and trunk based development is preferable.
That said, I think I can answer your specific question. Git Flow is described in
A successful Git branching model by Vincent Driessen.
Drissen provides instructions for Finishing a Hotfix branch, which ...