3 ms·

Generally, it's the responsibility of whoever made the changes to resolve conflicts (basically, git blame conflicting lines and the people who changed them get

Generally, it's the responsibility of whoever made the changes to resolve conflicts (basically, git blame conflicting lines and the people who changed them get notified to resolve conflicts in that file). Distributing the work like this makes the merges more reasonable.

tokenizerrr 9y ago
How does that work?
- srathi 9y ago
  You first rebase against the master locally and push the merged feature branch after resolving all the conflicts yourself. Afterwards, you go to the master and merge it against the updated feature branch. The 2nd merge should not result in any conflicts.
  - nerdponx 9y ago
    This model can be annoying on running feature branches. Once you rebase, you have to force-push to the remote feature branch. It's not so bad if you use --force-with-lease to prevent blowing away work on the remote, but it still means a lot of rewriting history on anything other than one-off branches.
    - cryptonector 9y ago
      No no, you never force push to "published" branches, e.g., upstream master. What you're doing when you rebase onto the latest upstream is this: you're making your local history the _same_ as the upstream, plus your commits as the latest commits, which means if you push that, then you're NOT rewriting the upstream's history. (In the Sun model one does rewrite project branch history, but one also leaves behind tags, and downstream developers use the equivalent of git rebase --onto. But the true upstream never rewrites its history.)
      - nerdponx 9y ago
        That's what I thought as well. But what happens when you need to rebase the feature branch against master? Won't you have to force push that rebase?
        cormacrelf 9y ago
        There's nothing stopping you from doing merges instead of rebases. * latest feature commit #3 (feature) * merge /| * | more master commits you wanted to include (master) | * feature commit #2 | * merge |/| * | master commits you wanted to include | * feature commit #1 |/ * original master tip * master history... Then, when you're done with feature, if you really care about clean history, just rebase the entire history of the feature branch into one or more commits based on the latest from master. I think checkout -b newbranch; rebase --squash master does the trick here: * feature commits #1, #2 and #3 (newbranch) | * latest feature commit (feature) | * merge |/| * | more master commits you wanted to include (master) | * feature commit #2 | * merge |/| * | master commits you wanted to include | * feature commit #1 |/ * original master tip * master history... Then checkout master, rebase newbranch, test it out and if you're all good, delete or ignore the original. * feature commits #1, #2 and #3 (master, newbranch) * more master commits you wanted to include * master commits you wanted to include * original master tip * master history...
        eihakker 9y ago
        *latest feature c *merge /| * |more master comm. | feature commit #: | merge |/| * |master commits y | feature commit # |/ original master * master history ..
        cormacrelf 9y ago
        maybe try that again keeping 4 spaces before each line?
        cryptonector 9y ago
joeld42 9y ago
Yep, this is the way I work. Always rebase against master, and fix conflicts there, so branches merging into master should always be up-to-date and have zero conflicts.

tokenizerrr 9y ago

How does that work?

srathi 9y ago
You first rebase against the master locally and push the merged feature branch after resolving all the conflicts yourself. Afterwards, you go to the master and merge it against the updated feature branch. The 2nd merge should not result in any conflicts.
- nerdponx 9y ago
  This model can be annoying on running feature branches. Once you rebase, you have to force-push to the remote feature branch. It's not so bad if you use --force-with-lease to prevent blowing away work on the remote, but it still means a lot of rewriting history on anything other than one-off branches.
  - cryptonector 9y ago
    No no, you never force push to "published" branches, e.g., upstream master. What you're doing when you rebase onto the latest upstream is this: you're making your local history the _same_ as the upstream, plus your commits as the latest commits, which means if you push that, then you're NOT rewriting the upstream's history. (In the Sun model one does rewrite project branch history, but one also leaves behind tags, and downstream developers use the equivalent of git rebase --onto. But the true upstream never rewrites its history.)
    - nerdponx 9y ago
      That's what I thought as well. But what happens when you need to rebase the feature branch against master? Won't you have to force push that rebase?
      - cormacrelf 9y ago
        There's nothing stopping you from doing merges instead of rebases. * latest feature commit #3 (feature) * merge /| * | more master commits you wanted to include (master) | * feature commit #2 | * merge |/| * | master commits you wanted to include | * feature commit #1 |/ * original master tip * master history... Then, when you're done with feature, if you really care about clean history, just rebase the entire history of the feature branch into one or more commits based on the latest from master. I think checkout -b newbranch; rebase --squash master does the trick here: * feature commits #1, #2 and #3 (newbranch) | * latest feature commit (feature) | * merge |/| * | more master commits you wanted to include (master) | * feature commit #2 | * merge |/| * | master commits you wanted to include | * feature commit #1 |/ * original master tip * master history... Then checkout master, rebase newbranch, test it out and if you're all good, delete or ignore the original. * feature commits #1, #2 and #3 (master, newbranch) * more master commits you wanted to include * master commits you wanted to include * original master tip * master history...
        eihakker 9y ago
        *latest feature c *merge /| * |more master comm. | feature commit #: | merge |/| * |master commits y | feature commit # |/ original master * master history ..
        cormacrelf 9y ago
        maybe try that again keeping 4 spaces before each line?
      - cryptonector 9y ago

joeld42 9y ago

Yep, this is the way I work. Always rebase against master, and fix conflicts there, so branches merging into master should always be up-to-date and have zero conflicts.