RubyGems - wayfarer - Versions diffs - 0.4.0 → 0.4.4 - Mend

wayfarer 0.4.0 → 0.4.4

Files changed (742) hide show

data/spec/support/static/git-scm.com/book/en/v2/ch00/_abort_merge.html ADDED Viewed

@@ -0,0 +1,1605 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <!-- Global site tag (gtag.js) - Google Analytics -->
+  <script async src="https://www.googletagmanager.com/gtag/js?id=UA-49925874-3"></script>
+  <script>
+    window.dataLayer = window.dataLayer || [];
+    function gtag(){dataLayer.push(arguments);}
+    gtag('js', new Date());
+    gtag('config', 'UA-49925874-3');
+  </script>
+  <meta charset='utf-8'>
+  <meta content='IE=edge,chrome=1' http-equiv='X-UA-Compatible'>
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title>Git - Advanced Merging</title>
+  <link href='../../../../favicon.ico' rel='shortcut icon' type='image/x-icon'>
+  <link rel="stylesheet" media="screen" href="../../../../assets/application-cafcf280f67db0e6d8168ba98a38da878769a9d5f37793b68ffb963a02d185e0.css" />
+  <script src="../../../../assets/modernize-b3ebe0c31c24f230dc62179d3e1030d2e57a53b1668d9382c0a27dbd44a94beb.js"></script>
+  <!--[if (gte IE 6)&(lte IE 8)]>
+  <script src="/javascripts/selectivizr-min.js"></script>
+  <![endif]-->
+</head>
+<body id="documentation">
+  <div class="inner">
+    <header>
+  <a href="https://git-scm.com/"><img src="../../../../images/logo@2x.png" width="110" height="46" alt="Git" /></a>
+  <span id="tagline"></span>
+  <script type="text/javascript">
+    var taglines = ["fast-version-control","everything-is-local","distributed-even-if-your-workflow-isnt","local-branching-on-the-cheap","distributed-is-the-new-centralized"];
+    var tagline = taglines[Math.floor(Math.random() * taglines.length)];
+    document.getElementById('tagline').innerHTML = '--' + tagline;
+  </script>
+  <form id="search" action="https://git-scm.com/search/results">
+    <input id="search-text" name="search" placeholder="Search entire site..." autocomplete="off" type="text" />
+  </form>
+  <div id="search-results"></div>
+</header>
+  </div> <!-- .inner -->
+    <div class="inner">
+      <div id="content-wrapper">
+        <button class="sidebar-btn"></button>
+<aside class="sidebar" id="sidebar">
+  <nav>
+    <ul>
+      <li>
+        <a href="https://git-scm.com/about">About</a>
+        <ul class="">
+          <li>
+            <a href="https://git-scm.com/about">Branching and Merging</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/small-and-fast">Small and Fast</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/distributed">Distributed</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/info-assurance">Data Assurance</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/staging-area">Staging Area</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/free-and-open-source">Free and Open Source</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/about/trademark">Trademark</a>
+          </li>
+        </ul>
+      </li>
+      <li>
+        <a class="active" href="https://git-scm.com/doc">Documentation</a>
+        <ul class="expanded">
+          <li>
+            <a href="https://git-scm.com/docs">Reference</a>
+          </li>
+          <li>
+            <a class="active" href="https://git-scm.com/book">Book</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/videos">Videos</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/doc/ext">External Links</a>
+          </li>
+        </ul>
+      </li>
+      <li>
+        <a href="https://git-scm.com/downloads">Downloads</a>
+        <ul class="">
+          <li>
+            <a href="https://git-scm.com/downloads/guis">GUI Clients</a>
+          </li>
+          <li>
+            <a href="https://git-scm.com/downloads/logos">Logos</a>
+          </li>
+        </ul>
+      </li>
+      <li>
+        <a href="https://git-scm.com/community">Community</a>
+      </li>
+    </ul>
+      <hr class="sidebar">
+        <p>
+This book is available in
+  <a href="https://git-scm.com/book/en">English</a>.
+</p>
+<p>
+  Full translation available in
+  <table>
+    <tr><td><a href="https://git-scm.com/book/az">azərbaycan dili</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/bg">български език</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/de">Deutsch</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/es">Español</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/fr">Français</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/gr">Ελληνικά</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/ja">日本語</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/ko">한국어</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/nl">Nederlands</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/ru">Русский</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/sl">Slovenščina</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/tl">Tagalog</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/uk">Українська</a></td></tr>
+    <tr><td><a href="https://git-scm.com/book/zh">简体中文</a>,</td></tr>
+  </table>
+</p>
+<p>
+  Partial translations available in
+  <table>
+    <tr><td><a href="https://git-scm.com/book/cs">Čeština</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/mk">Македонски</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/pl">Polski</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/sr">Српски</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/uz">Ўзбекча</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/zh-tw">繁體中文</a>,</td></tr>
+  </table>
+</p>
+<p>
+  Translations started for
+  <table>
+    <tr><td><a href="https://git-scm.com/book/be">Беларуская</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/fa" dir="rtl">فارسی</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/id">Indonesian</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/it">Italiano</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/ms">Bahasa Melayu</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/pt-br">Português (Brasil)</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/pt-pt">Português (Portugal)</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/sv">Svenska</a>,</td></tr>
+    <tr><td><a href="https://git-scm.com/book/tr">Türkçe</a>.</td></tr>
+  </table>
+</p>
+<hr class="sidebar"/>
+<p>
+The source of this book is <a href="https://github.com/progit/progit2">hosted on GitHub.</a></br>
+Patches, suggestions and comments are welcome.
+</p>
+  </nav>
+</aside>
+        <div id="content">
+<div id='book-chapters'>
+  <a class="dropdown-trigger" id="book-chapters-trigger" data-panel-id="chapters-dropdown" href="_reverse_commit.html#">Chapters ▾</a>
+<div class='dropdown-panel' id='chapters-dropdown'>
+  <div class="three-column">
+    <div class='column-left'>
+      <ol class='book-toc'>
+  <li class='chapter'>
+  <h2>1. <a href="ch01-getting-started.html">Getting Started</a></h2>
+    <ol>
+        <li>
+          1.1
+          <a href="ch01-getting-started.html" >About Version Control </a>
+        </li>
+        <li>
+          1.2
+          <a href="../Getting-Started-A-Short-History-of-Git.html" >A Short History of Git </a>
+        </li>
+        <li>
+          1.3
+          <a href="what_is_git_section.html" >What is Git? </a>
+        </li>
+        <li>
+          1.4
+          <a href="../Getting-Started-The-Command-Line.html" >The Command Line </a>
+        </li>
+        <li>
+          1.5
+          <a href="../Getting-Started-Installing-Git.html" >Installing Git </a>
+        </li>
+        <li>
+          1.6
+          <a href="_editor.html" >First-Time Git Setup </a>
+        </li>
+        <li>
+          1.7
+          <a href="_git_help.html" >Getting Help </a>
+        </li>
+        <li>
+          1.8
+          <a href="../Getting-Started-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>2. <a href="_git_cloning.html">Git Basics</a></h2>
+    <ol>
+        <li>
+          2.1
+          <a href="_git_cloning.html" >Getting a Git Repository </a>
+        </li>
+        <li>
+          2.2
+          <a href="_git_mv.html" >Recording Changes to the Repository </a>
+        </li>
+        <li>
+          2.3
+          <a href="_viewing_history.html" >Viewing the Commit History </a>
+        </li>
+        <li>
+          2.4
+          <a href="_unstaging.html" >Undoing Things </a>
+        </li>
+        <li>
+          2.5
+          <a href="_remote_repos.html" >Working with Remotes </a>
+        </li>
+        <li>
+          2.6
+          <a href="_annotated_tags.html" >Tagging </a>
+        </li>
+        <li>
+          2.7
+          <a href="_git_aliases.html" >Git Aliases </a>
+        </li>
+        <li>
+          2.8
+          <a href="../Git-Basics-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>3. <a href="_switching_branches.html">Git Branching</a></h2>
+    <ol>
+        <li>
+          3.1
+          <a href="_switching_branches.html" >Branches in a Nutshell </a>
+        </li>
+        <li>
+          3.2
+          <a href="_basic_branching.html" >Basic Branching and Merging </a>
+        </li>
+        <li>
+          3.3
+          <a href="_branch_management.html" >Branch Management </a>
+        </li>
+        <li>
+          3.4
+          <a href="_topic_branch.html" >Branching Workflows </a>
+        </li>
+        <li>
+          3.5
+          <a href="_delete_branches.html" >Remote Branches </a>
+        </li>
+        <li>
+          3.6
+          <a href="_rebase_rebase.html" >Rebasing </a>
+        </li>
+        <li>
+          3.7
+          <a href="../Git-Branching-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>4. <a href="../Git-on-the-Server-The-Protocols.html">Git on the Server</a></h2>
+    <ol>
+        <li>
+          4.1
+          <a href="../Git-on-the-Server-The-Protocols.html" >The Protocols </a>
+        </li>
+        <li>
+          4.2
+          <a href="_bare_repo.html" >Getting Git on a Server </a>
+        </li>
+        <li>
+          4.3
+          <a href="_generate_ssh_key.html" >Generating Your SSH Public Key </a>
+        </li>
+        <li>
+          4.4
+          <a href="_setting_up_server.html" >Setting Up the Server </a>
+        </li>
+        <li>
+          4.5
+          <a href="../Git-on-the-Server-Git-Daemon.html" >Git Daemon </a>
+        </li>
+        <li>
+          4.6
+          <a href="../Git-on-the-Server-Smart-HTTP.html" >Smart HTTP </a>
+        </li>
+        <li>
+          4.7
+          <a href="../Git-on-the-Server-GitWeb.html" >GitWeb </a>
+        </li>
+        <li>
+          4.8
+          <a href="_gitlab_groups_section.html" >GitLab </a>
+        </li>
+        <li>
+          4.9
+          <a href="../Git-on-the-Server-Third-Party-Hosted-Options.html" >Third Party Hosted Options </a>
+        </li>
+        <li>
+          4.10
+          <a href="../Git-on-the-Server-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>5. <a href="_integration_manager.html">Distributed Git</a></h2>
+    <ol>
+        <li>
+          5.1
+          <a href="_integration_manager.html" >Distributed Workflows </a>
+        </li>
+        <li>
+          5.2
+          <a href="_project_over_email.html" >Contributing to a Project </a>
+        </li>
+        <li>
+          5.3
+          <a href="_git_am.html" >Maintaining a Project </a>
+        </li>
+        <li>
+          5.4
+          <a href="../Distributed-Git-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+</ol>
+    </div>
+    <div class='column-middle'>
+      <ol class='book-toc'>
+  <li class='chapter'>
+  <h2>6. <a href="_personal_avatar.html">GitHub</a></h2>
+    <ol>
+        <li>
+          6.1
+          <a href="_personal_avatar.html" >Account Setup and Configuration </a>
+        </li>
+        <li>
+          6.2
+          <a href="_fetch_and_push_on_different_repositories.html" >Contributing to a Project </a>
+        </li>
+        <li>
+          6.3
+          <a href="_email_notifications.html" >Maintaining a Project </a>
+        </li>
+        <li>
+          6.4
+          <a href="_team_page.html" >Managing an organization </a>
+        </li>
+        <li>
+          6.5
+          <a href="_commit_status.html" >Scripting GitHub </a>
+        </li>
+        <li>
+          6.6
+          <a href="../GitHub-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>7. <a href="_git_reflog.html">Git Tools</a></h2>
+    <ol>
+        <li>
+          7.1
+          <a href="_git_reflog.html" >Revision Selection </a>
+        </li>
+        <li>
+          7.2
+          <a href="_interactive_staging.html" >Interactive Staging </a>
+        </li>
+        <li>
+          7.3
+          <a href="_git_clean.html" >Stashing and Cleaning </a>
+        </li>
+        <li>
+          7.4
+          <a href="_signing_commits.html" >Signing Your Work </a>
+        </li>
+        <li>
+          7.5
+          <a href="_git_grep.html" >Searching </a>
+        </li>
+        <li>
+          7.6
+          <a href="_removing_file_every_commit.html" >Rewriting History </a>
+        </li>
+        <li>
+          7.7
+          <a href="_the_index.html" >Reset Demystified </a>
+        </li>
+        <li>
+          7.8
+          <a href="_reverse_commit.html" class=active>Advanced Merging </a>
+        </li>
+        <li>
+          7.9
+          <a href="ref_rerere.html" >Rerere </a>
+        </li>
+        <li>
+          7.10
+          <a href="_file_annotation.html" >Debugging with Git </a>
+        </li>
+        <li>
+          7.11
+          <a href="_publishing_submodules.html" >Submodules </a>
+        </li>
+        <li>
+          7.12
+          <a href="_bundling.html" >Bundling </a>
+        </li>
+        <li>
+          7.13
+          <a href="_replace.html" >Replace </a>
+        </li>
+        <li>
+          7.14
+          <a href="_credential_caching.html" >Credential Storage </a>
+        </li>
+        <li>
+          7.15
+          <a href="../Git-Tools-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>8. <a href="_external_merge_tools.html">Customizing Git</a></h2>
+    <ol>
+        <li>
+          8.1
+          <a href="_external_merge_tools.html" >Git Configuration </a>
+        </li>
+        <li>
+          8.2
+          <a href="_keyword_expansion.html" >Git Attributes </a>
+        </li>
+        <li>
+          8.3
+          <a href="_email_hooks.html" >Git Hooks </a>
+        </li>
+        <li>
+          8.4
+          <a href="_enforcing_commit_message_format.html" >An Example Git-Enforced Policy </a>
+        </li>
+        <li>
+          8.5
+          <a href="../Customizing-Git-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>9. <a href="_git_svn.html">Git and Other Systems</a></h2>
+    <ol>
+        <li>
+          9.1
+          <a href="_git_svn.html" >Git as a Client </a>
+        </li>
+        <li>
+          9.2
+          <a href="_git_p4.html" >Migrating to Git </a>
+        </li>
+        <li>
+          9.3
+          <a href="../Git-and-Other-Systems-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>10. <a href="_plumbing_porcelain.html">Git Internals</a></h2>
+    <ol>
+        <li>
+          10.1
+          <a href="_plumbing_porcelain.html" >Plumbing and Porcelain </a>
+        </li>
+        <li>
+          10.2
+          <a href="_git_commit_objects.html" >Git Objects </a>
+        </li>
+        <li>
+          10.3
+          <a href="ref_the_ref.html" >Git References </a>
+        </li>
+        <li>
+          10.4
+          <a href="../Git-Internals-Packfiles.html" >Packfiles </a>
+        </li>
+        <li>
+          10.5
+          <a href="_pushing_refspecs.html" >The Refspec </a>
+        </li>
+        <li>
+          10.6
+          <a href="../Git-Internals-Transfer-Protocols.html" >Transfer Protocols </a>
+        </li>
+        <li>
+          10.7
+          <a href="_git_gc.html" >Maintenance and Data Recovery </a>
+        </li>
+        <li>
+          10.8
+          <a href="../Git-Internals-Environment-Variables.html" >Environment Variables </a>
+        </li>
+        <li>
+          10.9
+          <a href="../Git-Internals-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+</ol>
+    </div>
+    <div class='column-right'>
+      <ol class='book-toc'>
+  <li class='chapter'>
+  <h2>A1. <a href="../Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces.html">Appendix A: Git in Other Environments</a></h2>
+    <ol>
+        <li>
+          A1.1
+          <a href="../Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces.html" >Graphical Interfaces </a>
+        </li>
+        <li>
+          A1.2
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio.html" >Git in Visual Studio </a>
+        </li>
+        <li>
+          A1.3
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio-Code.html" >Git in Visual Studio Code </a>
+        </li>
+        <li>
+          A1.4
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-IntelliJ-%252F-PyCharm-%252F-WebStorm-%252F-PhpStorm-%252F-RubyMine.html" >Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine </a>
+        </li>
+        <li>
+          A1.5
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-Sublime-Text.html" >Git in Sublime Text </a>
+        </li>
+        <li>
+          A1.6
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-Bash.html" >Git in Bash </a>
+        </li>
+        <li>
+          A1.7
+          <a href="oh_my_zsh_git.html" >Git in Zsh </a>
+        </li>
+        <li>
+          A1.8
+          <a href="../Appendix-A:-Git-in-Other-Environments-Git-in-PowerShell.html" >Git in PowerShell </a>
+        </li>
+        <li>
+          A1.9
+          <a href="../Appendix-A:-Git-in-Other-Environments-Summary.html" >Summary </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>A2. <a href="../Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git.html">Appendix B: Embedding Git in your Applications</a></h2>
+    <ol>
+        <li>
+          A2.1
+          <a href="../Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git.html" >Command-line Git </a>
+        </li>
+        <li>
+          A2.2
+          <a href="_libgit2_bindings.html" >Libgit2 </a>
+        </li>
+        <li>
+          A2.3
+          <a href="../Appendix-B:-Embedding-Git-in-your-Applications-JGit.html" >JGit </a>
+        </li>
+        <li>
+          A2.4
+          <a href="../Appendix-B:-Embedding-Git-in-your-Applications-go-git.html" >go-git </a>
+        </li>
+        <li>
+          A2.5
+          <a href="../Appendix-B:-Embedding-Git-in-your-Applications-Dulwich.html" >Dulwich </a>
+        </li>
+    </ol>
+  </li>
+  <li class='chapter'>
+  <h2>A3. <a href="ch_core_editor.html">Appendix C: Git Commands</a></h2>
+    <ol>
+        <li>
+          A3.1
+          <a href="ch_core_editor.html" >Setup and Config </a>
+        </li>
+        <li>
+          A3.2
+          <a href="../Appendix-C:-Git-Commands-Getting-and-Creating-Projects.html" >Getting and Creating Projects </a>
+        </li>
+        <li>
+          A3.3
+          <a href="../Appendix-C:-Git-Commands-Basic-Snapshotting.html" >Basic Snapshotting </a>
+        </li>
+        <li>
+          A3.4
+          <a href="../Appendix-C:-Git-Commands-Branching-and-Merging.html" >Branching and Merging </a>
+        </li>
+        <li>
+          A3.5
+          <a href="../Appendix-C:-Git-Commands-Sharing-and-Updating-Projects.html" >Sharing and Updating Projects </a>
+        </li>
+        <li>
+          A3.6
+          <a href="../Appendix-C:-Git-Commands-Inspection-and-Comparison.html" >Inspection and Comparison </a>
+        </li>
+        <li>
+          A3.7
+          <a href="../Appendix-C:-Git-Commands-Debugging.html" >Debugging </a>
+        </li>
+        <li>
+          A3.8
+          <a href="../Appendix-C:-Git-Commands-Patching.html" >Patching </a>
+        </li>
+        <li>
+          A3.9
+          <a href="../Appendix-C:-Git-Commands-Email.html" >Email </a>
+        </li>
+        <li>
+          A3.10
+          <a href="../Appendix-C:-Git-Commands-External-Systems.html" >External Systems </a>
+        </li>
+        <li>
+          A3.11
+          <a href="../Appendix-C:-Git-Commands-Administration.html" >Administration </a>
+        </li>
+        <li>
+          A3.12
+          <a href="../Appendix-C:-Git-Commands-Plumbing-Commands.html" >Plumbing Commands </a>
+        </li>
+    </ol>
+  </li>
+</ol>
+    </div>
+  </div>
+ </div>
+    <span class="light" id="edition">
+      2nd Edition
+    </span>
+</div>
+<div id='main' class="book edition2">
+    <h1>7.8 Git Tools - Advanced Merging</h1>
+  <div>
+<h2 id="_advanced_merging">Advanced Merging</h2>
+<div class="paragraph">
+<p>Merging in Git is typically fairly easy.
+Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be surprised by one enormous conflict at the end of the series.</p>
+</div>
+<div class="paragraph">
+<p>However, sometimes tricky conflicts do occur.
+Unlike some other version control systems, Git does not try to be overly clever about merge conflict resolution.
+Git’s philosophy is to be smart about determining when a merge resolution is unambiguous, but if there is a conflict, it does not try to be clever about automatically resolving it.
+Therefore, if you wait too long to merge two branches that diverge quickly, you can run into some issues.</p>
+</div>
+<div class="paragraph">
+<p>In this section, we’ll go over what some of those issues might be and what tools Git gives you to help handle these more tricky situations.
+We’ll also cover some of the different, non-standard types of merges you can do, as well as see how to back out of merges that you’ve done.</p>
+</div>
+<div class="sect3">
+<h3 id="_merge_conflicts">Merge Conflicts</h3>
+<div class="paragraph">
+<p>While we covered some basics on resolving merge conflicts in <a href="_basic_merge_conflicts.html">Basic Merge Conflicts</a>, for more complex conflicts, Git provides a few tools to help you figure out what’s going on and how to better deal with the conflict.</p>
+</div>
+<div class="paragraph">
+<p>First of all, if at all possible, try to make sure your working directory is clean before doing a merge that may have conflicts.
+If you have work in progress, either commit it to a temporary branch or stash it.
+This makes it so that you can undo <strong>anything</strong> you try here.
+If you have unsaved changes in your working directory when you try a merge, some of these tips may help you preserve that work.</p>
+</div>
+<div class="paragraph">
+<p>Let’s walk through a very simple example.
+We have a super simple Ruby file that prints 'hello world'.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-ruby" data-lang="ruby">#! /usr/bin/env ruby
+def hello
+  puts 'hello world'
+end
+hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In our repository, we create a new branch named <code>whitespace</code> and proceed to change all the Unix line endings to DOS line endings, essentially changing every line of the file, but just with whitespace.
+Then we change the line “hello world” to “hello mundo”.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git checkout -b whitespace
+Switched to a new branch 'whitespace'
+$ unix2dos hello.rb
+unix2dos: converting file hello.rb to DOS format ...
+$ git commit -am 'Convert hello.rb to DOS'
+[whitespace 3270f76] Convert hello.rb to DOS
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+$ vim hello.rb
+$ git diff -b
+diff --git a/hello.rb b/hello.rb
+index ac51efd..e85207e 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ #! /usr/bin/env ruby
+ def hello
+-  puts 'hello world'
++  puts 'hello mundo'^M
+ end
+ hello()
+$ git commit -am 'Use Spanish instead of English'
+[whitespace 6d338d2] Use Spanish instead of English
+ 1 file changed, 1 insertion(+), 1 deletion(-)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Now we switch back to our <code>master</code> branch and add some documentation for the function.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git checkout master
+Switched to branch 'master'
+$ vim hello.rb
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index ac51efd..36c06c8 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,5 +1,6 @@
+ #! /usr/bin/env ruby
++# prints out a greeting
+ def hello
+   puts 'hello world'
+ end
+$ git commit -am 'Add comment documenting the function'
+[master bec6336] Add comment documenting the function
+ 1 file changed, 1 insertion(+)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Now we try to merge in our <code>whitespace</code> branch and we’ll get conflicts because of the whitespace changes.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge whitespace
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Automatic merge failed; fix conflicts and then commit the result.</code></pre>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_abort_merge">Aborting a Merge</h4>
+<div class="paragraph">
+<p>We now have a few options.
+First, let’s cover how to get out of this situation.
+If you perhaps weren’t expecting conflicts and don’t want to quite deal with the situation yet, you can simply back out of the merge with <code>git merge --abort</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git status -sb
+## master
+UU hello.rb
+$ git merge --abort
+$ git status -sb
+## master</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The <code>git merge --abort</code> option tries to revert back to your state before you ran the merge.
+The only cases where it may not be able to do this perfectly would be if you had unstashed, uncommitted changes in your working directory when you ran it, otherwise it should work fine.</p>
+</div>
+<div class="paragraph">
+<p>If for some reason you just want to start over, you can also run <code>git reset --hard HEAD</code>, and your repository will be back to the last committed state.
+Remember that any uncommitted work will be lost, so make sure you don’t want any of your changes.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_ignoring_whitespace">Ignoring Whitespace</h4>
+<div class="paragraph">
+<p>In this specific case, the conflicts are whitespace related.
+We know this because the case is simple, but it’s also pretty easy to tell in real cases when looking at the conflict because every line is removed on one side and added again on the other.
+By default, Git sees all of these lines as being changed, so it can’t merge the files.</p>
+</div>
+<div class="paragraph">
+<p>The default merge strategy can take arguments though, and a few of them are about properly ignoring whitespace changes.
+If you see that you have a lot of whitespace issues in a merge, you can simply abort it and do it again, this time with <code>-Xignore-all-space</code> or <code>-Xignore-space-change</code>.
+The first option ignores whitespace <strong>completely</strong> when comparing lines, the second treats sequences of one or more whitespace characters as equivalent.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge -Xignore-space-change whitespace
+Auto-merging hello.rb
+Merge made by the 'recursive' strategy.
+ hello.rb | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Since in this case, the actual file changes were not conflicting, once we ignore the whitespace changes, everything merges just fine.</p>
+</div>
+<div class="paragraph">
+<p>This is a lifesaver if you have someone on your team who likes to occasionally reformat everything from spaces to tabs or vice-versa.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_manual_remerge">Manual File Re-merging</h4>
+<div class="paragraph">
+<p>Though Git handles whitespace pre-processing pretty well, there are other types of changes that perhaps Git can’t handle automatically, but are scriptable fixes.
+As an example, let’s pretend that Git could not handle the whitespace change and we needed to do it by hand.</p>
+</div>
+<div class="paragraph">
+<p>What we really need to do is run the file we’re trying to merge in through a <code>dos2unix</code> program before trying the actual file merge.
+So how would we do that?</p>
+</div>
+<div class="paragraph">
+<p>First, we get into the merge conflict state.
+Then we want to get copies of my version of the file, their version (from the branch we’re merging in) and the common version (from where both sides branched off).
+Then we want to fix up either their side or our side and re-try the merge again for just this single file.</p>
+</div>
+<div class="paragraph">
+<p>Getting the three file versions is actually pretty easy.
+Git stores all of these versions in the index under “stages” which each have numbers associated with them.
+Stage 1 is the common ancestor, stage 2 is your version and stage 3 is from the <code>MERGE_HEAD</code>, the version you’re merging in (“theirs”).</p>
+</div>
+<div class="paragraph">
+<p>You can extract a copy of each of these versions of the conflicted file with the <code>git show</code> command and a special syntax.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git show :1:hello.rb &gt; hello.common.rb
+$ git show :2:hello.rb &gt; hello.ours.rb
+$ git show :3:hello.rb &gt; hello.theirs.rb</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you want to get a little more hard core, you can also use the <code>ls-files -u</code> plumbing command to get the actual SHA-1s of the Git blobs for each of these files.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git ls-files -u
+100755 ac51efdc3df4f4fd328d1a02ad05331d8e2c9111 1	hello.rb
+100755 36c06c8752c78d2aff89571132f3bf7841a7b5c3 2	hello.rb
+100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3	hello.rb</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The <code>:1:hello.rb</code> is just a shorthand for looking up that blob SHA-1.</p>
+</div>
+<div class="paragraph">
+<p>Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known <code>git merge-file</code> command which does just that.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ dos2unix hello.theirs.rb
+dos2unix: converting file hello.theirs.rb to Unix format ...
+$ git merge-file -p \
+    hello.ours.rb hello.common.rb hello.theirs.rb &gt; hello.rb
+$ git diff -b
+diff --cc hello.rb
+index 36c06c8,e85207e..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,8 -1,7 +1,8 @@@
+  #! /usr/bin/env ruby
+ +# prints out a greeting
+  def hello
+-   puts 'hello world'
++   puts 'hello mundo'
+  end
+  hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>At this point we have nicely merged the file.
+In fact, this actually works better than the <code>ignore-space-change</code> option because this actually fixes the whitespace changes before merge instead of simply ignoring them.
+In the <code>ignore-space-change</code> merge, we actually ended up with a few lines with DOS line endings, making things mixed.</p>
+</div>
+<div class="paragraph">
+<p>If you want to get an idea before finalizing this commit about what was actually changed between one side or the other, you can ask <code>git diff</code> to compare what is in your working directory that you’re about to commit as the result of the merge to any of these stages.
+Let’s go through them all.</p>
+</div>
+<div class="paragraph">
+<p>To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run <code>git diff --ours</code>:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff --ours
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index 36c06c8..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -2,7 +2,7 @@
+ # prints out a greeting
+ def hello
+-  puts 'hello world'
++  puts 'hello mundo'
+ end
+ hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>So here we can easily see that what happened in our branch, what we’re actually introducing to this file with this merge, is changing that single line.</p>
+</div>
+<div class="paragraph">
+<p>If we want to see how the result of the merge differed from what was on their side, you can run <code>git diff --theirs</code>.
+In this and the following example, we have to use <code>-b</code> to strip out the whitespace because we’re comparing it to what is in Git, not our cleaned up <code>hello.theirs.rb</code> file.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff --theirs -b
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index e85207e..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,5 +1,6 @@
+ #! /usr/bin/env ruby
++# prints out a greeting
+ def hello
+   puts 'hello mundo'
+ end</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Finally, you can see how the file has changed from both sides with <code>git diff --base</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff --base -b
+* Unmerged path hello.rb
+diff --git a/hello.rb b/hello.rb
+index ac51efd..44d0a25 100755
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,8 @@
+ #! /usr/bin/env ruby
++# prints out a greeting
+ def hello
+-  puts 'hello world'
++  puts 'hello mundo'
+ end
+ hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>At this point we can use the <code>git clean</code> command to clear out the extra files we created to do the manual merge but no longer need.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git clean -f
+Removing hello.common.rb
+Removing hello.ours.rb
+Removing hello.theirs.rb</code></pre>
+</div>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_checking_out_conflicts">Checking Out Conflicts</h4>
+<div class="paragraph">
+<p>Perhaps we’re not happy with the resolution at this point for some reason, or maybe manually editing one or both sides still didn’t work well and we need more context.</p>
+</div>
+<div class="paragraph">
+<p>Let’s change up the example a little.
+For this example, we have two longer lived branches that each have a few commits in them but create a legitimate content conflict when merged.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git log --graph --oneline --decorate --all
+* f1270f7 (HEAD, master) Update README
+* 9af9d3b Create README
+* 694971d Update phrase to 'hola world'
+| * e3eb223 (mundo) Add more tests
+| * 7cff591 Create initial testing script
+| * c3ffff1 Change text to 'hello mundo'
+|/
+* b7dcc89 Initial hello world code</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>We now have three unique commits that live only on the <code>master</code> branch and three others that live on the <code>mundo</code> branch.
+If we try to merge the <code>mundo</code> branch in, we get a conflict.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge mundo
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Automatic merge failed; fix conflicts and then commit the result.</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>We would like to see what the merge conflict is.
+If we open up the file, we’ll see something like this:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-ruby" data-lang="ruby">#! /usr/bin/env ruby
+def hello
+&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
+  puts 'hola world'
+=======
+  puts 'hello mundo'
+&gt;&gt;&gt;&gt;&gt;&gt;&gt; mundo
+end
+hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Both sides of the merge added content to this file, but some of the commits modified the file in the same place that caused this conflict.</p>
+</div>
+<div class="paragraph">
+<p>Let’s explore a couple of tools that you now have at your disposal to determine how this conflict came to be.
+Perhaps it’s not obvious how exactly you should fix this conflict.
+You need more context.</p>
+</div>
+<div class="paragraph">
+<p>One helpful tool is <code>git checkout</code> with the <code>--conflict</code> option.
+This will re-checkout the file again and replace the merge conflict markers.
+This can be useful if you want to reset the markers and try to resolve them again.</p>
+</div>
+<div class="paragraph">
+<p>You can pass <code>--conflict</code> either <code>diff3</code> or <code>merge</code> (which is the default).
+If you pass it <code>diff3</code>, Git will use a slightly different version of conflict markers, not only giving you the “ours” and “theirs” versions, but also the “base” version inline to give you more context.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git checkout --conflict=diff3 hello.rb</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Once we run that, the file will look like this instead:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-ruby" data-lang="ruby">#! /usr/bin/env ruby
+def hello
+&lt;&lt;&lt;&lt;&lt;&lt;&lt; ours
+  puts 'hola world'
+||||||| base
+  puts 'hello world'
+=======
+  puts 'hello mundo'
+&gt;&gt;&gt;&gt;&gt;&gt;&gt; theirs
+end
+hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you like this format, you can set it as the default for future merge conflicts by setting the <code>merge.conflictstyle</code> setting to <code>diff3</code>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git config --global merge.conflictstyle diff3</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The <code>git checkout</code> command can also take <code>--ours</code> and <code>--theirs</code> options, which can be a really fast way of just choosing either one side or the other without merging things at all.</p>
+</div>
+<div class="paragraph">
+<p>This can be particularly useful for conflicts of binary files where you can simply choose one side, or where you only want to merge certain files in from another branch — you can do the merge and then checkout certain files from one side or the other before committing.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_merge_log">Merge Log</h4>
+<div class="paragraph">
+<p>Another useful tool when resolving merge conflicts is <code>git log</code>.
+This can help you get context on what may have contributed to the conflicts.
+Reviewing a little bit of history to remember why two lines of development were touching the same area of code can be really helpful sometimes.</p>
+</div>
+<div class="paragraph">
+<p>To get a full list of all of the unique commits that were included in either branch involved in this merge, we can use the “triple dot” syntax that we learned in <a href="_triple_dot.html">Triple Dot</a>.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git log --oneline --left-right HEAD...MERGE_HEAD
+&lt; f1270f7 Update README
+&lt; 9af9d3b Create README
+&lt; 694971d Update phrase to 'hola world'
+&gt; e3eb223 Add more tests
+&gt; 7cff591 Create initial testing script
+&gt; c3ffff1 Change text to 'hello mundo'</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>That’s a nice list of the six total commits involved, as well as which line of development each commit was on.</p>
+</div>
+<div class="paragraph">
+<p>We can further simplify this though to give us much more specific context.
+If we add the <code>--merge</code> option to <code>git log</code>, it will only show the commits in either side of the merge that touch a file that’s currently conflicted.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git log --oneline --left-right --merge
+&lt; 694971d Update phrase to 'hola world'
+&gt; c3ffff1 Change text to 'hello mundo'</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you run that with the <code>-p</code> option instead, you get just the diffs to the file that ended up in conflict.
+This can be <strong>really</strong> helpful in quickly giving you the context you need to help understand why something conflicts and how to more intelligently resolve it.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_combined_diff_format">Combined Diff Format</h4>
+<div class="paragraph">
+<p>Since Git stages any merge results that are successful, when you run <code>git diff</code> while in a conflicted merge state, you only get what is currently still in conflict.
+This can be helpful to see what you still have to resolve.</p>
+</div>
+<div class="paragraph">
+<p>When you run <code>git diff</code> directly after a merge conflict, it will give you information in a rather unique diff output format.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff
+diff --cc hello.rb
+index 0399cd5,59727f0..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,11 @@@
+  #! /usr/bin/env ruby
+  def hello
+++&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
+ +  puts 'hola world'
+++=======
++   puts 'hello mundo'
+++&gt;&gt;&gt;&gt;&gt;&gt;&gt; mundo
+  end
+  hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The format is called “Combined Diff” and gives you two columns of data next to each line.
+The first column shows you if that line is different (added or removed) between the “ours” branch and the file in your working directory and the second column does the same between the “theirs” branch and your working directory copy.</p>
+</div>
+<div class="paragraph">
+<p>So in that example you can see that the <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code> lines are in the working copy but were not in either side of the merge.
+This makes sense because the merge tool stuck them in there for our context, but we’re expected to remove them.</p>
+</div>
+<div class="paragraph">
+<p>If we resolve the conflict and run <code>git diff</code> again, we’ll see the same thing, but it’s a little more useful.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ vim hello.rb
+$ git diff
+diff --cc hello.rb
+index 0399cd5,59727f0..0000000
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,7 @@@
+  #! /usr/bin/env ruby
+  def hello
+-   puts 'hola world'
+ -  puts 'hello mundo'
+++  puts 'hola mundo'
+  end
+  hello()</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This shows us that “hola world” was in our side but not in the working copy, that “hello mundo” was in their side but not in the working copy and finally that “hola mundo” was not in either side but is now in the working copy.
+This can be useful to review before committing the resolution.</p>
+</div>
+<div class="paragraph">
+<p>You can also get this from the <code>git log</code> for any merge to see how something was resolved after the fact.
+Git will output this format if you run <code>git show</code> on a merge commit, or if you add a <code>--cc</code> option to a <code>git log -p</code> (which by default only shows patches for non-merge commits).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git log --cc -p -1
+commit 14f41939956d80b9e17bb8721354c33f8d5b5a79
+Merge: f1270f7 e3eb223
+Author: Scott Chacon &lt;schacon@gmail.com&gt;
+Date:   Fri Sep 19 18:14:49 2014 +0200
+    Merge branch 'mundo'
+    Conflicts:
+        hello.rb
+diff --cc hello.rb
+index 0399cd5,59727f0..e1d0799
+--- a/hello.rb
++++ b/hello.rb
+@@@ -1,7 -1,7 +1,7 @@@
+  #! /usr/bin/env ruby
+  def hello
+-   puts 'hola world'
+ -  puts 'hello mundo'
+++  puts 'hola mundo'
+  end
+  hello()</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h3 id="_undoing_merges">Undoing Merges</h3>
+<div class="paragraph">
+<p>Now that you know how to create a merge commit, you’ll probably make some by mistake.
+One of the great things about working with Git is that it’s okay to make mistakes, because it’s possible (and in many cases easy) to fix them.</p>
+</div>
+<div class="paragraph">
+<p>Merge commits are no different.
+Let’s say you started work on a topic branch, accidentally merged it into <code>master</code>, and now your commit history looks like this:</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="../images/undomerge-start.png" alt="Accidental merge commit">
+</div>
+<div class="title">Figure 137. Accidental merge commit</div>
+</div>
+<div class="paragraph">
+<p>There are two ways to approach this problem, depending on what your desired outcome is.</p>
+</div>
+<div class="sect4">
+<h4 id="_fix_the_references">Fix the references</h4>
+<div class="paragraph">
+<p>If the unwanted merge commit only exists on your local repository, the easiest and best solution is to move the branches so that they point where you want them to.
+In most cases, if you follow the errant <code>git merge</code> with <code>git reset --hard HEAD~</code>, this will reset the branch pointers so they look like this:</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="../images/undomerge-reset.png" alt="History after `git reset --hard HEAD~`">
+</div>
+<div class="title">Figure 138. History after <code>git reset --hard HEAD~</code>
+</div>
+</div>
+<div class="paragraph">
+<p>We covered <code>reset</code> back in <a href="_git_reset.html">Reset Demystified</a>, so it shouldn’t be too hard to figure out what’s going on here.
+Here’s a quick refresher: <code>reset --hard</code> usually goes through three steps:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Move the branch HEAD points to.
+In this case, we want to move <code>master</code> to where it was before the merge commit (<code>C6</code>).</p>
+</li>
+<li>
+<p>Make the index look like HEAD.</p>
+</li>
+<li>
+<p>Make the working directory look like the index.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>The downside of this approach is that it’s rewriting history, which can be problematic with a shared repository.
+Check out <a href="_rebase_peril.html">The Perils of Rebasing</a> for more on what can happen; the short version is that if other people have the commits you’re rewriting, you should probably avoid <code>reset</code>.
+This approach also won’t work if any other commits have been created since the merge; moving the refs would effectively lose those changes.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_reverse_commit">Reverse the commit</h4>
+<div class="paragraph">
+<p>If moving the branch pointers around isn’t going to work for you, Git gives you the option of making a new commit which undoes all the changes from an existing one.
+Git calls this operation a “revert”, and in this particular scenario, you’d invoke it like this:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git revert -m 1 HEAD
+[master b1d8379] Revert "Merge branch 'topic'"</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The <code>-m 1</code> flag indicates which parent is the “mainline” and should be kept.
+When you invoke a merge into <code>HEAD</code> (<code>git merge topic</code>), the new commit has two parents: the first one is <code>HEAD</code> (<code>C6</code>), and the second is the tip of the branch being merged in (<code>C4</code>).
+In this case, we want to undo all the changes introduced by merging in parent #2 (<code>C4</code>), while keeping all the content from parent #1 (<code>C6</code>).</p>
+</div>
+<div class="paragraph">
+<p>The history with the revert commit looks like this:</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="../images/undomerge-revert.png" alt="History after `git revert -m 1`">
+</div>
+<div class="title">Figure 139. History after <code>git revert -m 1</code>
+</div>
+</div>
+<div class="paragraph">
+<p>The new commit <code>^M</code> has exactly the same contents as <code>C6</code>, so starting from here it’s as if the merge never happened, except that the now-unmerged commits are still in <code>HEAD</code>’s history.
+Git will get confused if you try to merge <code>topic</code> into <code>master</code> again:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge topic
+Already up-to-date.</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>There’s nothing in <code>topic</code> that isn’t already reachable from <code>master</code>.
+What’s worse, if you add work to <code>topic</code> and merge again, Git will only bring in the changes <em>since</em> the reverted merge:</p>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="../images/undomerge-revert2.png" alt="History with a bad merge">
+</div>
+<div class="title">Figure 140. History with a bad merge</div>
+</div>
+<div class="paragraph">
+<p>The best way around this is to un-revert the original merge, since now you want to bring in the changes that were reverted out, <strong>then</strong> create a new merge commit:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git revert ^M
+[master 09f0126] Revert "Revert "Merge branch 'topic'""
+$ git merge topic</code></pre>
+</div>
+</div>
+<div class="imageblock">
+<div class="content">
+<img src="../images/undomerge-revert3.png" alt="History after re-merging a reverted merge">
+</div>
+<div class="title">Figure 141. History after re-merging a reverted merge</div>
+</div>
+<div class="paragraph">
+<p>In this example, <code>M</code> and <code>^M</code> cancel out.
+<code>^^M</code> effectively merges in the changes from <code>C3</code> and <code>C4</code>, and <code>C8</code> merges in the changes from <code>C7</code>, so now <code>topic</code> is fully merged.</p>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h3 id="_other_types_of_merges">Other Types of Merges</h3>
+<div class="paragraph">
+<p>So far we’ve covered the normal merge of two branches, normally handled with what is called the “recursive” strategy of merging.
+There are other ways to merge branches together however.
+Let’s cover a few of them quickly.</p>
+</div>
+<div class="sect4">
+<h4 id="_our_or_theirs_preference">Our or Theirs Preference</h4>
+<div class="paragraph">
+<p>First of all, there is another useful thing we can do with the normal “recursive” mode of merging.
+We’ve already seen the <code>ignore-all-space</code> and <code>ignore-space-change</code> options which are passed with a <code>-X</code> but we can also tell Git to favor one side or the other when it sees a conflict.</p>
+</div>
+<div class="paragraph">
+<p>By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it.
+If you would prefer for Git to simply choose a specific side and ignore the other side instead of letting you manually resolve the conflict, you can pass the <code>merge</code> command either a <code>-Xours</code> or <code>-Xtheirs</code>.</p>
+</div>
+<div class="paragraph">
+<p>If Git sees this, it will not add conflict markers.
+Any differences that are mergeable, it will merge.
+Any differences that conflict, it will simply choose the side you specify in whole, including binary files.</p>
+</div>
+<div class="paragraph">
+<p>If we go back to the “hello world” example we were using before, we can see that merging in our branch causes conflicts.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge mundo
+Auto-merging hello.rb
+CONFLICT (content): Merge conflict in hello.rb
+Resolved 'hello.rb' using previous resolution.
+Automatic merge failed; fix conflicts and then commit the result.</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>However if we run it with <code>-Xours</code> or <code>-Xtheirs</code> it does not.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge -Xours mundo
+Auto-merging hello.rb
+Merge made by the 'recursive' strategy.
+ hello.rb | 2 +-
+ test.sh  | 2 ++
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+ create mode 100644 test.sh</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In that case, instead of getting conflict markers in the file with “hello mundo” on one side and “hola world” on the other, it will simply pick “hola world”.
+However, all the other non-conflicting changes on that branch are merged successfully in.</p>
+</div>
+<div class="paragraph">
+<p>This option can also be passed to the <code>git merge-file</code> command we saw earlier by running something like <code>git merge-file --ours</code> for individual file merges.</p>
+</div>
+<div class="paragraph">
+<p>If you want to do something like this but not have Git even try to merge changes from the other side in, there is a more draconian option, which is the “ours” merge <em>strategy</em>.
+This is different from the “ours” recursive merge <em>option</em>.</p>
+</div>
+<div class="paragraph">
+<p>This will basically do a fake merge.
+It will record a new merge commit with both branches as parents, but it will not even look at the branch you’re merging in.
+It will simply record as the result of the merge the exact code in your current branch.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git merge -s ours mundo
+Merge made by the 'ours' strategy.
+$ git diff HEAD HEAD~
+$</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>You can see that there is no difference between the branch we were on and the result of the merge.</p>
+</div>
+<div class="paragraph">
+<p>This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on.
+For example, say you branched off a <code>release</code> branch and have done some work on it that you will want to merge back into your <code>master</code> branch at some point.
+In the meantime some bugfix on <code>master</code> needs to be backported into your <code>release</code> branch.
+You can merge the bugfix branch into the <code>release</code> branch and also <code>merge -s ours</code> the same branch into your <code>master</code> branch (even though the fix is already there) so when you later merge the <code>release</code> branch again, there are no conflicts from the bugfix.</p>
+</div>
+</div>
+<div class="sect4">
+<h4 id="_subtree_merge">Subtree Merging</h4>
+<div class="paragraph">
+<p>The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one.
+When you specify a subtree merge, Git is often smart enough to figure out that one is a subtree of the other and merge appropriately.</p>
+</div>
+<div class="paragraph">
+<p>We’ll go through an example of adding a separate project into an existing project and then merging the code of the second into a subdirectory of the first.</p>
+</div>
+<div class="paragraph">
+<p>First, we’ll add the Rack application to our project.
+We’ll add the Rack project as a remote reference in our own project and then check it out into its own branch:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git remote add rack_remote https://github.com/rack/rack
+$ git fetch rack_remote --no-tags
+warning: no common commits
+remote: Counting objects: 3184, done.
+remote: Compressing objects: 100% (1465/1465), done.
+remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
+Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done.
+Resolving deltas: 100% (1952/1952), done.
+From https://github.com/rack/rack
+ * [new branch]      build      -&gt; rack_remote/build
+ * [new branch]      master     -&gt; rack_remote/master
+ * [new branch]      rack-0.4   -&gt; rack_remote/rack-0.4
+ * [new branch]      rack-0.9   -&gt; rack_remote/rack-0.9
+$ git checkout -b rack_branch rack_remote/master
+Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
+Switched to a new branch "rack_branch"</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Now we have the root of the Rack project in our <code>rack_branch</code> branch and our own project in the <code>master</code> branch.
+If you check out one and then the other, you can see that they have different project roots:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ ls
+AUTHORS         KNOWN-ISSUES   Rakefile      contrib         lib
+COPYING         README         bin           example         test
+$ git checkout master
+Switched to branch "master"
+$ ls
+README</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This is sort of a strange concept.
+Not all the branches in your repository actually have to be branches of the same project.
+It’s not common, because it’s rarely helpful, but it’s fairly easy to have branches contain completely different histories.</p>
+</div>
+<div class="paragraph">
+<p>In this case, we want to pull the Rack project into our <code>master</code> project as a subdirectory.
+We can do that in Git with <code>git read-tree</code>.
+You’ll learn more about <code>read-tree</code> and its friends in <a href="ch10-git-internals.html">Git Internals</a>, but for now know that it reads the root tree of one branch into your current staging area and working directory.
+We just switched back to your <code>master</code> branch, and we pull the <code>rack_branch</code> branch into the <code>rack</code> subdirectory of our <code>master</code> branch of our main project:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git read-tree --prefix=rack/ -u rack_branch</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>When we commit, it looks like we have all the Rack files under that subdirectory – as though we copied them in from a tarball.
+What gets interesting is that we can fairly easily merge changes from one of the branches to the other.
+So, if the Rack project updates, we can pull in upstream changes by switching to that branch and pulling:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git checkout rack_branch
+$ git pull</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Then, we can merge those changes back into our <code>master</code> branch.
+To pull in the changes and prepopulate the commit message, use the <code>--squash</code> option, as well as the recursive merge strategy’s <code>-Xsubtree</code> option.
+The recursive strategy is the default here, but we include it for clarity.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git checkout master
+$ git merge --squash -s recursive -Xsubtree=rack rack_branch
+Squash commit -- not updating HEAD
+Automatic merge went well; stopped before committing as requested</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>All the changes from the Rack project are merged in and ready to be committed locally.
+You can also do the opposite – make changes in the <code>rack</code> subdirectory of your <code>master</code> branch and then merge them into your <code>rack_branch</code> branch later to submit them to the maintainers or push them upstream.</p>
+</div>
+<div class="paragraph">
+<p>This gives us a way to have a workflow somewhat similar to the submodule workflow without using submodules (which we will cover in <a href="_git_submodules.html">Submodules</a>).
+We can keep branches with other related projects in our repository and subtree merge them into our project occasionally.
+It is nice in some ways, for example all the code is committed to a single place.
+However, it has other drawbacks in that it’s a bit more complex and easier to make mistakes in reintegrating changes or accidentally pushing a branch into an unrelated repository.</p>
+</div>
+<div class="paragraph">
+<p>Another slightly weird thing is that to get a diff between what you have in your <code>rack</code> subdirectory and the code in your <code>rack_branch</code> branch – to see if you need to merge them – you can’t use the normal <code>diff</code> command.
+Instead, you must run <code>git diff-tree</code> with the branch you want to compare to:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff-tree -p rack_branch</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Or, to compare what is in your <code>rack</code> subdirectory with what the <code>master</code> branch on the server was the last time you fetched, you can run:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="highlight"><code class="language-console" data-lang="console">$ git diff-tree -p rack_remote/master</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div id="nav"><a href="_the_index.html">prev</a> | <a href="ref_rerere.html">next</a></div></div>
+</div>
+        </div>
+      </div>
+      <footer>
+  <div class="site-source">
+    <a href="https://git-scm.com/site">About this site</a><br>
+    Patches, suggestions, and comments are welcome.
+  </div>
+  <div class="sfc-member">
+    Git is a member of <a href="https://git-scm.com/sfc">Software Freedom Conservancy</a>
+  </div>
+</footer>
+<a href="_reverse_commit.html#top" class="no-js scrollToTop" id="scrollToTop" data-label="Scroll to top">
+  <img src="../../../../images/icons/chevron-up@2x.png" width="20" height="20" alt="scroll-to-top"/>
+</a>
+<script src="../../../../assets/application-38b0d42ff05ffea45841edebbd14b75b89585646153808e82907c2c5c11f324b.js"></script>
+    </div>
+</body>
+</html>