/usr/share/doc/gitmagic/html/ch04.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
  <meta name="generator" content=
  "HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
  <meta http-equiv="Content-Type" content=
  "text/html; charset=utf-8">

  <title>Git Magic - Chapter&nbsp;4.&nbsp;Branch Wizardry</title>
  <link rel="stylesheet" type="text/css" href="default.css">
  <meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
  <link rel="home" href="index.html" title="Git Magic">
  <link rel="up" href="index.html" title="Git Magic">
  <link rel="prev" href="ch03.html" title=
  "Chapter&nbsp;3.&nbsp;Cloning Around">
  <link rel="next" href="ch05.html" title=
  "Chapter&nbsp;5.&nbsp;Lessons of History">
</head>

<body bgcolor="white" text="black" link="#0000FF" vlink="#840084"
alink="#0000FF">
    <div class="toc">
      <ul class="toc">
<li><b>Git Magic</b></li>
        <li>
          <span class="preface"><a href=
          "index.html">Preface</a></span>

          <ul>
            <li><span class="section"><a href=
            "index.html#thanks">Thanks!</a></span></li>

            <li><span class="section"><a href=
            "index.html#license">License</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch01.html">1.
          Introduction</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch01.html#work_is_play">Work is Play</a></span></li>

            <li><span class="section"><a href=
            "ch01.html#version_control">Version
            Control</a></span></li>

            <li><span class="section"><a href=
            "ch01.html#distributed_control">Distributed
            Control</a></span></li>

            <li><span class="section"><a href=
            "ch01.html#a_silly_superstition">A Silly
            Superstition</a></span></li>

            <li><span class="section"><a href=
            "ch01.html#merge_conflicts">Merge
            Conflicts</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch02.html">2. Basic
          Tricks</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch02.html#saving_state">Saving State</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#add_delete_rename">Add, Delete,
            Rename</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#advanced_undo_redo">Advanced
            Undo/Redo</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#reverting">Reverting</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#changelog_generation">Changelog
            Generation</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#downloading_files">Downloading
            Files</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#the_bleeding_edge">The Bleeding
            Edge</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#instant_publishing">Instant
            Publishing</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#what_have_i_done">What Have I
            Done?</a></span></li>

            <li><span class="section"><a href=
            "ch02.html#exercise">Exercise</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch03.html">3. Cloning
          Around</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch03.html#sync_computers">Sync
            Computers</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#classic_source_control">Classic Source
            Control</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#secret_source">Secret Source</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#bare_repositories">Bare
            repositories</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#push_versus_pull">Push versus
            pull</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#forking_a_project">Forking a
            Project</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#ultimate_backups">Ultimate
            Backups</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#light_speed_multitask">Light-Speed
            Multitask</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#guerilla_version_control">Guerilla Version
            Control</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#mercurial">Mercurial</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#bazaar">Bazaar</a></span></li>

            <li><span class="section"><a href=
            "ch03.html#why_i_use_git">Why I use Git</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch04.html">4. Branch
          Wizardry</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch04.html#the_boss_key">The Boss Key</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#dirty_work">Dirty Work</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#quick_fixes">Quick Fixes</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#merging">Merging</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#uninterrupted_workflow">Uninterrupted
            Workflow</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#reorganizing_a_medley">Reorganizing a
            Medley</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#managing_branches">Managing
            Branches</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#temporary_branches">Temporary
            Branches</a></span></li>

            <li><span class="section"><a href=
            "ch04.html#work_how_you_want">Work How You
            Want</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch05.html">5. Lessons of
          History</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch05.html#i_stand_corrected">I Stand
            Corrected</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#and_then_some">… And Then
            Some</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#local_changes_last">Local Changes
            Last</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#rewriting_history">Rewriting
            History</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#making_history">Making
            History</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#where_did_it_all_go_wrong">Where Did It All
            Go Wrong?</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#who_made_it_all_go_wrong">Who Made It All Go
            Wrong?</a></span></li>

            <li><span class="section"><a href=
            "ch05.html#personal_experience">Personal
            Experience</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch06.html">6. Multiplayer
          Git</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch06.html#who_am_i">Who Am I?</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#git_over_ssh_http">Git Over SSH,
            HTTP</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#git_over_anything">Git Over
            Anything</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#patches_the_global_currency">Patches: The
            Global Currency</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#sorry_we_8217_ve_moved">Sorry, We’ve
            Moved</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#remote_branches">Remote
            Branches</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#multiple_remotes">Multiple
            Remotes</a></span></li>

            <li><span class="section"><a href=
            "ch06.html#my_preferences">My
            Preferences</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch07.html">7. Git
          Grandmastery</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch07.html#source_releases">Source
            Releases</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#commit_what_changed">Commit What
            Changed</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#my_commit_is_too_big">My Commit Is Too
            Big!</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#the_index_git_8217_s_staging_area">The
            Index: Git’s Staging Area</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#don_8217_t_lose_your_head">Don’t Lose Your
            HEAD</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#head_hunting">HEAD-hunting</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#building_on_git">Building On
            Git</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#daring_stunts">Daring Stunts</a></span></li>

            <li><span class="section"><a href=
            "ch07.html#preventing_bad_commits">Preventing Bad
            Commits</a></span></li>
          </ul>
        </li>

        <li>
          <span class="chapter"><a href="ch08.html">8. Secrets
          Revealed</a></span>

          <ul>
            <li><span class="section"><a href=
            "ch08.html#invisibility">Invisibility</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#integrity">Integrity</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#intelligence">Intelligence</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#indexing">Indexing</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#git_8217_s_origins">Git’s
            Origins</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#the_object_database">The Object
            Database</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#blobs">Blobs</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#trees">Trees</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#commits">Commits</a></span></li>

            <li><span class="section"><a href=
            "ch08.html#indistinguishable_from_magic">Indistinguishable
            From Magic</a></span></li>
          </ul>
        </li>

        <li>
          <span class="appendix"><a href="apa.html">A. Git
          Shortcomings</a></span>

          <ul>
            <li><span class="section"><a href=
            "apa.html#sha1_weaknesses">SHA1
            Weaknesses</a></span></li>

            <li><span class="section"><a href=
            "apa.html#microsoft_windows">Microsoft
            Windows</a></span></li>

            <li><span class="section"><a href=
            "apa.html#unrelated_files">Unrelated
            Files</a></span></li>

            <li><span class="section"><a href=
            "apa.html#who_8217_s_editing_what">Who’s Editing
            What?</a></span></li>

            <li><span class="section"><a href=
            "apa.html#file_history">File History</a></span></li>

            <li><span class="section"><a href=
            "apa.html#initial_clone">Initial Clone</a></span></li>

            <li><span class="section"><a href=
            "apa.html#volatile_projects">Volatile
            Projects</a></span></li>

            <li><span class="section"><a href=
            "apa.html#global_counter">Global
            Counter</a></span></li>

            <li><span class="section"><a href=
            "apa.html#empty_subdirectories">Empty
            Subdirectories</a></span></li>

            <li><span class="section"><a href=
            "apa.html#initial_commit">Initial
            Commit</a></span></li>

            <li><span class="section"><a href=
            "apa.html#interface_quirks">Interface
            Quirks</a></span></li>
          </ul>
        </li>

        <li><span class="appendix"><a href="apb.html">B.
        Translating This Guide</a></span></li>
      </ul>
    </div>
