I have been doing this way of getting latest code from Git for years now and I wanted to ask if this is really the correct way of doing it since in this way, I prevent merge conflicts when opening a pull request later on.

P-Parent branch (where other devs create their pull request)
W-working branch (branched from P)

1. stash changes in W
2. Checkout P
3. Pull P to get latest commits from remote
4. Checkout W
5. Merge P to W
6. Push incoming commits to W remote
7. Pop stash and continue working
8. Stage changes once done then Commit
9. Push to remote W
10. Send pull request to P and once approved, merge

Is there anyone here doing the same thing or are there other ways of doing it?

CodePudding user response：

Instead of checking out P, pulling (fetching and merging or rebasing) just to checkout W and merge P you can fetch and merge the remote P, usual origin/P

$ git branch --show-current
W
$ git fetch
[...]
$ git merge origin/P

I like the rebase strategy, so I would rebase onto P instead of merging it into W.

$ git branch --show-current
W
$ git fetch
[...]
$ git rebase --onto origin/P HEAD~what_ever

CodePudding user response：

I usually follow the following steps to resolve the merge conflicts:

First, I will be in the latest master branch:

git pull && git pull origin master_branch(dev, master)

And then checkout to working branch

git checkout working_branch

and

git merge master_branch 

While merging master_branch, If you have merge conflicts you can resolve the merge conflicts on code and then git add/commit/push to the working branch.

git add/commit/push working_branch