1

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?

Joseph
  • 502
  • 4
  • 15
  • Steps 2+3+4+5 can be combined in one efficient command: `git pull origin P:P` , See https://stackoverflow.com/a/53859568/7976758 for more details. The rest is perfectly normal and standard workflow. – phd Feb 17 '22 at 00:13
  • This is one of the philosophical questions that there's no right or wrong way of doing it; it's more of how comfortable you're doing it. For me, I'd personally finish off the work and raise a Pull Request, then deal with merge conflicts as and when they happen. Normally I'd do `git fetch; git rebase origin/develop` and fix the conflicts. Most people I work with aren't comfortable doing it and avoid it by 3-way merge. – Prav Feb 17 '22 at 00:19
  • @phd - I am unable to do that command since I am having a permission denied error: error: cannot update the ref 'refs/heads/parent': unable to append to '.git/logs/refs/heads/parent': Permission denied – Joseph Feb 17 '22 at 00:57
  • 1
    A "permission denied" error in your *local repository* means you have some sort of permissions setup error on your local computer. You should own and have access to all of these files, in general: that's why you're using Git in the first place, so that you don't have to use someone else's computer and get permission and so on. (Otherwise you'd use some other VCS that is easier to use.) – torek Feb 17 '22 at 03:33
  • @torek I'm curious what you're thinking of for "some other VCS that is easier to use"? Wild guess- Mercurial? – TTT Feb 17 '22 at 04:07
  • This is just personal preference, but I hardly ever stash anymore. In step 1, I would just commit with a message similar to "wip: half done thing". Then when I come back to the branch I would just amend that commit with the improvement and change the commit message. I also am an advocate of never checking out `P`, which would land at [Andreas Louv's answer](https://stackoverflow.com/a/71150917/184546). Similarly, last week I wrote [an answer](https://stackoverflow.com/a/71057049/184546) which described in detail how this would work. – TTT Feb 17 '22 at 04:22
  • 1
    @TTT: Most of them? :-) Mercurial is pretty much as capable as Git but does have the distributed property, which makes things a bit confusing. But overall it's way more newbie friendly. It's a bit sad that it lost the popularity war. – torek Feb 17 '22 at 06:14

2 Answers2

1

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
Andreas Louv
  • 46,145
  • 13
  • 104
  • 123
  • I think OP wants the rebase other way around from the sound of it. He/she's not able to merge a feature to `dev/develop` because it has conflicts. – Prav Feb 17 '22 at 00:22
  • the problem that I had with fetch and merge is that I sometime face an 'unlink' problem and instead, the changes from the remote commits become unstaged. but will try the rebase too. – Joseph Feb 17 '22 at 00:24
  • 1
    Presumably `origin/P` is not getting re-written, so the last rebase command could probably be simplified to just `git rebase origin/P`. – TTT Feb 17 '22 at 04:10
0

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
Xab Ion
  • 1,105
  • 1
  • 11
  • 20