<div class="content">
  <div class="chapter">
    <div class="titlepage">
      <div>
        <div>
          <h1 class="title"><a id="branch_wizardry" name=
          "branch_wizardry"></a>Chapter&nbsp;4.&nbsp;Branch
          Wizardry</h1>
        </div>
      </div>
    </div>

    <p>Instant branching and merging are the most lethal of Git’s
    killer features.</p>

    <p><span class="strong"><strong>Problem</strong></span>:
    External factors inevitably necessitate context switching. A
    severe bug manifests in the released version without warning.
    The deadline for a certain feature is moved closer. A developer
    whose help you need for a key section of the project is about
    to leave. In all cases, you must abruptly drop what you are
    doing and focus on a completely different task.</p>

    <p>Interrupting your train of thought can be detrimental to
    your productivity, and the more cumbersome it is to switch
    contexts, the greater the loss. With centralized version
    control we must download a fresh working copy from the central
    server. Distributed systems fare better, as we can clone the
    desired version locally.</p>

    <p>But cloning still entails copying the whole working
    directory as well as the entire history up to the given point.
    Even though Git reduces the cost of this with file sharing and
    hard links, the project files themselves must be recreated in
    their entirety in the new working directory.</p>

    <p><span class="strong"><strong>Solution</strong></span>: Git
    has a better tool for these situations that is much faster and
    more space-efficient than cloning: <span class=
    "strong"><strong>git branch</strong></span>.</p>

    <p>With this magic word, the files in your directory suddenly
    shapeshift from one version to another. This transformation can
    do more than merely go back or forward in history. Your files
    can morph from the last release to the experimental version to
    the current development version to your friend’s version and so
    on.</p>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="the_boss_key" name=
            "the_boss_key"></a>The Boss Key</h2>
          </div>
        </div>
      </div>

      <p>Ever played one of those games where at the push of a
      button (“the boss key”), the screen would instantly display a
      spreadsheet or something? So if the boss walked in the office
      while you were playing the game you could quickly hide it
      away?</p>

      <p>In some directory:</p>
      <pre class="literallayout">
