branch.txt

   1 = Branch Magic =
   2 Cheap Context Switching
   3
   4 == The Boss Key ==
   5
   6 Ever play one of those games where you could hit a special key combination at
   7 any time, and 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 this fact?
   8
   9 In some directory, edit a text file and write "I'm smarter than my boss".
  10 Create a Git repository, that is, <tt>git-init ; git-add . ; git-commit -m "Initial commit"</tt>. Then type
  11
  12  $ git checkout -b boss
  13
  14 Edit the text file to say "My boss is smarter than me", and type <tt>git-commit -a</tt>. Now you can switch between the two versions of the file with
  15
  16  $ git branch master  # see original version of the file
  17
  18 and
  19
  20  $ git branch boss  # see version of the file suitable for boss' eyes
  21
  22 One can imagine reasons to use this that have nothing to do with source code management. Perhaps you have a program that reads data from a certain directory, and every now and then you'd like to switch the data back and forth without reconfiguring the program.
  23
  24 == Dirty Work ==
  25
  26 TODO
  27
  28 == Quick Fixes ==
  29
  30 TODO
  31
  32 == Working While Being Reviewed ==
  33
  34 Some projects require your code to be reviewed before you can submit it. To make life easier for those reviewing your code, if you have a big change to make you might break it into two or more parts, and get each parts separately reviewed.
  35
  36 What if the second part cannot be written until the first part is approved and checked in? In many version control systems, you'd have to send the first part to the reviewers, and then wait until it has been approved before starting on the second part.
  37
  38 Actually that's not quite true, but in many systems editing part 2 before part 1 has been submitted involves a lot of suffering and hardship. In Git, branching and merging are painless. So after you've committed the first part and sent it for review:
  39
  40  $ git checkout -b part2
  41
  42 Next, code the second part of the big change while you're waiting for the first part to be accepted. When the first part is approved and submitted,
  43
  44  $ git branch master
  45  $ git merge part2
  46  $ git branch -d part2
  47
  48 and the second part of the change is ready to review.
  49
  50 But wait! What if it wasn't that simple? Say you made a mistake in the first part, which you have to correct before submitting. No problem! First, switch back to the master branch with <tt>git branch master</tt>. Fix the issue with the first part of the change and hope it gets approved. If not we simply repeat this step.
  51
  52 Eventually, once the first part has been approved and submitted:
  53
  54  $ git merge part2
  55
  56 and again, the second part is ready to be reviewed.