Reputation: 41749
I've recently discovered on SO that the proper flow to push chances from a fork to the master repo is this:
Create an issue branch on the fork
Create Pull Request to merge this branch to the master the upstream
Pull changes from the upstream into the fork master
Push changes from the fork master to the remote fork master
And it all works fine, but I am not sure what to do when I meet a merge conflicts.
Namely, I created 3 branches for 3 issues and finished them. I pushed branches to the remote fork repo and I am ready to create PR. I create PR for BranchA, but it says "it cannot automatically merge as I have to resolve conflicts".
Resolving includes that I merge this branch to the fork master first, resolve conflicts, then push merged changes to the upstream master repo.
Haven't I just broken 4-step rule I mentioned above?
Is there a way NOT to merge anything on fork master but to resolve conflicts inside the branch and push fixed branch to the upstream via PR?
Upvotes: 2
Views: 3286
Reputation: 8345
I've recently discovered on SO that the proper flow to push chances from a fork to the master repo is this:
There is no "proper" flow with git. Git is workflow-agnostic and does not come with a prescribed work order. You have to understand what it does and adapt it to your needs.
The 4 points you describe seem outright wrong to me.
A working procedure is, in more detail (branches are like so
):
branch
on the fork repository, pull it into your local working repositorybranch
branch
master
to your local master
(which is a trivial fast-forward, you never touched master
) master
to the branch
(or, if you are working on branch
all by yourself, better yet, do a rebase). This is where manual conflict resolution occurs.master
and branch
to fork.branch
from fork-repos to master-repos, which now, by definition, is also conflict-free (until someone else modifies master-master
again).Upvotes: 3
Reputation: 1323973
Resolving includes that I merge this branch to the fork master first, resolve conflicts, then push merged changes to the upstream master repo.
No: you need to fetch from upstream, and rebase your PR branch on top of it, making sure your branch applies without conflicts. That is what step 3 should look like (unless the upstream branch changes too often, in which case, a simple merge is enough instead of a rebase)
Then you force push your branch to your fork. It will be eligible to be merge to the upstream repo.
As I describe in "Maintaining a branch that syncing with upstream", you can configure your local branch to automatically pull --rebase
from the upstream repo, and push to your local fork.
Upvotes: 0