de/pot/branch.po

   1 # Git Magic - A guide to using Git
   2 # This file is distributed under the GNU GENERAL PUBLIC LICENSE Version 3.
   3 # Benn Lynn <benlynn@gmail.com>, 2007.
   4 # Armin Stebich <armin@lordofbikes.de>, 2010.
   5 msgid ""
   6 msgstr ""
   7 "Project-Id-Version: Git Magic deutsch\n"
   8 "Report-Msgid-Bugs-To: bennlynn@gmail.com\n"
   9 "POT-Creation-Date: 2010-10-30 08:21+0300\n"
  10 "PO-Revision-Date: 2010-10-26 18:38+0300\n"
  11 "Last-Translator: Armin Stebich <armin@lordofbikes.de>\n"
  12 "Language-Team: de <git-magic@lordofbikes.de>\n"
  13 "Language: de\n"
  14 "MIME-Version: 1.0\n"
  15 "Content-Type: text/plain; charset=UTF-8\n"
  16 "Content-Transfer-Encoding: 8bit\n"
  17
  18 #. type: Plain text
  19 #: ../en/branch.txt:2
  20 msgid "== Branch Wizardry =="
  21 msgstr ""
  22
  23 #. type: Plain text
  24 #: ../en/branch.txt:4
  25 msgid ""
  26 "Instant branching and merging are the most lethal of Git's killer features."
  27 msgstr ""
  28
  29 #. type: Plain text
  30 #: ../en/branch.txt:8
  31 #, no-wrap
  32 msgid ""
  33 "*Problem*: External factors inevitably necessitate context switching. A severe\n"
  34 "bug manifests in the released version without warning. The deadline for a\n"
  35 "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.\n"
  36 msgstr ""
  37
  38 #. type: Plain text
  39 #: ../en/branch.txt:10
  40 msgid ""
  41 "Interrupting your train of thought can be detrimental to your productivity, "
  42 "and the more cumbersome it is to switch contexts, the greater the loss. With "
  43 "centralized version control we must download a fresh working copy from the "
  44 "central server. Distributed systems fare better, as we can clone the desired "
  45 "version locally."
  46 msgstr ""
  47
  48 #. type: Plain text
  49 #: ../en/branch.txt:12
  50 msgid ""
  51 "But cloning still entails copying the whole working directory as well as the "
  52 "entire history up to the given point. Even though Git reduces the cost of "
  53 "this with file sharing and hard links, the project files themselves must be "
  54 "recreated in their entirety in the new working directory."
  55 msgstr ""
  56
  57 #. type: Plain text
  58 #: ../en/branch.txt:14
  59 #, no-wrap
  60 msgid "*Solution*: Git has a better tool for these situations that is much faster and more space-efficient than cloning: *git branch*.\n"
  61 msgstr ""
  62
  63 #. type: Plain text
  64 #: ../en/branch.txt:16
  65 msgid ""
  66 "With this magic word, the files in your directory suddenly shapeshift from "
  67 "one version to another. This transformation can do more than merely go back "
  68 "or forward in history. Your files can morph from the last release to the "
  69 "experimental version to the current development version to your friend's "
  70 "version and so on."
  71 msgstr ""
  72
  73 #. type: Plain text
  74 #: ../en/branch.txt:18
  75 msgid "=== The Boss Key ==="
  76 msgstr ""
  77
  78 #. type: Plain text
  79 #: ../en/branch.txt:20
  80 msgid ""
  81 "Ever played one of those games where at the push of a button (``the boss "
  82 "key''), the screen would instantly display a spreadsheet or something? So if "
  83 "the boss walked in the office while you were playing the game you could "
  84 "quickly hide it away?"
  85 msgstr ""
  86
  87 #. type: Plain text
  88 #: ../en/branch.txt:22
  89 msgid "In some directory:"
  90 msgstr ""
  91
  92 #. type: Plain text
  93 #: ../en/branch.txt:27
  94 #, no-wrap
  95 msgid ""
  96 " $ echo \"I'm smarter than my boss\" > myfile.txt\n"
  97 " $ git init\n"
  98 " $ git add .\n"
  99 " $ git commit -m \"Initial commit\"\n"
 100 msgstr ""
 101
 102 #. type: Plain text
 103 #: ../en/branch.txt:29
 104 msgid ""
 105 "We have created a Git repository that tracks one text file containing a "
 106 "certain message. Now type:"
 107 msgstr ""
 108
 109 #. type: Plain text
 110 #: ../en/branch.txt:33
 111 #, no-wrap
 112 msgid ""
 113 " $ git checkout -b boss  # nothing seems to change after this\n"
 114 " $ echo \"My boss is smarter than me\" > myfile.txt\n"
 115 " $ git commit -a -m \"Another commit\"\n"
 116 msgstr ""
 117
 118 #. type: Plain text
 119 #: ../en/branch.txt:35
 120 msgid ""
 121 "It looks like we've just overwritten our file and committed it. But it's an "
 122 "illusion. Type:"
 123 msgstr ""
 124
 125 #. type: Plain text
 126 #: ../en/branch.txt:37
 127 #, no-wrap
 128 msgid " $ git checkout master  # switch to original version of the file\n"
 129 msgstr ""
 130
 131 #. type: Plain text
 132 #: ../en/branch.txt:39
 133 msgid ""
 134 "and hey presto! The text file is restored. And if the boss decides to snoop "
 135 "around this directory, type:"
 136 msgstr ""
 137
 138 #. type: Plain text
 139 #: ../en/branch.txt:41
 140 #, no-wrap
 141 msgid " $ git checkout boss  # switch to version suitable for boss' eyes\n"
 142 msgstr ""
 143
 144 #. type: Plain text
 145 #: ../en/branch.txt:43
 146 msgid ""
 147 "You can switch between the two versions of the file as much as you like, and "
 148 "commit to each independently."
 149 msgstr ""
 150
 151 #. type: Plain text
 152 #: ../en/branch.txt:45
 153 msgid "=== Dirty Work ==="
 154 msgstr ""
 155
 156 #. type: Plain text
 157 #: ../en/branch.txt:48
 158 msgid ""
 159 "[[branch]] Say you're working on some feature, and for some reason, you need "
 160 "to go back three versions and temporarily put in a few print statements to "
 161 "see how something works. Then:"
 162 msgstr ""
 163
 164 #. type: Plain text
 165 #: ../en/branch.txt:51
 166 #, no-wrap
 167 msgid ""
 168 " $ git commit -a\n"
 169 " $ git checkout HEAD~3\n"
 170 msgstr ""
 171
 172 #. type: Plain text
 173 #: ../en/branch.txt:53
 174 msgid ""
 175 "Now you can add ugly temporary code all over the place. You can even commit "
 176 "these changes. When you're done,"
 177 msgstr ""
 178
 179 #. type: Plain text
 180 #: ../en/branch.txt:55
 181 #, no-wrap
 182 msgid " $ git checkout master\n"
 183 msgstr ""
 184
 185 #. type: Plain text
 186 #: ../en/branch.txt:57
 187 msgid ""
 188 "to return to your original work. Observe that any uncommitted changes are "
 189 "carried over."
 190 msgstr ""
 191
 192 #. type: Plain text
 193 #: ../en/branch.txt:59
 194 msgid "What if you wanted to save the temporary changes after all? Easy:"
 195 msgstr ""
 196
 197 #. type: Plain text
 198 #: ../en/branch.txt:61
 199 #, no-wrap
 200 msgid " $ git checkout -b dirty\n"
 201 msgstr ""
 202
 203 #. type: Plain text
 204 #: ../en/branch.txt:63
 205 msgid ""
 206 "and commit before switching back to the master branch. Whenever you want to "
 207 "return to the dirty changes, simply type:"
 208 msgstr ""
 209
 210 #. type: Plain text
 211 #: ../en/branch.txt:65
 212 #, no-wrap
 213 msgid " $ git checkout dirty\n"
 214 msgstr ""
 215
 216 #. type: Plain text
 217 #: ../en/branch.txt:67
 218 msgid ""
 219 "We touched upon this command in an earlier chapter, when discussing loading "
 220 "old states. At last we can tell the whole story: the files change to the "
 221 "requested state, but we must leave the master branch. Any commits made from "
 222 "now on take your files down a different road, which can be named later."
 223 msgstr ""
 224
 225 #. type: Plain text
 226 #: ../en/branch.txt:69
 227 msgid ""
 228 "In other words, after checking out an old state, Git automatically puts you "
 229 "in a new, unnamed branch, which can be named and saved with *git checkout -"
 230 "b*."
 231 msgstr ""
 232
 233 #. type: Plain text
 234 #: ../en/branch.txt:71
 235 msgid "=== Quick Fixes ==="
 236 msgstr ""
 237
 238 #. type: Plain text
 239 #: ../en/branch.txt:73
 240 msgid ""
 241 "You're in the middle of something when you are told to drop everything and "
 242 "fix a newly discovered bug in commit `1b6d...`:"
 243 msgstr ""
 244
 245 #. type: Plain text
 246 #: ../en/branch.txt:76
 247 #, no-wrap
 248 msgid ""
 249 " $ git commit -a\n"
 250 " $ git checkout -b fixes 1b6d\n"
 251 msgstr ""
 252
 253 #. type: Plain text
 254 #: ../en/branch.txt:78
 255 msgid "Then once you've fixed the bug:"
 256 msgstr ""
 257
 258 #. type: Plain text
 259 #: ../en/branch.txt:82
 260 #, no-wrap
 261 msgid ""
 262 " $ git commit -a -m \"Bug fixed\"\n"
 263 " $ git push  # to the central repository\n"
 264 " $ git checkout master\n"
 265 msgstr ""
 266
 267 #. type: Plain text
 268 #: ../en/branch.txt:84
 269 msgid "and resume work on your original task."
 270 msgstr ""
 271
 272 #. type: Plain text
 273 #: ../en/branch.txt:86
 274 msgid "You can even 'merge' in the bugfix you just made, either by typing:"
 275 msgstr ""
 276
 277 #. type: Plain text
 278 #: ../en/branch.txt:88
 279 #, no-wrap
 280 msgid " $ git merge fixes\n"
 281 msgstr ""
 282
 283 #. type: Plain text
 284 #: ../en/branch.txt:90
 285 msgid "or:"
 286 msgstr ""
 287
 288 #. type: Plain text
 289 #: ../en/branch.txt:92
 290 #, no-wrap
 291 msgid " $ git pull\n"
 292 msgstr ""
 293
 294 #. type: Plain text
 295 #: ../en/branch.txt:94
 296 msgid "since you have already pushed the bugfix to the main repository."
 297 msgstr ""
 298
 299 #. type: Plain text
 300 #: ../en/branch.txt:96
 301 msgid "=== Merging ==="
 302 msgstr ""
 303
 304 #. type: Plain text
 305 #: ../en/branch.txt:100
 306 msgid ""
 307 "With some version control systems, creating branches is easy but merging "
 308 "them back together is tough. With Git, merging is so trivial that you might "
 309 "be unaware of it happening."
 310 msgstr ""
 311
 312 #. type: Plain text
 313 #: ../en/branch.txt:106
 314 msgid ""
 315 "We actually encountered merging long ago. The *pull* command in fact "
 316 "'fetches' commits and then merges them into your current branch. If you have "
 317 "no local changes, then the merge is a 'fast forward', a degenerate case akin "
 318 "to fetching the latest version in a centralized version control system. But "
 319 "if you do have local changes, Git will automatically merge, and report any "
 320 "conflicts."
 321 msgstr ""
 322
 323 #. type: Plain text
 324 #: ../en/branch.txt:111
 325 msgid ""
 326 "Ordinarily, a commit has exactly one 'parent commit', namely, the previous "
 327 "commit. Merging branches together produces a commit with at least two "
 328 "parents.  This begs the question: what commit does `HEAD~10` really refer "
 329 "to? A commit could have multiple parents, so which one do we follow?"
 330 msgstr ""
 331
 332 #. type: Plain text
 333 #: ../en/branch.txt:116
 334 msgid ""
 335 "It turns out this notation chooses the first parent every time. This is "
 336 "desirable because the current branch becomes the first parent during a "
 337 "merge; frequently you're only concerned with the changes you made in the "
 338 "current branch, as opposed to changes merged in from other branches."
 339 msgstr ""
 340
 341 #. type: Plain text
 342 #: ../en/branch.txt:119
 343 msgid ""
 344 "You can refer to a specific parent with a caret. For example, to show the "
 345 "logs from the second parent:"
 346 msgstr ""
 347
 348 #. type: Plain text
 349 #: ../en/branch.txt:121
 350 #, no-wrap
 351 msgid " $ git log HEAD^2\n"
 352 msgstr ""
 353
 354 #. type: Plain text
 355 #: ../en/branch.txt:124
 356 msgid ""
 357 "You may omit the number for the first parent. For example, to show the "
 358 "differences with the first parent:"
 359 msgstr ""
 360
 361 #. type: Plain text
 362 #: ../en/branch.txt:126
 363 #, no-wrap
 364 msgid " $ git diff HEAD^\n"
 365 msgstr ""
 366
 367 #. type: Plain text
 368 #: ../en/branch.txt:128
 369 msgid "You can combine this notation with other types. For example:"
 370 msgstr ""
 371
 372 #. type: Plain text
 373 #: ../en/branch.txt:130
 374 #, no-wrap
 375 msgid " $ git checkout 1b6d^^2~10 -b ancient\n"
 376 msgstr ""
 377
 378 #. type: Plain text
 379 #: ../en/branch.txt:133
 380 msgid ""
 381 "starts a new branch ``ancient'' representing the state 10 commits back from "
 382 "the second parent of the first parent of the commit starting with 1b6d."
 383 msgstr ""
 384
 385 #. type: Plain text
 386 #: ../en/branch.txt:135
 387 msgid "=== Uninterrupted Workflow ==="
 388 msgstr ""
 389
 390 #. type: Plain text
 391 #: ../en/branch.txt:137
 392 msgid ""
 393 "Often in hardware projects, the second step of a plan must await the "
 394 "completion of the first step. A car undergoing repairs might sit idly in a "
 395 "garage until a particular part arrives from the factory. A prototype might "
 396 "wait for a chip to be fabricated before construction can continue."
 397 msgstr ""
 398
 399 #. type: Plain text
 400 #: ../en/branch.txt:142
 401 msgid ""
 402 "Software projects can be similar. The second part of a new feature may have "
 403 "to wait until the first part has been released and tested. Some projects "
 404 "require your code to be reviewed before accepting it, so you might wait "
 405 "until the first part is approved before starting the second part."
 406 msgstr ""
 407
 408 #. type: Plain text
 409 #: ../en/branch.txt:147
 410 msgid ""
 411 "Thanks to painless branching and merging, we can bend the rules and work on "
 412 "Part II before Part I is officially ready. Suppose you have committed Part I "
 413 "and sent it for review. Let's say you're in the `master` branch. Then branch "
 414 "off:"
 415 msgstr ""
 416
 417 #. type: Plain text
 418 #: ../en/branch.txt:149
 419 #, no-wrap
 420 msgid " $ git checkout -b part2\n"
 421 msgstr ""
 422
 423 #. type: Plain text
 424 #: ../en/branch.txt:153
 425 msgid ""
 426 "Next, work on Part II, committing your changes along the way. To err is "
 427 "human, and often you'll want to go back and fix something in Part I.  If "
 428 "you're lucky, or very good, you can skip these lines."
 429 msgstr ""
 430
 431 #. type: Plain text
 432 #: ../en/branch.txt:159
 433 #, no-wrap
 434 msgid ""
 435 " $ git checkout master  # Go back to Part I.\n"
 436 " $ fix_problem\n"
 437 " $ git commit -a        # Commit the fixes.\n"
 438 " $ git checkout part2   # Go back to Part II.\n"
 439 " $ git merge master     # Merge in those fixes.\n"
 440 msgstr ""
 441
 442 #. type: Plain text
 443 #: ../en/branch.txt:161
 444 msgid "Eventually, Part I is approved:"
 445 msgstr ""
 446
 447 #. type: Plain text
 448 #: ../en/branch.txt:166
 449 #, no-wrap
 450 msgid ""
 451 " $ git checkout master  # Go back to Part I.\n"
 452 " $ submit files         # Release to the world!\n"
 453 " $ git merge part2      # Merge in Part II.\n"
 454 " $ git branch -d part2\n"
 455 msgstr ""
 456
 457 #. type: Plain text
 458 #: ../en/branch.txt:168
 459 msgid ""
 460 "Now you're in the `master` branch again, with Part II in the working "
 461 "directory."
 462 msgstr ""
 463
 464 #. type: Plain text
 465 #: ../en/branch.txt:172
 466 msgid ""
 467 "It's easy to extend this trick for any number of parts. It's also easy to "
 468 "branch off retroactively: suppose you belatedly realize you should have "
 469 "created a branch 7 commits ago. Then type:"
 470 msgstr ""
 471
 472 #. type: Plain text
 473 #: ../en/branch.txt:176
 474 #, no-wrap
 475 msgid ""
 476 " $ git branch -m master part2\n"
 477 " $  # Rename \"master\" branch to \"part2\".\n"
 478 " $ git checkout HEAD~7 -b master\n"
 479 msgstr ""
 480
 481 #. type: Plain text
 482 #: ../en/branch.txt:179
 483 msgid ""
 484 "The `master` branch now contains just Part I, and the `part2` branch "
 485 "contains the rest."
 486 msgstr ""
 487
 488 #. type: Plain text
 489 #: ../en/branch.txt:181
 490 msgid "=== Reorganizing a Medley ==="
 491 msgstr ""
 492
 493 #. type: Plain text
 494 #: ../en/branch.txt:183
 495 msgid ""
 496 "Perhaps you like to work on all aspects of a project in the same branch. You "
 497 "want to keep works-in-progress to yourself and want others to see your "
 498 "commits only when they have been neatly organized. Start a couple of "
 499 "branches:"
 500 msgstr ""
 501
 502 #. type: Plain text
 503 #: ../en/branch.txt:186
 504 #, no-wrap
 505 msgid ""
 506 "  $ git checkout -b sanitized\n"
 507 "  $ git checkout -b medley\n"
 508 msgstr ""
 509
 510 #. type: Plain text
 511 #: ../en/branch.txt:188
 512 msgid ""
 513 "Next, work on anything: fix bugs, add features, add temporary code, and so "
 514 "forth, committing often along the way. Then:"
 515 msgstr ""
 516
 517 #. type: Plain text
 518 #: ../en/branch.txt:191
 519 #, no-wrap
 520 msgid ""
 521 "  $ git checkout sanitized\n"
 522 "  $ git cherry-pick medley^^\n"
 523 msgstr ""
 524
 525 #. type: Plain text
 526 #: ../en/branch.txt:193
 527 msgid ""
 528 "applies the grandparent of the head commit of the ``medley'' branch to the "
 529 "``sanitized'' branch. With appropriate cherry-picks you can construct a "
 530 "branch that contains only permanent code, and has related commits grouped "
 531 "together."
 532 msgstr ""
 533
 534 #. type: Plain text
 535 #: ../en/branch.txt:195
 536 msgid "=== Managing Branches ==="
 537 msgstr ""
 538
 539 #. type: Plain text
 540 #: ../en/branch.txt:197
 541 msgid "List all branches by typing:"
 542 msgstr ""
 543
 544 #. type: Plain text
 545 #: ../en/branch.txt:199
 546 #, no-wrap
 547 msgid " $ git branch\n"
 548 msgstr ""
 549
 550 #. type: Plain text
 551 #: ../en/branch.txt:202
 552 msgid ""
 553 "By default, you start in a branch named ``master''. Some advocate leaving "
 554 "the ``master'' branch untouched and creating new branches for your own edits."
 555 msgstr ""
 556
 557 #. type: Plain text
 558 #: ../en/branch.txt:205
 559 msgid ""
 560 "The *-d* and *-m* options allow you to delete and move (rename) branches.  "
 561 "See *git help branch*."
 562 msgstr ""
 563
 564 #. type: Plain text
 565 #: ../en/branch.txt:210
 566 msgid ""
 567 "The ``master'' branch is a useful custom. Others may assume that your "
 568 "repository has a branch with this name, and that it contains the official "
 569 "version of your project. Although you can rename or obliterate the "
 570 "``master'' branch, you might as well respect this convention."
 571 msgstr ""
 572
 573 #. type: Plain text
 574 #: ../en/branch.txt:212
 575 msgid "=== Temporary Branches ==="
 576 msgstr ""
 577
 578 #. type: Plain text
 579 #: ../en/branch.txt:217
 580 msgid ""
 581 "After a while you may realize you are creating short-lived branches "
 582 "frequently for similar reasons: every other branch merely serves to save the "
 583 "current state so you can briefly hop back to an older state to fix a high-"
 584 "priority bug or something."
 585 msgstr ""
 586
 587 #. type: Plain text
 588 #: ../en/branch.txt:222
 589 msgid ""
 590 "It's analogous to changing the TV channel temporarily to see what else is "
 591 "on.  But instead of pushing a couple of buttons, you have to create, check "
 592 "out, merge, and delete temporary branches. Luckily, Git has a shortcut that "
 593 "is as convenient as a TV remote control:"
 594 msgstr ""
 595
 596 #. type: Plain text
 597 #: ../en/branch.txt:224
 598 #, no-wrap
 599 msgid " $ git stash\n"
 600 msgstr ""
 601
 602 #. type: Plain text
 603 #: ../en/branch.txt:229
 604 msgid ""
 605 "This saves the current state in a temporary location (a 'stash') and "
 606 "restores the previous state. Your working directory appears exactly as it "
 607 "was before you started editing, and you can fix bugs, pull in upstream "
 608 "changes, and so on. When you want to go back to the stashed state, type:"
 609 msgstr ""
 610
 611 #. type: Plain text
 612 #: ../en/branch.txt:231
 613 #, no-wrap
 614 msgid " $ git stash apply  # You may need to resolve some conflicts.\n"
 615 msgstr ""
 616
 617 #. type: Plain text
 618 #: ../en/branch.txt:234
 619 msgid ""
 620 "You can have multiple stashes, and manipulate them in various ways. See *git "
 621 "help stash*. As you may have guessed, Git maintains branches behind the "
 622 "scenes to perform this magic trick."
 623 msgstr ""
 624
 625 #. type: Plain text
 626 #: ../en/branch.txt:236
 627 msgid "=== Work How You Want ==="
 628 msgstr ""
 629
 630 #. type: Plain text
 631 #: ../en/branch.txt:240
 632 msgid ""
 633 "You might wonder if branches are worth the bother. After all, clones are "
 634 "almost as fast, and you can switch between them with *cd* instead of "
 635 "esoteric Git commands."
 636 msgstr ""
 637
 638 #. type: Plain text
 639 #: ../en/branch.txt:246
 640 msgid ""
 641 "Consider web browsers. Why support multiple tabs as well as multiple "
 642 "windows? Because allowing both accommodates a wide variety of styles. Some "
 643 "users like to keep only one browser window open, and use tabs for multiple "
 644 "webpages. Others might insist on the other extreme: multiple windows with no "
 645 "tabs anywhere.  Others still prefer something in between."
 646 msgstr ""
 647
 648 #. type: Plain text
 649 #: ../en/branch.txt:250
 650 msgid ""
 651 "Branching is like tabs for your working directory, and cloning is like "
 652 "opening a new browser window. These operations are fast and local, so why "
 653 "not experiment to find the combination that best suits you? Git lets you "
 654 "work exactly how you want."
 655 msgstr ""