7-tothefuture

   1 \section{To the Future}
   2
   3 Branches are great for trying new things, but you'll probably want some tools for moving your changes between them.
   4
   5 Simple scenario:
   6 \begin{itemize}
   7 \item  You're on the master branch.
   8 \item  You create a new branch called crazyidea.
   9 \item  You do some work on it.
  10 \item  You find that it is a great success, and you want the work to go back into master.
  11 \end{itemize}
  12
  13 Well, first off, you'll want to checkout master because that is the branch you want to change, not crazyidea:
  14
  15 And second, you'll want to, uh, somehow.. add those changes to master.
  16
  17 There are two very different ways to do this: they are called "merge" and "rebase".
  18
  19 It is very important to understand the difference between merge and rebase and use the appropriate tool.
  20
  21 Fortunately, this is a very special case called a "fast-forward", and they behave exactly the same.
  22 Because crazyidea is in the future (or, more precisely, master is an ancestor of crazyidea), all Git has to do is move master forward to where crazyidea is.
  23
  24 In this case you can do either
  25 \begin{verbatim}
  26 git merge crazyidea
  27 \end{verbatim}
  28 or
  29 \begin{verbatim}
  30 git rebase crazyidea
  31 \end{verbatim}
  32
  33 Both will fast-forward master to crazyidea.
  34
  35 Now then, here's a less simple scenario:
  36 \begin{itemize}
  37 \item  You're on the master branch.
  38 \item  You create a new branch called crazyidea.
  39 \item  You do some work on crazyidea.
  40 \item  You go back to master.
  41 \item  You do some different work on master.
  42 \item  You go back to crazyidea.
  43 \item  You want to see the work you've done on master in crazyidea.
  44 \end{itemize}
  45
  46 This is a hard problem to solve.
  47
  48 Git cannot simply move crazyidea to master, as you would lose the work you've done on crazyidea.
  49
  50 Remember, if you screw this up, you can always find your old commits using "git reflog" (or at least, you can do that until 30 days after they disappear).
  51
  52 %TODO: Remove redundant information about patches?
  53
  54 So, first off, here is how rebase would approach the problem:
  55 \begin{itemize}
  56 \item  Create a list of the commits that are in crazyidea but not in master.
  57 \item  Translate each commit into a "patch", a representation of what changed between the commit and the previous version.
  58 \item  Move crazyidea to master.
  59 \item  Attempt to replay what you did by applying the patches in sequence.
  60 \end{itemize}
  61
  62 You can do this by checking out the crazyidea branch and doing
  63 \begin{verbatim}
  64 $ git rebase master
  65 \end{verbatim}
  66
  67 Git will "attempt" to replay what you did, but there's no guarantee that it will actually work, as sometimes patches don't apply.
  68
  69 It probably won't work if you modified the same lines of the same file in each branch.
  70
  71 If it can't apply a patch, Git will stop the process and ask you to resolve the conflict.
  72
  73 Remember, when you do a rebase that isn't a fast-forward, you're creating an alternate version of history.
  74 In this alternate history, you built your current branch (crazyidea) on top of everything that's in the other branch (master).
  75
  76
  77 Git merge does this instead (actually, it can use many different strategies, but this is the common one):
  78 \begin{itemize}
  79 \item  Find the "merge base" of crazyidea and master, that is, the point where they started to diverge.
  80 \item  Generate a patch that would update the merge base to master.
  81 \item  Generate a patch that would update the merge base to crazyidea.
  82 \item  Apply both patches to the merge base at once.
  83 \item  Move crazyidea to this new revision, in which both sets of changes are applied.
  84 \end{itemize}
  85
  86 You can do this by checking out the crazyidea branch and doing
  87 \begin{verbatim}
  88 $ git merge master
  89 \end{verbatim}
  90
  91 Like rebase, merge may have to stop and ask you to resolve a conflict.
  92
  93 Unlike rebase, merge does not create an alternate version of history.
  94 Instead, it "joins" the two branches into a new commit that shares both histories.
  95
  96 In this sense, a merge is kind of like the opposite of a branch.
  97
  98 You might think of a branch as allowing you to create an alternate universe.
  99 In one universe, you spent the day building a swingset.
 100 In the other, you repaired the roof.
 101 At the end of the day, you can merge the two universes back into one universe in which you have a swingset and a roof that does not leak.
 102
 103 However, the merge only changes the branch you had checked out.
 104 The master branch will not have your changes from the crazyidea branch.
 105 Just remember, Git will only alter a branch if you have it checked out.
 106