2

I've recently discovered on SO that the proper flow to push chances from a fork to the master repo is this:

  1. Create an issue branch on the fork

  2. Create Pull Request to merge this branch to the master the upstream

  3. Pull changes from the upstream into the fork master

  4. 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?

S.B
  • 13,077
  • 10
  • 22
  • 49
sandalone
  • 41,141
  • 63
  • 222
  • 338

2 Answers2

2

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):

  • Create a branch on the fork repository, pull it into your local working repository
  • Work locally on the branch
  • Do some commits on the branch
  • Pull the master-master to your local master (which is a trivial fast-forward, you never touched master)
  • Locally merge the 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.
  • Push your new master and branch to fork.
  • Create your PR of branchfrom fork-repos to master-repos, which now, by definition, is also conflict-free (until someone else modifies master-master again).
AnoE
  • 8,048
  • 1
  • 21
  • 36
0

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250