Merge Conflict Resolution

Git Branching, Merging, and Conflict Resolution.

Transcript

1. Merge Conflict
   Resolution
   And other fun stuff
   

   View Slide

2. • Never work with other people
   • Never branch
   • kthxbai
   

   View Slide

3. Branching & Merging
   

   View Slide

4. View Slide

5. $ git checkout -b iss53
   Switched to a new branch "iss53"
   

   View Slide

6. $ vim index.html
   $ git commit -a -m 'added a new footer [issue 53]'
   

   View Slide

7. $ 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(+)
   

   View Slide

8. $ git checkout master
   $ git merge hotfix
   Updating f42c576..3a0874c
   Fast-forward
   index.html | 2 ++
   1 file changed, 2 insertions(+)
   

   View Slide

9. $ 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(+)
   

   View Slide

10. $ git checkout master
    Switched to branch 'master'
    $ git merge iss53
    Merge made by the 'recursive' strategy.
    index.html | 1 +
    1 file changed, 1 insertion(+)
    

    View Slide

11. Merge Conflicts
    

    View Slide

12. • 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.
    

    View Slide

13. View Slide

14. • 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
    contact : email.support@github.com
    =======
    
    please contact us at support@github.com
    
    >>>>>>> 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
    

    View Slide

15. • 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:
    
    please contact us at email.support@github.com
    
    • 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.
    

    View Slide

16. Worked Example With
    SourceTree
    

    View Slide

17. #! /usr/bin/env ruby
    def hello
    puts 'hello world'
    end
    hello()
    

    View Slide

18. $ git checkout -b spanish
    Switched to a new branch 'spanish'
    

    View Slide

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

    View Slide

20. #! /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(-)
    

    View Slide

21. $ git checkout -b master
    Switched to a new branch 'master'
    

    View Slide

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

    View Slide

23. #! /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(-)
    

    View Slide

24. View Slide

25. View Slide

26. View Slide

27. View Slide

28. View Slide

29. View Slide

30. #! /usr/bin/env ruby
    def hello
    <<<<<<< HEAD
    puts 'hello to all the world'
    =======
    puts 'hello mundo'
    >>>>>>> spanish
    end
    hello()
    

    View Slide

31. View Slide

32. View Slide

33. View Slide

34. View Slide

35. View Slide

36. If necessary you can restart the merge
    

    View Slide

37. View Slide

38. View Slide

39. View Slide

40. View Slide

41. View Slide

42. View Slide

43. To stop backup files during merge:
    git config --global mergetool.keepBackup false
    

    View Slide

44. View Slide

45. View Slide

46. 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.
    

    View Slide

47. Also, set your diff and merge tools in SourceTree
    

    View Slide

48. Difficult merges
    

    View Slide

49. • 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.
    

    View Slide

50. 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.
    

    View Slide

51. • ‘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’.
    

    View Slide

52. • 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.
    

    View Slide

53. Making conflicts more
    manageable
    

    View Slide

54. • 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.
    

    View Slide

55. • 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.
    

    View Slide

56. View Slide

57. References
    • http://git-scm.com/book/en/v2/Git-Branching-Basic-
    Branching-and-Merging
    • http://git-scm.com/book/en/v2/Git-Tools-Advanced-
    Merging
    • https://help.github.com/articles/resolving-a-merge-
    conflict-from-the-command-line/
    • https://git.3squared.com/3squared/merge-conflict-demo
    • https://www.gitignore.io (for possible .gitignore files)
    

    View Slide