Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Merge Conflict Resolution

Merge Conflict Resolution

Git Branching, Merging, and Conflict Resolution.

Luke Stringer

January 08, 2015
Tweet

More Decks by Luke Stringer

Other Decks in Programming

Transcript

  1. $ git checkout master Switched to branch ‘master' $ git

    checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' [hotfix 1fb7853] fixed the broken email address 1 file changed, 2 insertions(+)
  2. $ git checkout master $ git merge hotfix Updating f42c576..3a0874c

    Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)
  3. $ git branch -d hotfix Deleted branch hotfix (3a0874c). $

    git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' [iss53 ad82d7a] finished the new footer [issue 53] 1 file changed, 1 insertion(+)
  4. $ git checkout master Switched to branch 'master' $ git

    merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)
  5. • An “edit collision” is the most common merge conflict.

    • It happens when two branches have changed the same part of the same file, and then those branches are merged together. • Git has trouble understanding which change should be used, so it asks you to help out.
  6. • When this sort of conflict occurs, Git writes a

    special block into the file that contains the contents of both versions where the conflict occurred. <<<<<<< HEAD:index.html <div id="footer">contact : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html • The top part (everything above the =======) is the version in HEAD, the branch being merging into (the master branch in our example). • The top part (everything below the =======) is the version in the iss53 branch
  7. • In order to resolve the conflict, you have to

    either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: <div id="footer"> please contact us at [email protected] </div> • This resolution has a little of each section, and the <<<<<<<, =======, and >>>>>>> lines have been completely removed. • After you’ve resolved each of these sections stage the file to mark it as resolved.
  8. #! /usr/bin/env ruby def hello puts 'hello mundo' end hello()

    $ git checkout -b spanish Switched to a new branch 'spanish'
  9. #! /usr/bin/env ruby def hello puts 'hello mundo' end hello()

    $ git checkout -b spanish Switched to a new branch 'spanish' $ git commit -am 'Translated 'world' into Spanish’ [spanish 6d338d2] Translated 'world' into Spanish 1 file changed, 1 insertion(+), 1 deletion(-)
  10. #! /usr/bin/env ruby def hello puts 'hello to all the

    world' end hello() $ git checkout -b master Switched to a new branch 'master'
  11. #! /usr/bin/env ruby def hello puts 'hello to all the

    world' end hello() $ git checkout -b master Switched to a new branch 'master' $ git commit -am 'Elaborated the greeting message’ [master 239e5b4] Elaborated the greeting message 1 file changed, 1 insertion(+), 1 deletion(-)
  12. #! /usr/bin/env ruby def hello <<<<<<< HEAD puts 'hello to

    all the world' ======= puts 'hello mundo' >>>>>>> spanish end hello()
  13. Before attempting a merge • Your working directory should be

    clean before attempting a merge. If you have work in progress, either commit it to a temporary branch or stash it. • This allows you to undo anything you try during the conflict resolution. • If you have unsaved changes in your working directory when you try a merge, getting back to a buildable, working code base isn’t as easy.
  14. • Auto-generated project files that are not designed to be

    human readable. (.pbxproj, .sln, .storyboard) • Situations where a file has lots of complicated conflicts. • Multiple lines where both branches have made changes.
  15. Strategy • Choose the version of the file in the

    branch being merged into (master in this example). • Then manually add the changes in branch being merged in (project-changes in the example). • Typically you know more about the branch being merged in than the branch being merged into.
  16. • ‘Mine’ is the branch being merged into; master. •

    ‘Theirs’ is the branch being merged in from master’s perspective. • Note, if you are merging in your own branch, ‘Mine’ does not mean ‘my branch’.
  17. • Reapply the changes that were implemented in the branch

    being merged in. • Make sure it builds. • Make sure it runs. • Make sure the tests pass. • (If you have them. You do have them right?) • If possible the 2 (or more) developers of each branch should work together to ensure everything works.
  18. • Merge conflicts are unavoidable. • However, smaller more frequent

    conflicts are better and easier to deal with than large conflicts. • Conflicts become more troublesome as branches become more divergent. • In git-flow, a feature branch can become divergent from develop. • eg. new commits on develop after the feature branch was created.
  19. • Look out for new commits on develop. • Notice

    the down-arrow indicating commits to pull from the remote. • Periodically merge develop into your feature branch. • Conflicts will be smaller when compared to leaving the feature to become divergent and then merging into develop.