$ echo "I'm smarter than my boss" &gt; myfile.txt
$ git init
$ git add .
$ git commit -m "Initial commit"
</pre>

      <p>We have created a Git repository that tracks one text file
      containing a certain message. Now type:</p>
      <pre class="literallayout">
$ git checkout -b boss  # nothing seems to change after this
$ echo "My boss is smarter than me" &gt; myfile.txt
$ git commit -a -m "Another commit"
</pre>

      <p>It looks like we’ve just overwritten our file and
      committed it. But it’s an illusion. Type:</p>
      <pre class="literallayout">
$ git checkout master  # switch to original version of the file
</pre>

      <p>and hey presto! The text file is restored. And if the boss
      decides to snoop around this directory, type:</p>
      <pre class="literallayout">
$ git checkout boss  # switch to version suitable for boss' eyes
</pre>

      <p>You can switch between the two versions of the file as
      much as you like, and commit to each independently.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="dirty_work" name=
            "dirty_work"></a>Dirty Work</h2>
          </div>
        </div>
      </div>

      <p><a name="branch" id="branch"></a>Say you’re working on
      some feature, and for some reason, you need to go back three
      versions and temporarily put in a few print statements to see
      how something works. Then:</p>
      <pre class="literallayout">
$ git commit -a
$ git checkout HEAD~3
</pre>

      <p>Now you can add ugly temporary code all over the place.
      You can even commit these changes. When you’re done,</p>
      <pre class="literallayout">
$ git checkout master
</pre>

      <p>to return to your original work. Observe that any
      uncommitted changes are carried over.</p>

      <p>What if you wanted to save the temporary changes after
      all? Easy:</p>
      <pre class="literallayout">
$ git checkout -b dirty
</pre>

      <p>and commit before switching back to the master branch.
      Whenever you want to return to the dirty changes, simply
      type:</p>
      <pre class="literallayout">
$ git checkout dirty
</pre>

      <p>We touched upon this command in an earlier chapter, when
      discussing loading old states. At last we can tell the whole
      story: the files change to the requested state, but we must
      leave the master branch. Any commits made from now on take
      your files down a different road, which can be named
      later.</p>

      <p>In other words, after checking out an old state, Git
      automatically puts you in a new, unnamed branch, which can be
      named and saved with <span class="strong"><strong>git
      checkout -b</strong></span>.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="quick_fixes" name=
            "quick_fixes"></a>Quick Fixes</h2>
          </div>
        </div>
      </div>

      <p>You’re in the middle of something when you are told to
      drop everything and fix a newly discovered bug in commit
      <code class="literal">1b6d...</code>:</p>
      <pre class="literallayout">
$ git commit -a
$ git checkout -b fixes 1b6d
</pre>

      <p>Then once you’ve fixed the bug:</p>
      <pre class="literallayout">
$ git commit -a -m "Bug fixed"
$ git checkout master
</pre>

      <p>and resume work on your original task. You can even
      <span class="emphasis"><em>merge</em></span> in the freshly
      baked bugfix:</p>
      <pre class="literallayout">
$ git merge fixes
</pre>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="merging" name=
            "merging"></a>Merging</h2>
          </div>
        </div>
      </div>

      <p>With some version control systems, creating branches is
      easy but merging them back together is tough. With Git,
      merging is so trivial that you might be unaware of it
      happening.</p>

      <p>We actually encountered merging long ago. The <span class=
      "strong"><strong>pull</strong></span> command in fact
      <span class="emphasis"><em>fetches</em></span> commits and
      then merges them into your current branch. If you have no
      local changes, then the merge is a <span class=
      "emphasis"><em>fast forward</em></span>, a degenerate case
      akin to fetching the latest version in a centralized version
      control system. But if you do have local changes, Git will
      automatically merge, and report any conflicts.</p>

      <p>Ordinarily, a commit has exactly one <span class=
      "emphasis"><em>parent commit</em></span>, namely, the
      previous commit. Merging branches together produces a commit
      with at least two parents. This begs the question: what
      commit does <code class="literal">HEAD~10</code> really refer
      to? A commit could have multiple parents, so which one do we
      follow?</p>

      <p>It turns out this notation chooses the first parent every
      time. This is desirable because the current branch becomes
      the first parent during a merge; frequently you’re only
      concerned with the changes you made in the current branch, as
      opposed to changes merged in from other branches.</p>

      <p>You can refer to a specific parent with a caret. For
      example, to show the logs from the second parent:</p>
      <pre class="literallayout">
$ git log HEAD^2
</pre>

      <p>You may omit the number for the first parent. For example,
      to show the differences with the first parent:</p>
      <pre class="literallayout">
$ git diff HEAD^
</pre>

      <p>You can combine this notation with other types. For
      example:</p>
      <pre class="literallayout">
$ git checkout 1b6d^^2~10 -b ancient
</pre>

      <p>starts a new branch “ancient” representing the state 10
      commits back from the second parent of the first parent of
      the commit starting with 1b6d.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="uninterrupted_workflow" name=
            "uninterrupted_workflow"></a>Uninterrupted
            Workflow</h2>
          </div>
        </div>
      </div>

      <p>Often in hardware projects, the second step of a plan must
      await the completion of the first step. A car undergoing
      repairs might sit idly in a garage until a particular part
      arrives from the factory. A prototype might wait for a chip
      to be fabricated before construction can continue.</p>

      <p>Software projects can be similar. The second part of a new
      feature may have to wait until the first part has been
      released and tested. Some projects require your code to be
      reviewed before accepting it, so you might wait until the
      first part is approved before starting the second part.</p>

      <p>Thanks to painless branching and merging, we can bend the
      rules and work on Part II before Part I is officially ready.
      Suppose you have committed Part I and sent it for review.
      Let’s say you’re in the <code class="literal">master</code>
      branch. Then branch off:</p>
      <pre class="literallayout">
$ git checkout -b part2
</pre>

      <p>Next, work on Part II, committing your changes along the
      way. To err is human, and often you’ll want to go back and
      fix something in Part I. If you’re lucky, or very good, you
      can skip these lines.</p>
      <pre class="literallayout">
$ git checkout master  # Go back to Part I.
$ fix_problem
$ git commit -a        # Commit the fixes.
$ git checkout part2   # Go back to Part II.
$ git merge master     # Merge in those fixes.
</pre>

      <p>Eventually, Part I is approved:</p>
      <pre class="literallayout">
$ git checkout master  # Go back to Part I.
$ submit files         # Release to the world!
$ git merge part2      # Merge in Part II.
$ git branch -d part2  # Delete "part2" branch.
</pre>

      <p>Now you’re in the <code class="literal">master</code>
      branch again, with Part II in the working directory.</p>

      <p>It’s easy to extend this trick for any number of parts.
      It’s also easy to branch off retroactively: suppose you
      belatedly realize you should have created a branch 7 commits
      ago. Then type:</p>
      <pre class="literallayout">
$ git branch -m master part2  # Rename "master" branch to "part2".
$ git branch master HEAD~7    # Create new "master", 7 commits upstream.
</pre>

      <p>The <code class="literal">master</code> branch now
      contains just Part I, and the <code class=
      "literal">part2</code> branch contains the rest. We are in
      the latter branch; we created <code class=
      "literal">master</code> without switching to it, because we
      want to continue work on <code class="literal">part2</code>.
      This is unusual. Until now, we’ve been switching to branches
      immediately after creation, as in:</p>
      <pre class="literallayout">
$ git checkout HEAD~7 -b master  # Create a branch, and switch to it.
</pre>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="reorganizing_a_medley" name=
            "reorganizing_a_medley"></a>Reorganizing a Medley</h2>
          </div>
        </div>
      </div>

      <p>Perhaps you like to work on all aspects of a project in
      the same branch. You want to keep works-in-progress to
      yourself and want others to see your commits only when they
      have been neatly organized. Start a couple of branches:</p>
      <pre class="literallayout">
$ git branch sanitized    # Create a branch for sanitized commits.
$ git checkout -b medley  # Create and switch to a branch to work in.
</pre>

      <p>Next, work on anything: fix bugs, add features, add
      temporary code, and so forth, committing often along the way.
      Then:</p>
      <pre class="literallayout">
$ git checkout sanitized
$ git cherry-pick medley^^
</pre>

      <p>applies the grandparent of the head commit of the “medley”
      branch to the “sanitized” branch. With appropriate
      cherry-picks you can construct a branch that contains only
      permanent code, and has related commits grouped together.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="managing_branches" name=
            "managing_branches"></a>Managing Branches</h2>
          </div>
        </div>
      </div>

      <p>List all branches by typing:</p>
      <pre class="literallayout">
$ git branch
</pre>

      <p>By default, you start in a branch named “master”. Some
      advocate leaving the “master” branch untouched and creating
      new branches for your own edits.</p>

      <p>The <span class="strong"><strong>-d</strong></span> and
      <span class="strong"><strong>-m</strong></span> options allow
      you to delete and move (rename) branches. See <span class=
      "strong"><strong>git help branch</strong></span>.</p>

      <p>The “master” branch is a useful custom. Others may assume
      that your repository has a branch with this name, and that it
      contains the official version of your project. Although you
      can rename or obliterate the “master” branch, you might as
      well respect this convention.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="temporary_branches" name=
            "temporary_branches"></a>Temporary Branches</h2>
          </div>
        </div>
      </div>

      <p>After a while you may realize you are creating short-lived
      branches frequently for similar reasons: every other branch
      merely serves to save the current state so you can briefly
      hop back to an older state to fix a high-priority bug or
      something.</p>

      <p>It’s analogous to changing the TV channel temporarily to
      see what else is on. But instead of pushing a couple of
      buttons, you have to create, check out, merge, and delete
      temporary branches. Luckily, Git has a shortcut that is as
      convenient as a TV remote control:</p>
      <pre class="literallayout">
$ git stash
</pre>

      <p>This saves the current state in a temporary location (a
      <span class="emphasis"><em>stash</em></span>) and restores
      the previous state. Your working directory appears exactly as
      it was before you started editing, and you can fix bugs, pull
      in upstream changes, and so on. When you want to go back to
      the stashed state, type:</p>
      <pre class="literallayout">
$ git stash apply  # You may need to resolve some conflicts.
</pre>

      <p>You can have multiple stashes, and manipulate them in
      various ways. See <span class="strong"><strong>git help
      stash</strong></span>. As you may have guessed, Git maintains
      branches behind the scenes to perform this magic trick.</p>
    </div>

    <div class="section">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title"><a id="work_how_you_want" name=
            "work_how_you_want"></a>Work How You Want</h2>
          </div>
        </div>
      </div>

      <p>You might wonder if branches are worth the bother. After
      all, clones are almost as fast, and you can switch between
      them with <span class="strong"><strong>cd</strong></span>
      instead of esoteric Git commands.</p>

      <p>Consider web browsers. Why support multiple tabs as well
      as multiple windows? Because allowing both accommodates a
      wide variety of styles. Some users like to keep only one
      browser window open, and use tabs for multiple webpages.
      Others might insist on the other extreme: multiple windows
      with no tabs anywhere. Others still prefer something in
      between.</p>

      <p>Branching is like tabs for your working directory, and
      cloning is like opening a new browser window. These
      operations are fast and local, so why not experiment to find
      the combination that best suits you? Git lets you work
      exactly how you want.</p>
    </div>
  </div><script type="text/javascript" src="find_selflink.js">
</script>
</div>
</div><div class="footer"><a href="/~blynn/">Ben Lynn</a></div>
</body>
</html>
gitmagic 20140125-1 / usr / share / doc / gitmagic / html / ch04.html
