From 5369851e336b1d9571c818e7fd27cbd3ae62eeba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Sun, 29 Nov 2015 21:35:11 +0100 Subject: [PATCH 1/7] =?UTF-8?q?=C3=9Cbersetze=20Kapitel=203?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vollständige Übersetzung von Kapitel 3 mit Hilfe der Übersetzung der ersten Ausgabe. --- book/03-git-branching/1-git-branching.asc | 26 +- .../sections/basic-branching-and-merging.asc | 198 +++++++-------- .../sections/branch-management.asc | 30 +-- book/03-git-branching/sections/nutshell.asc | 160 ++++++------ book/03-git-branching/sections/rebasing.asc | 230 +++++++++--------- .../sections/remote-branches.asc | 162 ++++++------ book/03-git-branching/sections/workflows.asc | 78 +++--- 7 files changed, 451 insertions(+), 433 deletions(-) diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc index 77fb9e603..80fb8b581 100644 --- a/book/03-git-branching/1-git-branching.asc +++ b/book/03-git-branching/1-git-branching.asc @@ -2,15 +2,15 @@ == Git Branching (((branches))) -Nearly every VCS has some form of branching support. -Branching means you diverge from the main line of development and continue to do work without messing with that main line. -In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. +Nahezu jedes VCS unterstützt eine Form von Branching. +Branching bedeutet, dass Sie von der Hauptlinie der Entwicklung abzweigen und Ihre Arbeit fortsetzen, ohne an der Hauptlinie herumzubasteln. +Bei vielen VCS ist das ein etwas aufwendiger Prozess, welcher häufig von Ihnen verlangt, eine neue Kopie des kompletten Quellcodeverzeichnisses anzulegen, was bei großen Projekten viel Zeit in Anspruch nehmen kann. -Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community. -Why is it so special? -The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. -Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. -Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. +Manche Leute bezeichnen Gits Branching-Modell als dessen ``Killerfeature'', was Git zweifellos vom Rest der VCS-Community abhebt. +Was ist das Besondere daran? +Die Art und Weise, wie Git Branches anlegt, ist unglaublich leichtgewichtig, wodurch Branch-Operationen nahezu verzögerungsfrei ausgeführt werden und auch das Hin- und Herschalten zwischen einzelnen Entwicklungszweigen meist genauso schnell abläuft. +Im Gegensatz zu anderen VCS ermutigt Git zu einer Arbeitsweise mit häufigem Branching und Merging, sogar mehrmals am Tag. +Wenn Sie diese Funktion verstehen und beherrschen, besitzen Sie ein mächtiges und einmaliges Werkzeug, welches Ihre Art zu entwickeln vollständig verändern kann. include::sections/nutshell.asc[] @@ -24,9 +24,9 @@ include::sections/remote-branches.asc[] include::sections/rebasing.asc[] -=== Summary +=== Zusammenfassung -We've covered basic branching and merging in Git. -You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. -You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. -Next, we'll cover what you'll need to run your own Git repository-hosting server. +Wir haben einfaches Branching und Merging mit Git behandelt. +Es sollte Ihnen leicht fallen, neue Branches zu erstellen und zu diesen zu wechseln, zwischen bestehenden Branches zu wechseln und lokale Branches zusammenzuführen. +Außerdem sollten Sie in der Lage sein, Ihre Branches auf einem gemeinsam genutzten Server bereitzustellen, mit anderen an gemeinsam genutzten Branches zu arbeiten und Ihre Branches zu rebasen, bevor Sie diese bereitstellen. +Als Nächstes werden wir behandeln, was Sie benötigen, um einen eigenen Git-Repository-Hosting-Server zu betreiben. diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index cc3aa8908..35744bdfb 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,31 +1,31 @@ -=== Basic Branching and Merging +=== Grundlagen des Verzweigens und Zusammenführens -Let's go through a simple example of branching and merging with a workflow that you might use in the real world. -You'll follow these steps: +Lassen Sie uns ein einfaches Beispiel für das Verzweigen und Zusammenführen durchgehen, wie es Ihnen bei einem Arbeitsablauf in der realen Welt begegnen könnte. +Sie werden diesen Schritten folgen: -. Do work on a web site. -. Create a branch for a new story you're working on. -. Do some work in that branch. +. Erledigen von Arbeiten an einer Website. +. Erzeugen eines Branches für eine neue Geschichte, an der Sie gerade arbeiten. +. Durchführen einiger Arbeiten innerhalb des Branches. -At this stage, you'll receive a call that another issue is critical and you need a hotfix. -You'll do the following: +Zu diesem Zeitpunkt erhalten Sie einen Anruf, dass ein anderer Sachverhalt kritisch ist und Sie den Fehler schnell beheben müssen. +Sie werden Folgendes tun: -. Switch to your production branch. -. Create a branch to add the hotfix. -. After it's tested, merge the hotfix branch, and push to production. -. Switch back to your original story and continue working. +. Wechseln Sie zu Ihrem Produktionsbranch. +. Legen Sie einen neuen Branch an, um den Fehler zu beheben. +. Nachdem dies getestet wurde, integrieren Sie den Fehlerbehungsbranch und laden das Ganze in die Produktionsumgebung hoch. +. Wechseln Sie zurück zu Ihrer ursprünglichen Geschichte und arbeiten Sie weiter daran. [[_basic_branching]] -==== Basic Branching +==== Grundlagen des Verzweigens (((branches, basic workflow))) -First, let's say you're working on your project and have a couple of commits already. +Lassen Sie uns zunächst annehmen, Sie arbeiten an Ihrem Projekt und haben bereits ein paar Commits gemacht. -.A simple commit history -image::images/basic-branching-1.png[A simple commit history.] +.Ein einfacher Commit-Verlauf +image::images/basic-branching-1.png[Ein einfacher Commit-Verlauf.] -You've decided that you're going to work on issue #53 in whatever issue-tracking system your company uses. -To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: +Sie haben sich dafür entschieden, an Sachverhalt #53 zu arbeiten in irgendeinem Fehlerverfolgunssystem, dass Ihre Firma benutzt. +Um einen neuen Branch anzulegen und gleichzeitig zu diesem zu wechseln, können Sie die Anweisung `git checkout` zusammen mit der Option `-b` ausführen: [source,console] ---- @@ -33,7 +33,7 @@ $ git checkout -b iss53 Switched to a new branch "iss53" ---- -This is shorthand for: +Das ist die Kurzversion von: [source,console] ---- @@ -41,11 +41,11 @@ $ git branch iss53 $ git checkout iss53 ---- -.Creating a new branch pointer -image::images/basic-branching-2.png[Creating a new branch pointer.] +.Erzeugen eines neuen Branch-Zeigers +image::images/basic-branching-2.png[Erzeugen eines neuen Branch-Zeigers.] -You work on your web site and do some commits. -Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): +Sie arbeiten an Ihrer Website und führen einige Commits durch. +Wenn Sie das machen, bewegt das den `iss53`-Branch vorwärts, weil Sie ihn ausgecheckt haben (das bedeutet, Ihr `HEAD` zeigt auf diesen Branch): [source,console] ---- @@ -53,17 +53,17 @@ $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' ---- -.The iss53 branch has moved forward with your work -image::images/basic-branching-3.png[The iss53 branch has moved forward with your work.] +.Der iss53-Branch hat sich bei Ihrer Arbeit vorwärts bewegt +image::images/basic-branching-3.png[Der iss53-Branch hat sich bei Ihrer Arbeit vorwärts bewegt.] -Now you get the call that there is an issue with the web site, and you need to fix it immediately. -With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. -All you have to do is switch back to your `master` branch. +Jetzt bekommen Sie den Anruf, dass es ein Problem mit der Website gibt und Sie es umgehend beheben müssen. +Bei Git müssen Sie die Fehlerbehebung nicht zusammen mit den Änderungen bereitstellen, die Sie bereits an `iss53` vorgenommen haben, und Sie müssen auch keinen großen Aufwand damit betreiben, diese Änderungen rückgängig zu machen, bevor Sie daran arbeiten können, Ihre Fehlerbehebung auf das anzuwenden, was sich in der Produktionsumgebung befindet. +Alles, was Sie machen müssen, ist, zu Ihrem `master`-Branch zurück zu wechseln. -However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches. -It's best to have a clean working state when you switch branches. -There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <<_git_stashing>>. -For now, let's assume you've committed all your changes, so you can switch back to your master branch: +Bevor Sie das tun, beachten Sie jedoch, dass Git Sie nicht die Branches wechseln lassen wird, wenn in Ihrem Arbeitsverzeichnis oder Ihrem Index Änderungen existieren, welche Konflikte mit dem Branch erzeugen können, den Sie gerade auschecken. +Am besten ist es, einen sauberen Arbeitsstatus zu haben, wenn Sie die Branches wechseln. +Es gibt Möglichkeiten, dies zu umzugehen (namentlich sogenanntes Stashing und das Abändern von Commits), was wir später in <<_git_stashing>> behandeln. +Lassen Sie uns vorerst annehmen, Sie haben für alle Ihre Änderungen Commits durchgeführt, sodass Sie zu Ihrem `master`-Branch zurück wechseln können. [source,console] ---- @@ -71,12 +71,12 @@ $ git checkout master Switched to branch 'master' ---- -At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. -This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. -It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. +Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, bevor Sie mit der Arbeit an Sachverhalt #53 begonnen haben und Sie können sich direkt auf die Fehlerbehebung konzentrieren. +Dabei sollte man diesen wichtigen Punkt bedenken: wenn Sie die Branches wechseln, setzt Git Ihr Arbeitsverzeichnis zurück, um genauso auszusehen, wie zu dem Zeitpunkt, als Sie den letzten Commit auf diesem Branch durchgeführt haben. +Dateien werden automatisch hinzugefügt, entfernt und verändert, um sicherzustellen, dass Ihre Arbeitskopie auf dem selben Stand ist wie zum Zeitpunkt Ihres letzten Commits auf diesem Branch. -Next, you have a hotfix to make. -Let's create a hotfix branch on which to work until it's completed: +Als Nächstes müssen Sie sich um die Fehlerbehebung kümmern. +Lassen Sie uns einen Branch namens ``hotfix'' erstellen, an dem Sie bis zu dessen Fertigstellung arbeiten. [source,console] ---- @@ -88,11 +88,11 @@ $ git commit -a -m 'fixed the broken email address' 1 file changed, 2 insertions(+) ---- -.Hotfix branch based on `master` -image::images/basic-branching-4.png[Hotfix branch based on `master`.] +.Auf `master`-Branch basierender hotfix-Branch +image::images/basic-branching-4.png[Auf `master`-Branch basierender hotfix-Branch.] -You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. -You do this with the `git merge` command:(((git commands, merge))) +Sie können Ihre Tests durchführen und sicherstellen, dass der Hotfix seinen Zweck erfüllt und ihn dann mit dem master-Branch zusammenführen, um ihn in die Produktionsumgebung zu integrieren. +Das machen Sie mit der Anweisung `git merge`:(((git commands, merge))) [source,console] ---- @@ -104,18 +104,18 @@ Fast-forward 1 file changed, 2 insertions(+) ---- -You'll notice the phrase ``fast-forward'' in that merge. -Because the commit pointed to by the branch you merged in was directly upstream of the commit you're on, Git simply moves the pointer forward. -To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward.'' +Ihnen wird bei diesem Zusammenführen der Ausdruck ``fast-forward'' auffallen. +Da der Commit, auf den der Branch zeigte, den Sie integriert haben, unmittelbar von dem letzten Commit abstammt, auf dem Sie sich befinden, bewegt Git den Zeiger einfach weiter. +Um es anders auszudrücken, wenn Sie versuchen, einen Commit mit einem anderen Commit zu verschmelzen, welcher erreicht werden kann, in dem man einfach dem Commit-Verlauf des ersteren Commits folgt, dann vereinfacht Git die Dinge durch Vorwärtsbewegen des Zeigers, weil es sich hier nicht um auseinanderlaufende Entwicklungsstränge handelt, die miteinander zu verschmelzen sind - dies wird ``fast-forward'' genannt. -Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. +Ihre Änderung befindet sich nun im Schnappschuss des Commits, auf den der `master`-Branch zeigt und Sie können Ihre Fehlerbehebung anwenden. -.`master` is fast-forwarded to `hotfix` -image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.] +.`master` wurde vorgespult zu `hotfix` +image::images/basic-branching-5.png[`master` wurde vorgespult zu `hotfix`.] -After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted. -However, first you'll delete the `hotfix` branch, because you no longer need it – the `master` branch points at the same place. -You can delete it with the `-d` option to `git branch`: +Nachdem Ihre überaus wichtige Fehlerbehebung bereitgestellt wurde, können Sie sich wieder dem zuwenden, woran Sie gerade arbeiteten, als Sie unterbrochen wurden. +Zunächst werden Sie jedoch den `hotfix`-Branch löschen, weil Sie diesen nicht länger benötigen - schließlich verweist der `master`-Branch auf den selben Entwicklungsstand. +Sie können ihn löschen, in dem Sie die Anweisung `git branch` mit der Option `-d` ausführen: [source,console] ---- @@ -123,7 +123,7 @@ $ git branch -d hotfix Deleted branch hotfix (3a0874c). ---- -Now you can switch back to your work-in-progress branch on issue #53 and continue working on it. +Jetzt können Sie zu dem Branch zurückwechseln, auf dem Sie mit Ihren Arbeiten an Sachverhalt #53 begonnen haben, und daran weiter arbeiten. [source,console] ---- @@ -135,19 +135,22 @@ $ git commit -a -m 'finished the new footer [issue 53]' 1 file changed, 1 insertion(+) ---- -.Work continues on `iss53` -image::images/basic-branching-6.png[Work continues on `iss53`.] +.Weitergeführte Arbeiten an `iss53` +image::images/basic-branching-6.png[Weitergeführte Arbeiten an `iss53`.] It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. +An dieser Stelle ist anzumerken, dass die Änderung, welche Sie auf Ihrem `hotfix`-Branch vorgenommen haben, nicht in den Dateien Ihres `iss53`-Branches enthalten ist. +Wenn Sie diese einfließen lassen müssen, können Sie Ihren `master`-Branch mit der Anweisung `git merge master` mit Ihrem `iss53`-Branch zusammenführen, oder Sie können damit warten, diese Änderungen zu integrieren, bis Sie entscheiden, den `iss53`-Branch später in den `master`-Branch zurückzuführen. + [[_basic_merging]] -==== Basic Merging +==== Grundlagen des Zusammenführens (((branches, merging)))(((merging))) -Suppose you've decided that your issue #53 work is complete and ready to be merged into your `master` branch. -In order to do that, you'll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. -All you have to do is check out the branch you wish to merge into and then run the `git merge` command: +Angenommen, Sie haben entschieden, dass Ihre Arbeiten an Sachverhalt #53 abgeschlossen sind und das Ganze soweit ist, dass es mit dem `master` Branch zusammengeführt werden kann. +Um das zu tun, werden Sie Ihren `iss53`-Branch in den `master`-Branch einfließen lassen, genauso wie Sie es zuvor mit dem `hotfix`-Branch getan haben. +Sie müssen nur mit der Anweisung `checkout` zum dem Branch zu wechseln, in welchen Sie etwas einfließen lassen wollen und dann die Anweisung `git merge` ausführen: [source,console] ---- @@ -159,25 +162,26 @@ index.html | 1 + 1 file changed, 1 insertion(+) ---- -This looks a bit different than the `hotfix` merge you did earlier. -In this case, your development history has diverged from some older point. -Because the commit on the branch you're on isn't a direct ancestor of the branch you're merging in, Git has to do some work. -In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. +Das sieht ein bisschen anders aus, als das Zusammenführen mit dem `hotfix`-Branch, dass Sie zuvor gemacht haben. +Die Entwicklungsstränge haben sich in diesem Fall schon zu einem früheren Zeitpunkt geteilt. +Da der `commit` auf dem Branch, auf dem Sie sich befinden, kein direkter Vorgänger von dem Branch ist, in den Sie etwas einfließem lassen wollen, hat Git einiges zu tun. +In diesem Fall führt Git ein einfaches 3-Wege-`merge` durch, wobei es die beiden Schnappschüsse verwendet, auf welche die Enden der Branches zeigen, und den gemeinsamen Vorgänger dieser beiden. + +.Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden. +image::images/basic-merging-1.png[Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden.] -.Three snapshots used in a typical merge -image::images/basic-merging-1.png[Three snapshots used in a typical merge.] +Anstatt einfach den Zeiger des Branches vorwärts zu bewegen, erstellt Git einen neuen Schnappschuss, der aus dem 3-Wege-`merge` resultiert und erzeugt automatisch einen neuen `commit`, der darauf zeigt. +Dieser wird auch als `merge commit` bezeichnet und ist ein Spezialfall, weil er mehr als nur einen Elternteil hat. -Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. -This is referred to as a merge commit, and is special in that it has more than one parent. +.Ein `merge commit` +image::images/basic-merging-2.png[Ein `merge commit`.] -.A merge commit -image::images/basic-merging-2.png[A merge commit.] +Es ist wichtig herauszustellen, dass Git den besten gemeinsamen Vorgänger als Grundlage für das Zusammenführen bestimmt, denn hierin unterscheidet es sich von älteren Werkzeugen wie CVS oder Subversion (vor Version 1.5), wo der Entwickler beim Zusammenführen die `merge`-Basis selbst ermitteln musste. +In Git ist das Zusammenführen dadurch wesentlich einfacher, als in diesen anderen Systemen. -It's worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than older tools like CVS or Subversion (before version 1.5), where the developer doing the merge had to figure out the best merge base for themselves. -This makes merging a heck of a lot easier in Git than in these other systems. +Da Ihre Änderungen jetzt eingeflossen sind, haben Sie keinen weiteren Bedarf mehr für den `iss53`-Branch. -Now that your work is merged in, you have no further need for the `iss53` branch. -You can close the ticket in your ticket-tracking system, and delete the branch: +Sie können das Ticket in Ihrem Ticket-Tracking-System schließen und den Branch löschen: [source,console] ---- @@ -185,12 +189,12 @@ $ git branch -d iss53 ---- [[_basic_merge_conflicts]] -==== Basic Merge Conflicts +==== Grundlegende Konflikte bei Zusammenführen (((merging, conflicts))) -Occasionally, this process doesn't go smoothly. -If you changed the same part of the same file differently in the two branches you're merging together, Git won't be able to merge them cleanly. -If your fix for issue #53 modified the same part of a file as the `hotfix`, you'll get a merge conflict that looks something like this: +Gelegentlich verläuft der Prozess nicht ganz so reibungslos. +Wenn Sie in den beiden Branches, die Sie zusammenführen wollen, an der selben Stelle in der selben Datei unterschiedliche Änderungen vorgenommen haben, wird Git nicht in der Lage sein, diese sauber zusammenzuführen. +Wenn Ihre Änderungen bezüglich Sachverhalt #53 die selbe Stelle in einer Datei betreffen wie beim `hotfix`-Branch, werden Sie einen `merge`-Konflikt bekommen, der ungefähr so aussehen könnte: [source,console] ---- @@ -200,9 +204,9 @@ CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. ---- -Git hasn't automatically created a new merge commit. -It has paused the process while you resolve the conflict. -If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: +Git hat nicht automatisch einen neuen 'merge commit' erstellt. +Es hat den Prozess angehalten, solange Sie den Konflikt beseitigen. +Wenn Sie zu einem beliebigen Zeitpunkt nach einem `merge`-Konflikt sehen wollen, welche Dateien nicht zusammengeführt werden konnten (den Status `unmerged` haben), können Sie die Anweisung `git status` ausführen: [source,console] ---- @@ -219,9 +223,9 @@ Unmerged paths: no changes added to commit (use "git add" and/or "git commit -a") ---- -Anything that has merge conflicts and hasn't been resolved is listed as unmerged. -Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. -Your file contains a section that looks something like this: +Alles, was `merge`-Konflikte aufweist und nicht gelöst wurde, wird als `unmerged` aufgeführt. +Git fügt den betroffenen Dateien Standardmarkierungen zur Konfliktlösung hinzu, so können Sie diese Dateien öffnen und diese Konflikte manuell lösen . +Ihre Datei enthält einen Abschnitt, der ungefährt so aussieht: [source,html] ---- @@ -234,9 +238,9 @@ Your file contains a section that looks something like this: >>>>>>> iss53:index.html ---- -This means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. -In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. -For instance, you might resolve this conflict by replacing the entire block with this: +Das heißt, die Version in `HEAD` (Ihres `master`-Branches, denn der wurde per `checkout` aktiviert, als Sie das `merge` gemacht haben) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. +Um den Konflikt zu lösen, müssen Sie sich entweder für einen der beiden Teile entscheiden oder Sie führen die Inhalte selbst zusammen. +Sie könnten diesen Konflikt lösen, indem Sie den kompletten Block zum Beispiel damit ersetzen: [source,html] ---- @@ -245,11 +249,11 @@ please contact us at email.support@github.com ---- -This resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. -After you've resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. -Staging the file marks it as resolved in Git. +Diese Lösung hat von beiden Teilen etwas und die Zeilen mit `<<<<<<<`, `=======`, und `>>>>>>>` wurden vollständig entfernt. +Nachdem Sie alle problematischen Bereiche in allen von dem Konflikt betroffenen Dateien beseitigt haben, führen Sie einfach die Anweisung `git add` für alle betroffenen Dateien aus, um sie als gelöst zu markieren. +Dieses 'staging' der Dateien markiert sie für Git als bereinigt. -If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:(((git commands, mergetool))) +Wenn Sie ein grafisches Tool benutzen möchten, um die Probleme zu lösen, dann können Sie `git mergetool` verwenden, welches ein passendes grafisches `merge`-Tool startet und Sie durch die Konfliktbereiche führt:(((git commands, mergetool))) [source,console] ---- @@ -268,17 +272,17 @@ Normal merge conflict for 'index.html': Hit return to start merge resolution tool (opendiff): ---- -If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on a Mac), you can see all the supported tools listed at the top after ``one of the following tools.'' -Just type the name of the tool you'd rather use. +Wenn Sie ein anderes `merge`-Tool anstelle des Standardwerkzeugs verwenden möchten (Git wählte in diesem Fall `opendiff`, da die Anweisung auf einem Mac ausgeführt wurde), dann können Sie alle unterstützten Werkzeuge oben – unter ``one of the following tools'' – aufgelistet sehen. +Tippen Sie einfach den Namen Ihres gewünschten Werkzeugs ein. [NOTE] ==== -If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <<_advanced_merging>>. +Wenn Sie anspruchsvollere Werkzeuge zur Lösung komplizierter `merge`-Konflikte benötigen, wir beschäftigen uns ausführlicher mit dem Zusammenführen in <<_advanced_merging>>. ==== -After you exit the merge tool, Git asks you if the merge was successful. -If you tell the script that it was, it stages the file to mark it as resolved for you. -You can run `git status` again to verify that all conflicts have been resolved: +Nachdem Sie das `merge`-Werkzeug beendet haben, werden Sie von Git gefragt, ob das Zusammenführen erfolgreich war. +Wenn Sie dem Skript ausrichten, dass es das war, fügt es die Datei zum Index hinzu, um diese für Sie als gelöst zu markieren. +Sie können die Anweisung `git status` erneut ausführen, um zu prüfen, dass alle Konflikte gelöst wurden: [source,console] ---- @@ -292,8 +296,8 @@ Changes to be committed: modified: index.html ---- -If you're happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. -The commit message by default looks something like this: +Wenn Sie damit zufrieden sind und Sie geprüft haben, dass alles, was Konflikte aufwies, zum Index hinzugefügt wurde, können Sie die Anweisung `git commit` ausführen, um den `merge commit` abzuschließen. +Die standardmäßige Commit-Nachricht sieht ungefähr so aus: [source,console] ---- @@ -318,4 +322,4 @@ Conflicts: # ---- -You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future – why you did what you did, if it's not obvious. +Sie können dieser Commit-Nachricht noch Details darüber hinzufügen, wie Sie das Zusammenführen gelöst haben, wenn Sie denken, es könnte für künftige Betrachter dieses Commits hilfreich sein zu erklären, warum Sie getan haben, was Sie getan haben, falls es nicht offensichtlich ist. \ No newline at end of file diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index a8776bb25..ba26fcdbd 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -1,11 +1,11 @@ [[_branch_management]] -=== Branch Management +=== Branch-Management (((branches, managing))) -Now that you've created, merged, and deleted some branches, let's look at some branch-management tools that will come in handy when you begin using branches all the time. +Nachdem Sie nun einige Branches erzeugt, zusammengeführt und gelöscht haben, lassen Sie uns jetzt einige Werkzeuge für das Branch-Management betrachten, die sich als sehr nützlich erweisen werden, wenn Sie erst einmal damit anfangen, andauernd Branches zu benutzen. -The `git branch` command does more than just create and delete branches.(((git commands, branch))) -If you run it with no arguments, you get a simple listing of your current branches: +Die Anweisung `git branch` kann noch mehr, als Branches zu erzeugen und zu löschen.(((git commands, branch))) +Wenn Sie die Anweisung ohne Argumente ausführen, bekommen Sie eine einfache Auflistung Ihrer aktuellen Branches: [source,console] ---- @@ -15,9 +15,9 @@ $ git branch testing ---- -Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out (i.e., the branch that `HEAD` points to). -This means that if you commit at this point, the `master` branch will be moved forward with your new work. -To see the last commit on each branch, you can run `git branch -v`: +Beachten Sie das `*`-Zeichen, dass dem `master`-Branch vorangestellt ist: es zeigt an, welchen Branch Sie gegenwärtig ausgecheckt haben (bzw. den Branch, auf den `HEAD` zeigt). +Wenn Sie zu diesem Zeitpunkt einen Commit durchführen, wird der `master`-Branch durch Ihre neue Änderung vorwärts bewegt. +Um sich den letzten Commit auf jedem Branch anzeigen zu lassen, können Sie die Anweisung `git branch -v` ausführen: [source,console] ---- @@ -27,8 +27,8 @@ $ git branch -v testing 782fd34 add scott to the author list in the readmes ---- -The useful `--merged` and `--no-merged` options can filter this list to branches that you have or have not yet merged into the branch you're currently on. -To see which branches are already merged into the branch you're on, you can run `git branch --merged`: +Die nützlichen Optionen `--merged` und `--no-merged` können diese Liste nach Branches filtern, welche bereits mit dem Branch, auf dem Sie sich gegenwärtig befinden, zusammengeführt wurden und welche nicht. +Um zu sehen, welche Branches schon mit dem Branch zusammengeführt wurden, auf dem sie gerade sind, können Sie die Anweisung `git branch --merged` ausführen: [source,console] ---- @@ -37,10 +37,10 @@ $ git branch --merged * master ---- -Because you already merged in `iss53` earlier, you see it in your list. -Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you've already incorporated their work into another branch, so you're not going to lose anything. +Da Sie den Branch `iss53` schon früher einfließen lassen haben, sehen Sie ihn in Ihrer Liste. +Branches auf dieser Liste ohne vorangestelltes `*` können für gewöhnlich einfach mit der Anweisung `git branch -d` gelöscht werden; Sie haben deren Änderungen bereits zu einem anderen Branch hinzugefügt, sodass Sie nichts verlieren würden. -To see all the branches that contain work you haven't yet merged in, you can run `git branch --no-merged`: +Um alle Branches zu sehen, welche Änderungen enhalten, die Sie noch nicht integriert haben, können Sie die Anweisung `git branch --no-merged` ausführen: [source,console] ---- @@ -48,8 +48,8 @@ $ git branch --no-merged testing ---- -This shows your other branch. -Because it contains work that isn't merged in yet, trying to delete it with `git branch -d` will fail: +Dies zeigt Ihren anderen Branch. +Da er Änderungen enthält, die noch nicht integriert wurden, würde der Versuch, ihn mit `git branch -d` zu löschen, fehlschlagen: [source,console] ---- @@ -58,4 +58,4 @@ error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. ---- -If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out. +Wenn Sie den Branch tatsächlich löschen und damit diese Änderungen verlieren wollen, können Sie die Anweisung mit der Option `-D` verstärken, worauf auch die hilfreiche Nachricht hinweist. \ No newline at end of file diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 846518bd6..db3d822ad 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -1,15 +1,15 @@ [[_git_branches_overview]] -=== Branches in a Nutshell +=== Branches in aller Kürze -To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. +Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Schritt zurückgehen und untersuchen, wie Git seine Daten speichert. -As you may remember from <<_getting_started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots. +Wie Sie vielleicht von <<_getting_started>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von Momentaufnahmen. -When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. -This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. +Wenn Sie einen Commit anlegen, dann speichert Git ein `commit`-Objekt, welches einen Zeiger zu der Momentaufnahme der Inhalte enthält, welche sich in der Staging Area bzw. im Index befinden. +Dieses Objekt beinhaltet den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und Zeiger zu dem Commit oder den Commits, welche direkt vor diesem Commit gemacht wurden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welche aus dem Zusammenführen von zwei oder mehr Branches resultiert. -To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit. -Staging the files checksums each one (the SHA-1 hash we mentioned in <<_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: +Um das zu veranschaulichen, lassen Sie uns annehmen, Sie haben ein Verzeichnis, welches drei Dateien enthält, und Sie fügen alle Dateien zur Staging-Area hinzu und führen einen Commit durch. +Durch das Hinzufügen der Dateien zur Staging Area erzeugt Git für jede Datei eine Prüfsumme (den SHA-1-Hashwert, den wir in <<_getting_started>> erwähnt haben), speichert diese Version der Datei im Git-Repository (Git verweist auf diese als Blobs) und fügt die Prüfsumme der Staging-Area hinzu: [source,console] ---- @@ -17,64 +17,64 @@ $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' ---- -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. -Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.(((git commands, commit))) +Wenn Sie mit der Anweisung `git commit` einen Commit erzeugen, berechnet Git für jedes Unterverzeichnis (in diesem Fall nur das Wurzelverzeichnis des Projektes) eine Prüfsumme und speichert diese als `tree`-Objekte im Git-Repository. +Git erzeugt dann ein `commit`-Objekt, welches die Metadaten und einen Zeiger zum `tree`-Objekt des Wurzelverzeichnisses enthält, sodass es bei Bedarf die Momentaufnahme erneut erzeugen kann.(((git commands, commit))) -Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. +Ihr Git-Repository enthält jetzt fünf Objekte: je einen Blob für die Inhalte von jeder Ihrer drei Dateien, ein `tree`-Objekt, welches den Inhalt des Verzeichnisses auflistet und angibt, welcher Dateiname zu welchem Blob gehört, und ein `commit`-Objekt mit dem Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. -.A commit and its tree -image::images/commit-and-tree.png[A commit and its tree.] +.Ein Commit und sein Tree +image::images/commit-and-tree.png[Ein Commit und sein Tree.] -If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. +Wenn Sie einige Änderungen vornehmen und wieder einen Commit durchführen, speichert dieser einen Zeiger zu dem Commit, der unmittelbar davor gemacht wurde. -.Commits and their parents -image::images/commits-and-parents.png[Commits and their parents.] +.Commits und ihre Vorgänger +image::images/commits-and-parents.png[Commits und ihre Vorgänger.] -A branch in Git is simply a lightweight movable pointer to one of these commits. -The default branch name in Git is `master`. -As you start making commits, you're given a master branch that points to the last commit you made. -Every time you commit, it moves forward automatically. +Ein Branch ist bei Git einfach ein leichtgewichtiger beweglicher Zeiger zu einem von diesen Commits. +Die Standardbezeichnung für einen Branch bei Git lautet `master`. +Wenn Sie damit beginnen, Commits durchzuführen, erhalten Sie einen `master`-Branch, der auf den letzten Commit zeigt, den Sie gemacht haben. +Jedes Mal, wenn Sie einen Commit durchführen, bewegt er sich automatisch vorwärts. [NOTE] ==== -The ``master'' branch in Git is not a special branch.(((master))) -It is exactly like any other branch. -The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it. +Der ``master''-Branch in Git ist kein spezieller Branch.(((master))) +Er ist genau wie jeder andere Branch. +Der einzige Grund dafür, dass nahezu jedes Repository einen ``master''-Branch hat, ist der Umstand, dass die Anweisung `git init` diesen standardmäßig erzeugt und die meisten Leute sich nicht darum kümmern, den Namen zu ändern. ==== -.A branch and its commit history -image::images/branch-and-history.png[A branch and its commit history.] +.Ein Branch und sein Commit-Verlauf +image::images/branch-and-history.png[Ein Branch und sein Commit-Verlauf.] [[_create_new_branch]] -==== Creating a New Branch +==== Erzeugen eines neuen Branches (((branches, creating))) -What happens if you create a new branch? -Well, doing so creates a new pointer for you to move around. -Let's say you create a new branch called testing. -You do this with the `git branch` command:(((git commands, branch))) +Was passiert, wenn Sie einen neuen Branch erzeugen? +Nun, dabei wird ein neuer Zeiger für Sie erzeugt. +Sagen wir, Sie erzeugen einen neuen Branch mit dem Namen ``testing''. +Das machen Sie mit der Anweisung `git branch`:(((git commands, branch))) [source,console] ---- $ git branch testing ---- -This creates a new pointer at the same commit you're currently on. +Dies erzeugt einen neuen Zeiger, der auf den selben Commit zeigt, auf dem Sie sich gegenwärtig befinden. -.Two branches pointing into the same series of commits -image::images/two-branches.png[Two branches pointing into the same series of commits.] +.Zwei Branches, die auf die selbe Serie von Commits zeigen +image::images/two-branches.png[Zwei Branches, die auf die selbe Serie von Commits zeigen.] -How does Git know what branch you're currently on? -It keeps a special pointer called `HEAD`. -Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. -In Git, this is a pointer to the local branch you're currently on. -In this case, you're still on master. -The `git branch` command only _created_ a new branch – it didn't switch to that branch. +Woher weiß Git, auf welchem Branch Sie gegenwärtig sind? +Es besitzt einen speziellen Zeiger namens `HEAD`. +Beachten Sie, dass dieser `HEAD` sich sehr stark unterscheidet von den `HEAD`-Konzepten anderer Versionsverwaltungen, mit denen Sie vielleicht vertraut sind, wie Subversion oder CVS. +Bei Git handelt es sich bei `HEAD` um einen Zeiger auf den lokalen Branch, auf dem Sie sich gegenwärtig befinden. +In diesem Fall sind Sie noch auf dem `master`-Branch. +Die Anweisung `git branch` hat den neuen Branch nur _erzeugt_, aber nicht zu diesem gewechselt. -.HEAD pointing to a branch -image::images/head-to-master.png[HEAD pointing to a branch.] +.Auf einen Branch zeigender HEAD +image::images/head-to-master.png[Auf einen Branch zeigender HEAD.] -You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`. +Sie können dies ganz einfach sehen, indem Sie eine einfache `git log`-Anweisung ausführen, welche Ihnen zeigt, wohin die Zeiger der Branches zeigen. Diese Option hat den Namen `--decorate`. [source,console] ---- @@ -84,27 +84,27 @@ f30ab (HEAD, master, testing) add feature #32 - ability to add new 98ca9 initial commit of my project ---- -You can see the ``master'' and ``testing'' branches that are right there next to the `f30ab` commit. +Sie können die ``master''- und ``testing''-Branches sehen, welche dort direkt neben dem Commit `f30ab` sind. [[_switching_branches]] -==== Switching Branches +==== Wechseln der Branches (((branches, switching))) -To switch to an existing branch, you run the `git checkout` command.(((git commands, checkout))) -Let's switch to the new testing branch: +Um zu einem existierenden Branch zu wechseln, führen Sie die Anweisung `git checkout` aus.(((git commands, checkout))) +Lassen Sie uns zu dem neuen `testing`-Branch wechseln. [source,console] ---- $ git checkout testing ---- -This moves `HEAD` to point to the `testing` branch. +Dies bewegt `HEAD` dazu, auf den `testing`-Branch zu zeigen. -.HEAD points to the current branch -image::images/head-to-testing.png[HEAD points to the current branch.] +.HEAD zeigt auf den aktuellen Branch +image::images/head-to-testing.png[HEAD zeigt auf den aktuellen Branch.] -What is the significance of that? -Well, let's do another commit: +Was bedeutet das? +Nun, lassen Sie und einen weiteren Commit durchführen. [source,console] ---- @@ -112,34 +112,34 @@ $ vim test.rb $ git commit -a -m 'made a change' ---- -.The HEAD branch moves forward when a commit is made -image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.] +.Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird +image::images/advance-testing.png[Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird.] -This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran `git checkout` to switch branches. -Let's switch back to the master branch: +Das ist interessant, weil sich jetzt Ihr `testing`-Branch vorwärts bewegt hat, aber Ihr `master`-Branch noch auf den Commit zeigt, auf dem Sie sich befanden, als Sie die Anweisung `git checkout` ausführten, um die Branches zu wechseln. +Lassen Sie uns zurückwechseln zum `master`-Branch. [source,console] ---- $ git checkout master ---- -.HEAD moves when you checkout -image::images/checkout-master.png[HEAD moves when you checkout.] +.HEAD bewegt sich, wenn Sie auschecken +image::images/checkout-master.png[HEAD bewegt sich, wenn Sie auschecken.] -That command did two things. -It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. -This also means the changes you make from this point forward will diverge from an older version of the project. -It essentially rewinds the work you've done in your testing branch so you can go in a different direction. +Diese Anweisung hat zwei Dinge bewirkt. +Sie hat den Zeiger `HEAD` zurückbewegt, um auf den `master`-Branch zu zeigen, und sie verwandelte die Dateien in Ihrem Arbeitsverzeichnis zurück in den Zustand zum Zeitpunkt der Momentaufnahme, auf welche der `master`-Branch zeigt. +Dies bedeutet auch, dass die Änderungen, die Sie von diesem Punkt aus vornehmen, von einer älteren Verion des Projekts abzweigen werden. +Sie macht im Grunde genommen die Änderungen rückgängig, die Sie auf Ihrem `testing`-Branch vorgenommen haben, sodass Sie in eine andere Richtung gehen können. [NOTE] -.Switching branches changes files in your working directory +.Wechseln der Branches ändert Dateien in Ihrem Arbeitsverzeichnis ==== -It's important to note that when you switch branches in Git, files in your working directory will change. -If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. -If Git cannot do it cleanly, it will not let you switch at all. +Es ist wichtig zu beachten, dass sich die Dateien in Ihrem Arbeitsverzeichnis verändern, wenn Sie in Git die Branches wechseln. +Wenn Sie zu einem älteren Branch wechseln, wird Ihr Arbeitsverzeichnis zurückverwandelt, sodass es aussieht wie zu dem Zeitpunkt, als Sie Ihren letzten Commit auf diesem Branch durchgeführt haben. +Wenn Git das nicht problemlos durchführen kann, lässt es Sie die Branches überhaupt nicht wechseln. ==== -Let's make a few changes and commit again: +Lassen Sie uns ein paar Änderungen vornehmen und noch einen Commit durchführen: [source,console] ---- @@ -147,17 +147,17 @@ $ vim test.rb $ git commit -a -m 'made other changes' ---- -Now your project history has diverged (see <>). -You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. -Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you're ready. -And you did all that with simple `branch`, `checkout`, and `commit` commands. +Jetzt hat sich Ihr Projektverlauf verzweigt (see <>). +Sie erzeugten einen Branch und wechselten zu diesem, arbeiteten etwas daran, und dann wechselten Sie zurück zu Ihrem Hauptzweig und erledigten andere Arbeiten. +Beide Änderungen existieren getrennt voneinander in separaten Branches: Sie können zwischen den beiden Branches hin und her wechseln und diese zusammenführen, wenn Sie fertig sind. +Und das alles haben Sie mit einfachen `branch`-, `checkout`- und `commit`-Anweisungen gemacht. [[divergent_history]] -.Divergent history -image::images/advance-master.png[Divergent history.] +.Verzweigter Verlauf +image::images/advance-master.png[Verzweigter Verlauf.] -You can also see this easily with the `git log` command. -If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. +Sie können sich dies auch mühelos ansehen, wenn Sie die Anweisung `git log` ausführen. +Wenn Sie die Anweisung `git log --oneline --decorate --graph --all`, wird Ihnen der Verlauf von Ihren Commits so angezeigt, dass erkennbar ist, wo Ihre Branch-Zeiger sich befinden und wie Ihr Verlauf sich verzweigt hat. [source,console] ---- @@ -170,12 +170,12 @@ $ git log --oneline --decorate --graph --all * 98ca9 initial commit of my project ---- -Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. -Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). +Da ein Branch in Git in Wirklichkeit eine einfache Datei ist, welche die 40 Zeichen lange SHA-1-Prüfsumme des Commits enthält, zu dem sie zeigt, können Branches ohne großen Aufwand erzeugt und vernichtet werden. +Einen neuen Branch anzulegen, geht so schnell und ist so einfach, wie 41 Bytes in eine Datei zu schreiben (40 Zeichen und ein Zeilenumbruch). -This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project's files into a second directory. -This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. -Also, because we're recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. -These features help encourage developers to create and use branches often. +Dies steht in krassem Gegensatz zu der Art und Weise, wie die meisten älteren Werkzeuge zur Versionsverwaltung Branches anlegen, was das Kopieren aller Projektdateien in ein zweites Verzeichnis einschließt. +Das kann, in Abhängigkeit von der Projektgröße, mehrere Sekunden oder sogar Minuten dauern, während bei Git dieser Prozess augenlicklich erledigt ist. +Da wir außerdem immer die Vorgänger mit aufzeichnen, wenn wir einen Commit durchführen, wird automatisch die Suche nach einer geeigneten Basis für das Zusammenführen für uns erledigt, was dadurch in der Regel sehr einfach erledigt werden kann. +Diese Funktionen tragen dazu bei, die Entwickler zu ermutigen, häufig Branches zu erstellen und zu nutzen. -Let's see why you should do so. +Lassen Sie uns sehen, warum Sie das tun sollten. diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 24d7c47cf..57e2e7e14 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -2,27 +2,27 @@ === Rebasing (((rebasing))) -In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. -In this section you'll learn what rebasing is, how to do it, why it's a pretty amazing tool, and in what cases you won't want to use it. +Es gibt bei Git zwei Wege, um Änderungen von einem Branch in einen anderen zu integrieren: `merge` und `rebase`. +In diesem Abschnitt werden Sie erfahren, was Rebasing ist, wie Sie es anwenden, warum es ein verdammt abgefahrenes Werkzeug ist und bei welchen Gelegenheiten Sie es besser nicht einsetzen sollten. -==== The Basic Rebase +==== Das einfache Rebase -If you go back to an earlier example from <<_basic_merging>>, you can see that you diverged your work and made commits on two different branches. +Wenn Sie sich noch mal ein früheres Beispiel aus <<_basic_merging>> anschauen, können Sie sehen, dass Sie Ihre Arbeit verzweigt und Commits auf zwei unterschiedlichen Branches erstellt haben. -.Simple divergent history -image::images/basic-rebase-1.png[Simple divergent history.] +.Einfacher verzweigter Verlauf +image::images/basic-rebase-1.png[Einfacher verzweigter Verlauf.] -The easiest way to integrate the branches, as we've already covered, is the `merge` command. -It performs a three-way merge between the two latest branch snapshots (`C3` and `C4`) and the most recent common ancestor of the two (`C2`), creating a new snapshot (and commit). +Wie wir bereits besprochen haben, ist die einfachste Möglichkeit, Branches zusammenzuführen, die `merge`-Anweisung. +Sie führt einen Drei-Wege-Merge durch zwischen den beiden letzten Momentaufnahmen der Branches (`C3` und `C4`) und dem letzen gemeinsamen Vorgänger (C2) der beiden, wobei eine neue Momentaufnahme (und ein Commit) erzeugt wird. -.Merging to integrate diverged work history -image::images/basic-rebase-2.png[Merging to integrate diverged work history.] +.Zusammenführen (Merging) verzweigter Arbeitsverläufe +image::images/basic-rebase-2.png[Zusammenführen (Merging) verzweigter Arbeitsverläufe.] -However, there is another way: you can take the patch of the change that was introduced in `C4` and reapply it on top of `C3`. -In Git, this is called _rebasing_. -With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.(((git commands, rebase))) +Allerdings gibt es noch einen anderen Weg: Sie können den Patch der Änderungen, den wir in `C4` eingeführt haben, nehmen und an der Spitze von `C3` erneut anwenden. +Dieses Vorgehen nennt man in Git _rebasing_. +Mit der `rebase`-Anweisung können Sie alle Änderungen, die an einem Branch vorgenommen wurden, auf einen anderen Branch erneut anwenden.(((git commands, rebase))) -In this example, you'd run the following: +In diesem Beispiel würden Sie folgendes ausführen: [source,console] ---- @@ -32,12 +32,12 @@ First, rewinding head to replay your work on top of it... Applying: added staged command ---- -It works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. +Dies funktioniert, indem Git zum letzten gemeinsamen Vorfahren der beiden Branches (der, auf dem Sie arbeiten, und jener, auf den Sie _rebasen_ möchten) geht, dann die Informationen zu den Änderungen (diffs) sammelt, welche seit dem bei jedem einzelen Commit des aktuellen Branches gemacht wurden, diese in temporären Dateien speichert, den aktuellen Branch auf den gleichen Commit setzt wie den Branch, auf den Sie _rebasen_ möchten und dann alle Änderungen erneut durchführt. -.Rebasing the change introduced in `C4` onto `C3` -image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.] +.Rebase der in `C4` eingeführten Änderung auf `C3` +image::images/basic-rebase-3.png[Rebasing der in `C4` eingeführten Änderung auf `C3`.] -At this point, you can go back to the master branch and do a fast-forward merge. +An diesem Punkt können Sie zurück zum `master`-Branch wechseln und einen `fast-forward`-Merge durchführen. [source,console] ---- @@ -45,47 +45,47 @@ $ git checkout master $ git merge experiment ---- -.Fast-forwarding the master branch -image::images/basic-rebase-4.png[Fast-forwarding the master branch.] +.Vorspulen des master-Branches +image::images/basic-rebase-4.png[Vorspulen des master-Branches.] -Now, the snapshot pointed to by `C4'` is exactly the same as the one that was pointed to by `C5` in the merge example. -There is no difference in the end product of the integration, but rebasing makes for a cleaner history. -If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. +Nun ist die Momentaufnahme, auf die `C4'` zeigt, exakt die selbe wie diejenige, auf die `C5` in dem Merge-Beispiel gezeigt hat. +Es gibt keinen Unterschied im Resultat dieser Zusammenführung, aber durch Rebasing ensteht ein saubrerer Verlauf. +Wenn Sie das Protokoll des ``rebased''-Branches näher betrachten, sieht es aus wie ein linearer Verlauf: es scheint, als seien die ganzen Arbeiten der Reihe nach abgelaufen, auch wenn sie urprünglich parallel erfolgten. -Often, you'll do this to make sure your commits apply cleanly on a remote branch – perhaps in a project to which you're trying to contribute but that you don't maintain. -In this case, you'd do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. -That way, the maintainer doesn't have to do any integration work – just a fast-forward or a clean apply. +Häufig werden Sie so verfahren um sicherzustellen, dass sich Ihre Commits sauber auf einen entfernten Branch anwenden lassen – möglicherweise in einem Projekt, an dem Sie sich beteiligen möchten, bei dem Sie aber nicht der Verantwortliche sind. +In diesem Fall würden Sie Ihre Arbeiten in einem Branch erledigen und im Anschluss Ihre Änderungen mittels Rebase zu `origin/master` hinzufügen, wenn Sie soweit sind, Ihre Patches dem Hauptprojekt zu übermitteln. +Auf diese Art und Weise hätte der Verantwortliche keinen Aufwand mit der Integration – nur ein ``fast-forward'' oder eine saubere Anwedung Ihres Patches. -Note that the snapshot pointed to by the final commit you end up with, whether it's the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it's only the history that is different. -Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. +Beachten Sie, dass die Momentaufnahme, auf welche der letzte Commit zeigt, ob es nun der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, die selbe Momentaufnahme ist, nur der Verlauf ist ein anderer. +Rebasing wiederholt die Änderungsschritte von einer Entwicklungslinie auf einer anderen in der Reihenfolge, in der sie entstanden sind, wohingegen beim Zusammenführen die beiden Endpunkte der Branches genommen und miteinander verschmolzen werden. -==== More Interesting Rebases +==== Interessantere Rebases -You can also have your rebase replay on something other than the rebase target branch. -Take a history like <>, for example. -You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. -Then, you branched off that to make the client-side changes (`client`) and committed a few times. -Finally, you went back to your server branch and did a few more commits. +Sie können Ihr Rebase auch auf einen anderen Branch als den Rebase-Ziel-Branch anwenden. +Nehmen Sie zum Beispiel einen Verlauf wie in <>. +Sie haben einen Themen-Branch (`server`) angelegt, um ein paar serverseitige Funktionalitäten zu Ihrem Projekt hinzuzufügen, und haben dann einen Commit gemacht. +Dann haben Sie von diesem einen weiteren Branch abgezweigt, um clientseitige Änderungen (`client`) vorzunehmen, und haben ein paar Commits durchgeführt. +Zum Schluss wechselten Sie wieder zurück zu Ihrem `server`-Branch und machten ein paar weitere Commits. [[rbdiag_e]] -.A history with a topic branch off another topic branch -image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch.] +.Ein Verlauf mit einem Themen-Branch neben einem anderen Themen-Branch +image::images/interesting-rebase-1.png[Ein Verlauf mit einem Themen-Branch neben einem anderen Themen-Branch.] -Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it's tested further. -You can take the changes on client that aren't on server (`C8` and `C9`) and replay them on your master branch by using the `--onto` option of `git rebase`: +Angenommen, Sie entscheiden sich, dass Sie für einen Release Ihre clientseitigen Änderungen mit Ihrer Hauptentwicklungslinie zusammenführen, während Sie die serverseitigen Änderungen noch zurückhalten wollen, bis diese weiter getestet wurden. +Sie können einfach die Änderungen am `client`-Branch (`C8` und `C9`), die nicht auf `server`-Branch sind, nehmen und mit der Anweisung `git rebase` zusammen mit der Option `--onto` erneut auf den `master`-Branch anwenden: [source,console] ---- $ git rebase --onto master server client ---- -This basically says, ``Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.'' -It's a bit complex, but the result is pretty cool. +Dies bedeutet im Wesentlichen, ``Checke den `client`-Branch aus, finde die Patches des gemeinsamen Vorgängers des `client`- und des `server`-Branches heraus und wende sie erneut auf den `master`-Branch an.'' +Das ist ein wenig komplex, aber das Resultat ist ziemlich toll. -.Rebasing a topic branch off another topic branch -image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch.] +.Rebasing eines Themen-Branches außerhalb eines anderen Themen-Branches +image::images/interesting-rebase-2.png[Rebasing eines Themen-Branches außerhalb eines anderen Themen-Branches.] -Now you can fast-forward your master branch (see <>): +Jetzt können Sie Ihren Master-Branch vorspulen (siehe <>): [source,console] ---- @@ -94,24 +94,24 @@ $ git merge client ---- [[rbdiag_g]] -.Fast-forwarding your master branch to include the client branch changes -image::images/interesting-rebase-3.png[Fast-forwarding your master branch to include the client branch changes.] +.Vorspulen Ihres master-Branches zum Einfügen der Änderungen des client-Branches +image::images/interesting-rebase-3.png[Vorspulen Ihres master-Branches zum Einfügen der Änderungen des client-Branches.] -Let's say you decide to pull in your server branch as well. -You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` – which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`): +Lassen Sie uns annehmen, Sie entscheiden sich dazu, Ihren `server`-Branch ebenfalls einzupflegen. +Sie können das Rebase des `server`-Branches auf den `master`-Branch anwenden, ohne diesen vorher auschecken zu müssen, indem Sie die Anweisung `git rebase [Basis-Branch] [Themen-Branch]` ausführen, welche für Sie den Themen-Branch auscheckt (in diesem Fall `server`) und ihn auf dem Basis-Branch (`master`) wiederholt: [source,console] ---- $ git rebase master server ---- -This replays your `server` work on top of your `master` work, as shown in <>. +Dies wiederholt Ihre Änderungen vom `server`-Branch an der Spitze des `master`-Branches, wie in <> abgebildet wird. [[rbdiag_h]] -.Rebasing your server branch on top of your master branch -image::images/interesting-rebase-4.png[Rebasing your server branch on top of your master branch.] +.Rebase Ihres server-Branches an der Spitze Ihres master-Branches +image::images/interesting-rebase-4.png[Rebase Ihres server-Branches an der Spitze Ihres master-Branches.] -Then, you can fast-forward the base branch (`master`): +Dann können Sie den Basis-Branch vorspulen (`master`): [source,console] ---- @@ -119,7 +119,7 @@ $ git checkout master $ git merge server ---- -You can remove the `client` and `server` branches because all the work is integrated and you don't need them anymore, leaving your history for this entire process looking like <>: +Sie können die Branches `client`- und `server` entfernen, da die ganze Arbeit bereits integriert wurde und Sie diese nicht mehr benötigen. Und Ihr Verlauf für diesen gesamten Prozess sieht aus wie in <>: [source,console] ---- @@ -128,105 +128,107 @@ $ git branch -d server ---- [[rbdiag_i]] -.Final commit history -image::images/interesting-rebase-5.png[Final commit history.] +.Endgültiger Commit-Verlauf +image::images/interesting-rebase-5.png[Endgültiger Commit-Verlauf.] [[_rebase_peril]] -==== The Perils of Rebasing +==== Die Gefahren von Rebasing (((rebasing, perils of))) -Ahh, but the bliss of rebasing isn't without its drawbacks, which can be summed up in a single line: +Ahh, aber der ganze Spaß mit dem Rebasing kommt nicht ohne seine Schattenseiten, welche in einer einzigen Zeile zusammengefasst werden können: -**Do not rebase commits that exist outside your repository.** +**Führen Sie kein Rebase mit Commits durch, die außerhalb Ihres Repositorys existieren.** -If you follow that guideline, you'll be fine. -If you don't, people will hate you, and you'll be scorned by friends and family. +Wenn Sie dieser Richtlinie folgen, können Sie nichts falsch machen. +Wenn Sie es nicht tun, werden die Leute Sie hassen und Sie werden von Freunden und Verwandten verachtet. -When you rebase stuff, you're abandoning existing commits and creating new ones that are similar but different. -If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours. +Wenn Sie ein Rebase durchführen, heben Sie bestehende Commits auf und erstellen stattdessen neue, die zwar ähnlich aber dennoch unterschiedlich sind. +Wenn Sie Commits irgendwohin hochladen und andere ziehen sich diese herunter und nehmen sie als Grundlage für ihre Arbeit, dann müssen Ihre Mitstreiter ihre Arbeit jedesmal erneut zusammenführen, sobald Sie Ihre Commits mit einem `git rebase` überschreiben und wieder hochladen. Und richtig chaotisch wird es, wenn Sie versuchen, deren Arbeit in Ihre eigene zu integrieren. -Let's look at an example of how rebasing work that you've made public can cause problems. -Suppose you clone from a central server and then do some work off that. -Your commit history looks like this: +Lassen Sie uns ein Beispiel betrachten, wie ein Rebase von Änderungen, die Sie veröffentlicht haben, Probleme verursachen kann. +Angenommen, Sie klonen von einem zentralen Server und werkeln ein bisschen daran rum. +Ihr Commit-Verlauf sieht aus wie dieser: -.Clone a repository, and base some work on it -image::images/perils-of-rebasing-1.png["Clone a repository, and base some work on it."] +.Klonen Sie ein Repository und bauen Sie darauf Ihre Arbeit auf +image::images/perils-of-rebasing-1.png["Klonen Sie ein Repository und nehmen Sie Änderungen daran vor."] -Now, someone else does more work that includes a merge, and pushes that work to the central server. -You fetch them and merge the new remote branch into your work, making your history look something like this: +Ein anderer arbeitet unterdessen weiter, macht einen Merge und lädt seine Arbeit auf den zentralen Server hoch. +Sie holen die Änderungen ab und führen den neuen Remote-Branch mit Ihrer Arbeit zusammen, sodass Ihr Verlauf wie so aussieht. -.Fetch more commits, and merge them into your work -image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work."] +.Holen Sie weitere Commits ab und führen Sie diese mit Ihrer Arbeit zusammen +image::images/perils-of-rebasing-2.png["Holen Sie weitere Commits ab und führen Sie diese mit Ihrer Arbeit zusammen."] -Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. -You then fetch from that server, bringing down the new commits. +Als nächstes entscheidet sich die Person, welche die zusammengeführte Arbeit hochgeladen hat, dies rückgängig zu machen und stattdessen ihre Arbeit mittels Rebase hinzuzufügen. Sie führt dazu die Anweisung `git push --force` aus, um den Verlauf auf dem Server zu überschreiben. +Sie holen das Ganze dann von diesem Server ab und laden die neuen Commits herunter. [[_pre_merge_rebase_work]] -.Someone pushes rebased commits, abandoning commits you've based your work on -image::images/perils-of-rebasing-3.png["Someone pushes rebased commits, abandoning commits you've based your work on."] +.Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen Ihre Arbeit basiert +image::images/perils-of-rebasing-3.png["Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen Ihre Arbeit basiert."] -Now you're both in a pickle. -If you do a `git pull`, you'll create a merge commit which includes both lines of history, and your repository will look like this: +Jetzt sitzen Sie beide in der Klemme. +Wenn Sie ein `git pull` durchführen, würden Sie einen Merge-Commit erzeugen, welcher beide Entwicklungslinien einschließt, und Ihr Repository würde so aussehen: [[_merge_rebase_work]] -.You merge in the same work again into a new merge commit -image::images/perils-of-rebasing-4.png[You merge in the same work again into a new merge commit.] +.Sie lassen die Änderungen nochmals in die selbe Arbeit einfließen in einen neuen Merge-Commit +image::images/perils-of-rebasing-4.png[Sie lassen die Änderungen nochmals in die selbe Arbeit einfließen in einen neuen Merge-Commit.] -If you run a `git log` when your history looks like this, you'll see two commits that have the same author, date, and message, which will be confusing. -Furthermore, if you push this history back up to the server, you'll reintroduce all those rebased commits to the central server, which can further confuse people. -It's pretty safe to assume that the other developer doesn't want `C4` and `C6` to be in the history; that's why she rebased in the first place. +Falls Sie die Anweisung `git log` ausführen, wenn Ihr Verlauf so aussieht, würden Sie zwei Commits sehen, bei denen Autor, Datum und Nachricht übereinstimmen, was verwirrend sein würde. +Des Weiteren würden Sie, wenn Sie diesen Verlauf auf den Server hochladen, alle diese vom Rebase stammenden Commits auf dem zentralen Server neu einführen, was die Leute weiter durcheinander bringen könnte. +Man kann ziemlich sicher davon ausgehen, dass der andere Entwickler `C4` und `C6` nicht im Verlauf haben möchte; das ist der Grund, warum derjenige das Rebase überhaupt gemacht hat. [[_rebase_rebase]] -==== Rebase When You Rebase +==== Rebase, wenn Sie Rebase durchführen -If you *do* find yourself in a situation like this, Git has some further magic that might help you out. If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten. +Wenn Sie in eine Situation wie diese geraten *sind*, hat Git einige weitere Zaubertricks auf Lager, welche Ihnen da raus helfen könnten. Wenn irgendjemand aus Ihrem Team Änderungen hochlädt unter Verwendung der Option `--force` und dabei Arbeit überschreibt, auf der Sie Ihre Arbeit aufgebaut haben, ist es Ihre Herausforderung herauszufinden, was Ihnen gehört und was derjenige überschrieben hat. -It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. This is called a ``patch-id''. +Es stellt sich heraus, dass Git zusätzlich zur SHA-1-Pürfsumme auch eine Prüfsumme berechnet, welche genau auf dem Patch basiert, der mit dem Commit eingeführt wurde. Dies nennt man eine ``patch-id'' . -If you pull down work that was rewritten and rebase it on top of the new commits from your partner, Git can often successfully figure out what is uniquely yours and apply them back on top of the new branch. +Wenn sie Arbeit herunterladen, welche neu geschrieben wurde, und diese mit mittels Rebase an der Spitze der Commits von Ihrem Partner hinzufügen, kann Git häufig erfolgreich herausfinden, was einzig und allein Ihre Commits sind und diese an der Spitze des neuen Branches anwenden. -For instance, in the previous scenario, if instead of doing a merge when we're at <<_pre_merge_rebase_work>> we run `git rebase teamone/master`, Git will: +Wenn wir im vorhergehenden Szenario beispielsweise bei <<_pre_merge_rebase_work>> die Anweisung `git rebase teamone/master` ausführen, anstatt ein Merge durchzuführen, dann wird Git: -* Determine what work is unique to our branch (C2, C3, C4, C6, C7) -* Determine which are not merge commits (C2, C3, C4) -* Determine which have not been rewritten into the target branch (just C2 and C3, since C4 is the same patch as C4') -* Apply those commits to the top of `teamone/master` +* bestimmen, welche Änderungen an unserem Branch einmalig sind (C2, C3, C4, C6, C7) +* bestimmen, welche der Commits keine Merge-Commits sind (C2, C3, C4) +* bestimmen, welche Commits nicht neu in den Zielbranch geschrieben wurden (bloß C2 und C3, da C4 der selbe Patch wie C4' ist) +* diese Commits an der Spitze des Branches `teamone/master` anwenden So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>. +Statt des Ergebnisses, welches wir in <<_merge_rebase_work>> sehen, würden wir etwas erhalten, was irgendwie mehr so wäre wie <<_rebase_rebase_work>>. + [[_rebase_rebase_work]] -.Rebase on top of force-pushed rebase work. -image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.] +.Rebase an der Spitze von Änderungen eines "force-pushed"-Rebase. +image::images/perils-of-rebasing-5.png[Rebase an der Spitze von Änderungen eines "force-pushed"-Rebase.] -This only works if C4 and C4' that your partner made are almost exactly the same patch. Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there). +Dies funktioniert nur, wenn es sich bei C4 und C4', welche Ihr Teamkollege gemacht hat, um fast genau den selben Patch handelt. -You can also simplify this by running a `git pull --rebase` instead of a normal `git pull`. Or you could do it manually with a `git fetch` followed by a `git rebase teamone/master` in this case. +Sie können dies auch vereinfachen, indem Sie die Anweisung `git pull --rebase` anstatt eines normalen `git pull` ausführen. Oder Sie könnten es manuell durchführen mit einem `git fetch` gefolgt von einem `git rebase teamone/master` in diesem Fall. -If you are using `git pull` and want to make `--rebase` the default, you can set the `pull.rebase` config value with something like `git config --global pull.rebase true`. +Wenn Sie `git pull` benutzen und `--rebase` zur Standardeinstellung machen wollen, können Sie den `pull.rebase`-Konfigurationswert mit etwas wie `git config --global pull.rebase true` einstellen. -If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you'll be fine. -If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates. +Wenn Sie Rebasing als eine Möglichkeit betrachten, um aufzuräumen und mit Commits zu arbeiten, bevor Sie diese hochladen und wenn Sie Rebase nur auf Commits anwenden, die noch nie öffentlich zugänglich waren, können Sie nichts falsch machen. +Wenn Sie Rebase auf Commits anwenden, die bereits veröffentlicht wurden und Leute vielleicht schon ihre Arbeit darauf aufgebaut haben, dann können Sie sich auf frustrierenden Ärger gefasst machen, und auf den Hohn Ihrer Teamkollegen. -If you or a partner does find it necessary at some point, make sure everyone knows to run `git pull --rebase` to try to make the pain after it happens a little bit simpler. +Wenn Sie oder ein Kollege es an irgendeinem Punkt als unbedingt notwendig erachten, stellen Sie sicher, dass alle darüber informiert wurden, anschließend die Anweisung `git pull --rebase` auszuführen, um die Schmerzen danach etwas erträglicher zu machen. -==== Rebase vs. Merge +==== Rebase im Vergleich zu Merge -(((rebasing, vs. merging)))(((merging, vs. rebasing))) -Now that you've seen rebasing and merging in action, you may be wondering which one is better. -Before we can answer this, let's step back a bit and talk about what history means. +(((merging, vs. rebasing))) +Nachdem Sie jetzt Rebasing und Merging in Aktion erlebt haben, fragen Sie sich vielleicht, was davon besser ist. +Bevor wir dies beantworten können, lassen Sie uns ein klein wenig zurückblicken und darüber reden, was der Verlauf bedeutet. -One point of view on this is that your repository's commit history is a *record of what actually happened.* -It's a historical document, valuable in its own right, and shouldn't be tampered with. -From this angle, changing the commit history is almost blasphemous; you're _lying_ about what actually transpired. -So what if there was a messy series of merge commits? -That's how it happened, and the repository should preserve that for posterity. +Ein Standpunkt ist, dass der Commit-Verlauf Ihres Repositorys eine *Aufzeichnung davon ist, was wirklich passierte". +Es ist ein geschichtliches Dokument, eigenständig kostbar, und sollte nicht manipuliert werden. +Aus diesem Blickwinkel ist die Änderung des Verlaufs fast Gotteslästerung; Sie _lügen_ darüber, was sich wirklich ereignet hat. +Aber was ist, wenn es eine chaotische Reihe von Merge-Commits gibt? +Das ist, wie es dazu gekommen ist und das Repository sollte das für die Nachwelt erhalten. -The opposing point of view is that the commit history is the *story of how your project was made.* -You wouldn't publish the first draft of a book, and the manual for how to maintain your software deserves careful editing. -This is the camp that uses tools like rebase and filter-branch to tell the story in the way that's best for future readers. +Der entgegengesetzte Standpunkt ist, dass der Commit-Verlauf die *Geschichte davon ist, wie Ihr Projekt gemacht wurde". +Sie würden den ersten Entwurf eines Buches auch nicht veröffentlichen, und die Anleitung dafür, wie Ihre Software zu warten ist, verdient eine sorgfältige Bearbeitung. +Dies ist das Lager, welches Werkzeuge wie Rebase und Filter-Branch benutzt, um die Geschichte so zu erzählen, wie es für künftige Leser am besten ist. -Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple. -Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different. -Now that you know how both of these things work, it's up to you to decide which one is best for your particular situation. +Nun zu der Frage, ob Zusammenführen oder Rebase besser ist: Sie haben hoffentlich erkannt, dass es nicht so einfach ist. +Git ist ein mächtiges Werkzeug und es ermöglicht Ihnen, viele Dinge an und mit Ihrem Verlauf anzustellen, aber alle Teams und alle Projekte sind verschieden. +Da Sie jetzt wissen, wie diesen beiden Techniken funktionieren, müssen Sie selbst entscheiden, welche davon in Ihrer besonderen Situation am besten geeignet ist. -In general the way to get the best of both worlds is to rebase local changes you've made but haven't shared yet before you push them in order to clean up your story, but never rebase anything you've pushed somewhere. +Für gewöhnlich lassen sich die Vorteile von beiden Techniken nutzen, indem Sie lokale Änderungen, die Sie gemacht aber noch nicht veröffentlicht haben, mittels Rebase hinzufügen, um den Verlauf zu bereinigen, aber niemals ein Rebase an Commits durchführen, die Sie bereits irgendwohin hochgeladen haben. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 520cb0c2d..a78f40c4b 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -1,65 +1,70 @@ [[_remote_branches]] -=== Remote Branches +=== Remote-Branches (((branches, remote)))(((references, remote))) -Remote branches are references (pointers) to the state of branches in your remote repositories. -They're local branches that you can't move; they're moved automatically for you whenever you do any network communication. -Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them. +Remote-Referenzen sind Referenzen (Zeiger) in Ihren Remote-Repositorys, einschließlich Branches, Tags usw. +Sie können eine vollständige, ausführliche Liste von Remote-Referenzen bekommen, wenn Sie die Anweisungen `git ls-remote (remote)` oder `git remote show (remote)` ausführen, für Remote-Branches sowie für weitere Informationen. +Häufige werden jedoch Remote-Tracking-Branches genutzt. -They take the form `(remote)/(branch)`. -For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. -If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`. +Remote-Tracking-Branches sind Referenzen auf den Zustand von Remote-Branches. +Sie sind lokale Referenzen, die Sie nicht bewegen können, sie werden automatisch für Sie bewegt, sobald Sie irgendeine Netzwerkkommunikation durchführen. +Entfernte Branches dienen als Lesezeichen, um Sie daran zu erinnern, an welcher Position sich die Branches in Ihren entfernten Repositorys befanden, als Sie sich zum letzten Mal mit ihnen verbunden haben. -This may be a bit confusing, so let's look at an example. -Let's say you have a Git server on your network at `git.ourcompany.com`. -If you clone from this, Git's `clone` command automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally. -Git also gives you your own local `master` branch starting at the same place as origin's `master` branch, so you have something to work from. +Sie haben die Form `(Remote-Repository)/(Branch)`. +Wenn Sie beispielsweise wissen möchten, wie der `master`-Branch in Ihrem `origin`-Repository ausgesehen hat, als Sie zuletzt Kontakt mit ihm hatten, dann würden Sie den `origin/master`-Branch überprüfen. +Wenn Sie mit einem Mitarbeiter an einem Problem gearbeitet haben und dieser bereits einen `iss53`-Branch hochgeladen hat, besitzen Sie möglicherweise Ihren eigenen lokalen `iss53`-Branch; aber der Branch auf dem Server würde auf den Commit von `origin/iss53` zeigen. + +Das kann ein wenig verwirrend sein, lassen Sie uns also ein Besipiel betrachten. +Angenommen, Sie haben in Ihrem Netzwerk einen Git-Server mit der Adresse `git.ourcompany.com`. +Wenn Sie von diesem klonen, erhält der Server von der Git-Anweisung `clone` automatisch den Namen `origin`, lädt all seine Daten herunter, erstellt einen Zeiger zu dem Commit, auf den dessen `master`-Branch zeigt und benennt ihn lokal `origin/master`. +Git gibt Ihnen auch Ihren eigenen lokalen `master`-Branch mit der gleichen Ausgangsposition wie `origin/master`-Branch, damit Sie einen Punkt, wo Sie mit Ihrer Arbeit beginnen können. [NOTE] -.``origin'' is not special +.``origin'' ist nichts besonderes ==== -Just like the branch name ``master'' does not have any special meaning in Git, neither does ``origin''. While ``master'' is the default name for a starting branch when you run `git init` which is the only reason it's widely used, ``origin'' is the default name for a remote when you run `git clone`. If you run `git clone -o booyah` instead, then you will have `booyah/master` as your default remote branch.(((origin))) +Genau wie der Branchname ``master'' bei Git keine besondere Bedeutung hat, hat auch ``origin'' keine. Während ``master'' die Standardbezeichnung für einen Anfangsbranch ist, wenn Sie die Anweisung `git init` ausführen, was der einzige Grund dafür ist, warum er so weit verbreitet ist, wird ``origin'' als Standardbezeichnung für ein entferntes Repository vergeben, wenn Sie die Anweisung `git clone` ausführen. Wenn Sie statt dessen die Anweisung `git clone -o booyah` ausführen, erhalten Sie `booyah/master` als entfernten Standardbranch.(((origin))) ==== -.Server and local repositories after cloning -image::images/remote-branches-1.png[Server and local repositories after cloning.] +.Entfernte und lokale Repositorys nach dem Klonen +image::images/remote-branches-1.png[Entfernte und lokale Repositorys nach dem Klonen.] -If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its `master` branch, then your histories move forward differently. -Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn't move. +Wenn Sie ein wenig an Ihrem lokalen `master`-Branch arbeiten und in der Zwischenzeit jemand anders etwas zu `git.ourcompany.com` hochlädt und damit dessen `master`-Branch aktualisiert, dann bewegen sich eure Verläufe unterschiedlich vorwärts. +Und solange Sie keinen Kontakt mit Ihrem `origin`-Server aufnehmen, bewegt sich Ihr `origin/master`-Zeiger nicht. -.Local and remote work can diverge -image::images/remote-branches-2.png[Local and remote work can diverge.] +.Lokale und entfernte Änderungen können auseinander laufen +image::images/remote-branches-2.png[Lokale und entfernte Änderungen können auseinander laufen.] -To synchronize your work, you run a `git fetch origin` command. -This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position. +Um Ihre Arbeit zu synchronisieren, führen Sie die Anweisung `git fetch origin` aus. +Die Anweisung schlägt nach, welcher Server `orgin` ist (in diesem Fall `git.ourcompany.com`), holt alle Daten, die Sie noch nicht haben, und aktualisiert Ihre lokale Datenbank, indem es Ihren `orgin/master`-Zeiger auf seine neue, aktuellere Position bewegt. -.`git fetch` updates your remote references -image::images/remote-branches-3.png[`git fetch` updates your remote references.] +.`git fetch` aktualisiert Ihre entfernten Verweise +image::images/remote-branches-3.png[`git fetch` aktualisiert Ihre entfernten Verweise.] -To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let's assume you have another internal Git server that is used only for development by one of your sprint teams. -This server is at `git.team1.ourcompany.com`. -You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <<_git_basics_chapter>>. -Name this remote `teamone`, which will be your shortname for that whole URL. +Um den Umgang mit mehreren Remote-Servern zu veranschaulichen und um zu sehen, wie Remote-Branches bei diesen Remote-Projekten aussehen, nehmen wir an, dass Sie einen weiteren internen Git-Server haben, welcher von einem Ihrer Sprint-Teams nur zur Entwicklung genutzt wird. +Diesen Server erreichen wir unter `git.team1.ourcompany.com`. +Sie können ihn zu dem Projekt, an dem Sie gegenwärtig arbeiten, als neuen Remote-Server hinzufügen, indem Sie die Anweisung `git remote add` ausführen, wie wir bereits in <<_git_basics_chapter>> behandelt haben. +Nennen Sie diesen Remote-Server `teamone`, was Ihre Kurzbezeichnung für die gesamte URL sein wird. -.Adding another server as a remote -image::images/remote-branches-4.png[Adding another server as a remote.] +.Hinzufügen eines weiteren entfernten Servers +image::images/remote-branches-4.png[Hinzufügen eines weiteren entfernten Servers.] -Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don't have yet. -Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch. +Jetzt können Sie die Anweisung `git fetch teamone` ausführen, um alles vom Server zu holen, was Sie noch nicht haben. +Da auf diesem Server eine Teilmenge der Daten ist, welche sich gerade jetzt auf Ihrem `origin`-Server befinden, holt Git keine Daten ab, aber es stellt einen entfernten Branch namens `teamone/master` so ein, dass er auf den Commit zeigt, den `teamone` als seinen `master`-Branch hat. -.Remote tracking branch for `teamone/master` -image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.] +.Remote-Tracking-Branch für `teamone/master` +image::images/remote-branches-5.png[Remote-Tracking-Branch für `teamone/master`.] [[_pushing_branches]] ==== Pushing +==== Hochladen (Pushing) (((pushing))) -When you want to share a branch with the world, you need to push it up to a remote that you have write access to. -Your local branches aren't automatically synchronized to the remotes you write to – you have to explicitly push the branches you want to share. -That way, you can use private branches for work you don't want to share, and push up only the topic branches you want to collaborate on. +Wenn Sie einen Branch mit der Welt teilen möchten, müssen Sie ihn auf einen Remote-Server hochladen, auf dem Sie Schreibrechte besitzen. +Ihre lokalen Branches werden nicht automatisch mit den Remote-Servern synchronisiert, wenn Sie etwas hochladen – Sie müssen die Branches explizit hochladen (push), die Sie veröffentlichen wollen. +Auf diese Weise können Sie private Branches, die Sie nicht veröffentlichen wollen, zum Arbeiten benutzen und nur die Themen-Branches hochladen, an denen Sie mitarbeiten wollen. -If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. -Run `git push (remote) (branch)`:(((git commands, push))) +Wenn Sie einen Zweig namens `serverfix` besitzen, an dem Sie mit anderen arbeiten möchten, dann können Sie diesen auf dieselbe Weise hochladen wie Ihren ersten Branch. +Führen Sie die Anweisung `git push (remote) (branch)` aus:(((git commands, push))) [source,console] ---- @@ -80,17 +85,24 @@ You can also do `git push origin serverfix:serverfix`, which does the same thing You can use this format to push a local branch into a remote branch that is named differently. If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project. +Das ist eine kleine Abkürzung. +Git erweitert die Branchbezeichnung `serverfix` automatisch zu `refs/heads/serverfix:refs/heads/serverfix`, was soviel bedeutet wie ``Nimm meinen lokalen `serverfix`-Branch und aktualisiere damit den `serverfix`-Branch auf meinem Remote-Server''. +Wir werden den `refs/heads/`-Teil in <<_git_internals>> noch näher beleuchten, Sie können ihn aber in der Regel weglassen. +Sie können auch die Anweisung `git push origin serverfix:serverfix` ausführen, was das Gleiche bewirkt – es bedeutet ``Nimm meinen `serverfix` und mach ihn zum `serverfix` des Remote-Servers''. +Sie können dieses Format auch benutzen, um einen lokalen Branch in einen Remote-Branch mit anderem Namen zu laden. +Wenn Sie ihn auf dem Remote-Server nicht `serverfix` nennen wollen, könnten Sie stattdessen die Anweisung `git push origin serverfix:awesomebranch` ausführen, um Ihren lokalen `serverfix`-Branch in den `awesomebranch`-Branch des Remote-Projekts zu laden. + [NOTE] -.Don't type your password every time +.Geben Sie Ihr Passwort jedes Mal ein ==== -If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push. +Wenn Sie eine HTTPS-URL benutzen, um darüber hochzuladen, wird Sie der Git-Server zur Authentifizierung nach Ihrem Benutzernamen und Passwort fragen. Standardmäßig wird er Sie im Terminal dazu auffordern, diese Informationen einzugeben, damit der Server Ihnen mitteilen kann, ob Sie berechtigt sind, etwas hochzuladen. -If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`. +Wenn Sie es nicht jedes Mal eingeben wollen, wenn Sie etwas hochladen, da können Sie einen ``credential cache'' einstellen. Am einfachsten ist es, die Informationen nur für einige Minuten im Speicher zu behalten, was Sie einfach mit der Anweisung `git config --global credential.helper cache` bewerkstelligen können. -For more information on the various credential caching options available, see <<_credential_caching>>. +Weitere Informationen zu den verschiedenen verfügbaren ``credential cache''-Optionen finden Sie in <<_credential_caching>>. ==== -The next time one of your collaborators fetches from the server, they will get a reference to where the server's version of `serverfix` is under the remote branch `origin/serverfix`: +Das nächste Mal, wenn einer Ihrer Mitarbeiter Daten von Server abholt, wird er eine Referenz auf die Server-Version des Branches `serverfix` unter dem Remote-Branch `origin/serverfix` erhalten: [source,console] ---- @@ -103,11 +115,11 @@ From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ---- -It's important to note that when you do a fetch that brings down new remote branches, you don't automatically have local, editable copies of them. -In other words, in this case, you don't have a new `serverfix` branch – you only have an `origin/serverfix` pointer that you can't modify. +Es ist wichtig zu beachten, dass Sie beim Abholen eines neuen Remote-Branches nicht automatisch eine lokale, bearbeitbare Kopie desselben erhalten. +Mit anderen Worten, in diesem Fall bekommen Sie keinen neuen `serverfix`-Branch – sondern nur einen `origin/serverfix`-Zeiger, den Sie nicht verändern können. -To merge this work into your current working branch, you can run `git merge origin/serverfix`. -If you want your own `serverfix` branch that you can work on, you can base it off your remote branch: +Um diese Änderungen in Ihren gegenwärtigen Arbeitsbranch einfließen zu lassen, können Sie die Anweisung `git merge origin/serverfix` ausführen. +Wenn Sie Ihren eigenen Branch `serverfix` haben wollen, andem Sie arbeiten können, dann können Sie diesen auf Grundlage des Remote-Branches erstellen: [source,console] ---- @@ -116,20 +128,20 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -This gives you a local branch that you can work on that starts where `origin/serverfix` is. +Dies erstellt Ihnen einen lokalen Branch, an dem Sie arbeiten können und der dort beginnt, wo `origin/serverfix` ist. [[_tracking_branches]] -==== Tracking Branches +==== Tracking-Branches (((branches, tracking)))(((branches, upstream))) -Checking out a local branch from a remote branch automatically creates what is called a ``tracking branch'' (or sometimes an ``upstream branch''). -Tracking branches are local branches that have a direct relationship to a remote branch. -If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and branch to merge into. +Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisch einen sogenannten ``Tracking-Branch'' (oder manchmal einen ``Upstream-Branch''). +Tracking-Branches sind lokale Branches, die eine direkte Beziehung zu einem Remote-Branch haben. +Wenn Sie sich auf einem Tracking-Branch befinden und `git pull` eingeben, weiß Git automatisch, von welchem Server Daten abzuholen sind und in welchen Branch diese einfließen sollen. -When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. -However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don't track the `master` branch. -The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. -This is a common enough operation that git provides the `--track` shorthand: +Wenn Sie ein Repository klonen, wird automatisch ein `master`-Branch erzeugt, welcher `origin/master` verfolgt. +Sie können jedoch auch andere Tracking-Branches erzeugen, wenn Sie wünschen, – welche die nicht Zweige auf `origin` und dessen `master`-Branch verfolgen. +Der einfachste Fall ist das Beispiel, dass Sie gerade gesehen haben, die Ausführung der Anweisung `git checkout -b [branch] [remotename]/[branch]`. +Mit der Git-Version 1.6.2 oder später kannst Du auch die `--track`-Kurzvariante nutzen: [source,console] ---- @@ -138,7 +150,7 @@ Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ---- -To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: +Um einen lokalen Branch mit einem anderen Namen als dem des Remote-Branches zu erzeugen, können Sie einfach die erste Version mit einem anderen lokalen Branch-Namen verwenden: [source,console] ---- @@ -147,9 +159,9 @@ Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ---- -Now, your local branch `sf` will automatically pull from `origin/serverfix`. +Ihr lokaler Branch `sf` wird jetzt automatisch von `origin/serverfix` herunterladen. -If you already have a local branch and want to set it to a remote branch you just pulled down, or want to change the upstream branch you're tracking, you can use the `-u` or `--set-upstream-to` option to `git branch` to explicitly set it at any time. +Wenn Sie bereits einen lokalen Branch haben und ihn auf einen Remote-Branch einstellen wollen, den Sie gerade heruntergeladen haben, oder Sie den Upstream-Branch ändern wollen, können Sie die Anweisung `git branch` zusammen mit der Option `-u` oder `--set-upstream-to` benutzen, um diesen zu jeder Zeit explizit einzustellen. [source,console] ---- @@ -158,12 +170,12 @@ Branch serverfix set up to track remote branch serverfix from origin. ---- [NOTE] -.Upstream shorthand +.Upstream Kürzel ==== -When you have a tracking branch set up, you can reference it with the `@{upstream}` or `@{u}` shorthand. So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++))) +Wenn Sie einen Tracking-Branch eingerichtet haben, können Sie auf diesen mit den Kürzeln `@{upstream}` oder `@{u}` verweisen. Wenn Sie sich also auf dem `master`-Branch befinden und dieser `origin/master` verfolgt, können Sie etwas wie `git merge @{u}` anstatt von `git merge origin/master` ausführen, wenn Sie wollen.(((+++@{u}+++)))(((+++@{upstream}+++))) ==== -If you want to see what tracking branches you have set up, you can use the `-vv` option to `git branch`. This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both. +Wenn Sie die Tracking-Branches sehen wollen, die Sie eingerichtet haben, können Sie die Anweisung `git branch` zusammen mit der Option `-vv` ausführen. Dies listet Ihre lokalen Branches zusammen mit weiteren Informationen auf, einschließlich was jeder Branch verfolgt und ob Ihr lokaler Branch voraus, hinterher oder beides ist. [source,console] ---- @@ -174,27 +186,27 @@ $ git branch -vv testing 5ea463a trying something new ---- -So here we can see that our `iss53` branch is tracking `origin/iss53` and is ``ahead'' by two, meaning that we have two commits locally that are not pushed to the server. We can also see that our `master` branch is tracking `origin/master` and is up to date. Next we can see that our `serverfix` branch is tracking the `server-fix-good` branch on our `teamone` server and is ahead by three and behind by one, meaning that there is one commit on the server we haven't merged in yet and three commits locally that we haven't pushed. Finally we can see that our `testing` branch is not tracking any remote branch. +Hier können wir also sehen, dass unser `iss53`-Branch den Branch `origin/iss53` verfolgt und die Information ``ahead 2'' bedeutet, dass wir zwei lokale Commits haben, welche noch nicht auf den Server hochgeladen wurden. Wir können außerdem sehen, dass unser `master`-Branch `origin/master` verfolgt und auf den neuesten Stand ist. Als nächstes sehen wir, dass unser `serverfix`-Branch den Branch `server-fix-good` auf unserem `teamone`-Server verfolgt und ``ahead 3, behind 1'' bedeutet, dass es einen Commit auf dem Server gibt, den wir noch nicht einfließen lassen haben, und drei lokale Commits existieren, die wir noch nicht hochgeladen haben. Zum Schluss können wir sehen, dass unser `testing`-Branch gar keinen Remote-Branch verfolgt. -It's important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. You could do that like this: `$ git fetch --all; git branch -vv` +Es ist wichtig zu beachten, dass diese Zahlen den Zustand zu dem Zeitpunkt beschreiben, als Sie zum letzten Mal Daten vom Server abgeholt haben. Diese Anweisung greift nicht auf die Server zu, sie liefert nur die Informationen, welche beim letzten Server-Kontakt lokal zwischengespeichert wurden. Wenn Sie vollkommen aktuelle Zahlen von ``ahead'' und ``behind'' wollen, dann müssen Sie, kurz bevor Sie die Anweisung ausführen, von all Ihren Remote-Servern Daten abholen (fetch). Sie könnten das so machen: `$ git fetch --all; git branch -vv` -==== Pulling +==== Herunterladen (((pulling))) -While the `git fetch` command will fetch down all the changes on the server that you don't have yet, it will not modify your working directory at all. -It will simply get the data for you and let you merge it yourself. -However, there is a command called `git pull` which is essentially a `git fetch` immediately followed by a `git merge` in most cases. -If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the `clone` or `checkout` commands, `git pull` will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch. +Während die Anweisung `git fetch` alle Änderungen auf dem Server abholt, die Sie zurzeit noch nicht haben, wird sie an Ihrem Arbeitsverzeichnis überhaupt nichts verändern. +Sie wird einfach die Daten für Sie holen und Ihnen das Zusammenführen überlassen. +Es gibt jedoch eine Anweisung namens `git pull`, welche im Grunde genommen ein `git fetch` ist, dem in den meisten Fällen augenblicklich ein `git merge` folgt. +Wenn Sie einen Tracking-Branch eingerichtet haben, wie es im letzten Abschnitt demonstriert wurde, entweder durch explizites Einrichten oder indem er für Sie durch die Anweisungen `clone` oder `checkout` erzeugt wurde, wird die Anweisung `git pull` nachschlagen, welchen Server und Branch Ihr gegenwärtiger Branch gerade verfolgt, die Daten von diesem Server abholen und dann versuchen, die Daten in diesen Remote-Branch einfließen zu lassen. -Generally it's better to simply use the `fetch` and `merge` commands explicitly as the magic of `git pull` can often be confusing. +Generell ist es besser, einfach explizit die Anweisungen `git fetch` und `git merge` zu benutzen, da die Zauberei der Anweisung `git pull` häufig verwirrend sein kann. [[_delete_branches]] -==== Deleting Remote Branches +==== Löschen von Remote-Branches (((branches, deleting remote))) -Suppose you're done with a remote branch – say you and your collaborators are finished with a feature and have merged it into your remote's `master` branch (or whatever branch your stable codeline is in). -You can delete a remote branch using the `--delete` option to `git push`. -If you want to delete your `serverfix` branch from the server, you run the following: +Stellen wir uns vor, Sie sind mit Ihrem Remote-Branch fertig – Sie und Ihre Mitarbeiter sind fertig mit einer neuen Funktion und haben sie in den `master`-Branch des Remote-Servers (oder in welchem Branch auch immer sich Ihr stabiler Code befindet) einfließen lassen. +Sie können einen Remote-Branch löschen, indem die Anweisung `git push` zusammen mit der Option `--delete` ausführen. +Wenn Sie Ihren `serverfix`-Branch vom Server löschen wollen, führen Sie folgende Anweisung aus: [source,console] ---- @@ -203,4 +215,4 @@ To https://github.com/schacon/simplegit - [deleted] serverfix ---- -Basically all this does is remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it's often easy to recover. +All dies entfernt im Grunde nur den Zeiger auf dem Server. Der Git-Server behält normalerweise die Daten dort noch eine Weile, bis eine Müllsammlung (garbage collection) durchgeführt wird, wenn also versehentlich was gelöscht wurde, ist es häufig einfach wiederherzustellen. \ No newline at end of file diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 654eb6c75..c2169a6cf 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,63 +1,63 @@ -=== Branching Workflows +=== Branching-Arbeitsabläufe -Now that you have the basics of branching and merging down, what can or should you do with them? -In this section, we'll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle. +Jetzt haben Sie die Grundlagen des Verzweigens (Branching) und Zusammenführens (Merging) kennengelernt. Und was können oder sollten Sie damit anfangen? +In diesem Abschnitt werden wir einige gewöhnliche Arbeitsabläufe behandeln, welche dieses leichtgewichtige Verzweigen ermöglicht, sodass Sie entscheiden können, ob Sie es in Ihren eigenen Entwicklungszyklus einbinden möchten. -==== Long-Running Branches +==== Langfristige Branches (((branches, long-running))) -Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. -This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. +Da Git ein einfaches 3-Wege-Merge verwendet, ist mehrmaliges Zusammenführen von einem Branch in einen anderen über einen langen Zeitraum generell einfach zu bewerkstelligen. +Das bedeutet, Sie können mehrere Branches haben, die immer offen sind und die Sie für unterschiedliche Stadien Ihres Entwicklungszyklus verwenden; Sie können regelmäßig welche davon mit anderen zusammenführen. -Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch – possibly only code that has been or will be released. -They have another parallel branch named `develop` or `next` that they work from or use to test stability – it isn't necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. -It's used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they're ready, to make sure they pass all the tests and don't introduce bugs. +Viele Git-Entwickler haben einen Arbeitsablauf, welcher den Ansatz verfolgt, nur vollkommen stabilen Code im `master`-Branch zu haben – möglicherweise auch nur Code, der released wurde oder werden soll. +Sie haben einen weiteren parallelen Branch namens `develop` oder `next`, auf dem Sie arbeiten oder den Sie für Stabilitätstests nutzen - dieser ist nicht zwangsläufig stabil, aber wann immer er einen stabilen Zustand erreicht, kann er mit dem `master`-Branch zusammengeführt werden. +Es wird benutzt, um Themen-Branches (kurzfristige Branches, wie Ihr früherer `iss53`-Branch) einfließen zu lassen, wenn diese fertiggestellt sind, um sicherzustellen, dass diese alle Tests bestehen und keine Fehler einschleppen. -In reality, we're talking about pointers moving up the line of commits you're making. -The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history. +Eigentlich reden wir gerade über Zeiger, die sich in der Reihe der Commits, die Sie durchführen, aufwärts bewegen. +Die stabilen Branches sind weiter hinten und die allerneuesten Branches sind weiter vorn im Verlauf. -.A linear view of progressive-stability branching +.Lineares Modell eines Branchings mit zunehmender Stabilität image::images/lr-branches-1.png[A linear view of progressive-stability branching.] -It's generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they're fully tested. +Es ist gewöhnlich einfacher, sich die verschiedenen Branches als Arbeitsdepots vorzustellen, in denen Sätze von Commits in stabilere Depots aufsteigen, sobald sie vollständig getestet wurden. [[lrbranch_b]] -.A ``silo'' view of progressive-stability branching +.``Depot''-Modell eines Branchings mit zunehmender Stabilität image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching.] -You can keep doing this for several levels of stability. -Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. -The idea is that your branches are at various levels of stability; when they reach a more stable level, they're merged into the branch above them. -Again, having multiple long-running branches isn't necessary, but it's often helpful, especially when you're dealing with very large or complex projects. +Sie können dies für mehrere Stabilitätsgrade beibehalten. +Einige größere Projekte haben auch einen Branch namens `proposed` (vorgeschlagen) oder `pu` (proposed updates – vorgeschlagene Updates), in welchem Branches integriert sind, die vielleicht noch nicht bereit sind, in den `next`- oder `master`-Branch einzufließen. +Die Idee dahinter ist, dass Ihre Branches verschiedene Stabilitätsgrade repräsentieren; sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt. +Nochmal, langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich, insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat. [[_topic_branch]] -==== Topic Branches +==== Themen-Branches (((branches, topic))) -Topic branches, however, are useful in projects of any size. -A topic branch is a short-lived branch that you create and use for a single particular feature or related work. -This is something you've likely never done with a VCS before because it's generally too expensive to create and merge branches. -But in Git it's common to create, work on, merge, and delete branches several times a day. +Themen-Branches sind in Projekten jeder Größe nützlich. +Ein Themen-Branch ist ein kurzlebiger Branch, welchen Sie für eine ganz bestimmte Funktion oder zusammengehörende Arbeiten erstellen und benutzten. +Das ist etwas, was Sie wahrscheinlich noch nie zuvor mit einem Versionsverwaltungssystem gemacht haben, weil es normalerweise zu aufwändig und mühsam ist, Branches zu erstellen und zusammenzuführen. +Aber bei Git ist es vollkommen üblich, mehrmals am Tag Branches zu erstellen, an ihnen zu arbeiten, sie zusammenzuführen und sie anschließend wieder zu löschen. -You saw this in the last section with the `iss53` and `hotfix` branches you created. -You did a few commits on them and deleted them directly after merging them into your main branch. -This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it's easier to see what has happened during code review and such. -You can keep the changes there for minutes, days, or months, and merge them in when they're ready, regardless of the order in which they were created or worked on. +Sie haben das im letzten Abschnitt an den Branches `iss53` und `hotfix` gesehen, die Sie erstellt haben. +Sie führten mehrere Commits auf diesen Branches durch und löschten sie sofort, nachdem Sie sie mit Ihrem Hauptbranch zusammengeführt haben. +Diese Technik erlaubt es Ihnen, schnell und vollständig den Kontext zu wechseln - da Ihre Arbeit auf verschiedene Depots aufgeteilt ist, wo alle Änderungen auf diesem Branch unter diese Thematik fallen, ist es leichter nachzuvollziehen, was bei Code-Überprüfungen und ähnlichem geschehen ist. +Sie können die Änderungen darin für Minuten, Tage oder Monate aufbewahren und sie einfließen lassen, wenn diese fertig sind, ungeachtet der Reihenfolge, in welcher diese erstellt oder bearbeitet wurden. -Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you're not sure is a good idea (`dumbidea` branch). -Your commit history will look something like this: +Betrachten wir folgendes Beispiel: Sie erledigen gerade einige Arbeiten (auf `master`), zweigen davon ab wegen eines Problems (`iss91`), arbeiten daran eine Weile, zweigen davon den zweiten Branch ab, um eine andere Möglichkeit zur Handhabung des selben Problems auszuprobieren (`iss91v2`), wechseln zurück zu Ihrem master-Branch und arbeiten dort eine Zeitlang, und zweigen dann dort nochmal ab, um etwas zu versuchen, bei dem Sie sich nicht sind, ob es eine gute Idee ist (`dumbidea`-Branch). +Ihre Commit-Verlauf wird in etwa so aussehen: -.Multiple topic branches -image::images/topic-branches-1.png[Multiple topic branches.] +.Mehrere Themen-Branches +image::images/topic-branches-1.png[Mehrere Themen-Branches.] -Now, let's say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. -You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two. -Your history then looks like this: +Angenommen, Sie haben sich jetzt entschieden, dass Ihnen die zweite Lösung für Ihr Problem (`iss91v2`) am besten gefällt; und Sie haben den `dumbidea`-Branch Ihren Mitarbeitern gezeigt und es hat sich herausgestellt, dass er genial ist. +Sie können also den ursprünglichen `iss91`-Branch (unter Verlust der Commits `C5` und `C6`) wegwerfen und die anderen beiden einfließen lassen. +Ihr Verlauf sieht dann so aus: -.History after merging `dumbidea` and `iss91v2` -image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.] +.Verlauf nach dem Einfließen von `dumbidea` und `iss91v2` +image::images/topic-branches-2.png[Verlauf nach dem Einfließen von `dumbidea` und `iss91v2`.] -We will go into more detail about the various possible workflows for your Git project in <<_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter. +In <<_distributed_git>> werden wir die verschiedenen möglichen Arbeitsabläufe für Ihr Git-Projket noch detaillierter betrachten. Bevor Sie sich also entscheiden, welches Branching-Modell Sie für Ihr nächstes Projekt nutzen wollen, sollten Sie unbedingt dieses Kapitel gelesen haben. -It's important to remember when you're doing all this that these branches are completely local. -When you're branching and merging, everything is being done only in your Git repository – no server communication is happening. +Während Sie das alles machen, ist es wichtig, daran zu denken, dass alle diese Branches nur lokal existieren. +Wenn Sie Branches anlegen und zusammenführen, geschieht das alles nur in Ihrem Git-Repository – es findet keine Server-Kommunikation statt. \ No newline at end of file From de35b871fd5f2d9404b7bc63c2b1550657cb10e3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Wed, 16 Jan 2019 10:08:01 +0100 Subject: [PATCH 2/7] Update nutshell.asc Korrigiere Rechtschreibung --- book/03-git-branching/sections/nutshell.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index db3d822ad..feeeba2bc 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -59,7 +59,7 @@ Das machen Sie mit der Anweisung `git branch`:(((git commands, branch))) $ git branch testing ---- -Dies erzeugt einen neuen Zeiger, der auf den selben Commit zeigt, auf dem Sie sich gegenwärtig befinden. +Dies erzeugt einen neuen Zeiger, der auf denselben Commit zeigt, auf dem Sie sich gegenwärtig befinden. .Zwei Branches, die auf die selbe Serie von Commits zeigen image::images/two-branches.png[Zwei Branches, die auf die selbe Serie von Commits zeigen.] @@ -128,7 +128,7 @@ image::images/checkout-master.png[HEAD bewegt sich, wenn Sie auschecken.] Diese Anweisung hat zwei Dinge bewirkt. Sie hat den Zeiger `HEAD` zurückbewegt, um auf den `master`-Branch zu zeigen, und sie verwandelte die Dateien in Ihrem Arbeitsverzeichnis zurück in den Zustand zum Zeitpunkt der Momentaufnahme, auf welche der `master`-Branch zeigt. -Dies bedeutet auch, dass die Änderungen, die Sie von diesem Punkt aus vornehmen, von einer älteren Verion des Projekts abzweigen werden. +Dies bedeutet auch, dass die Änderungen, die Sie von diesem Punkt aus vornehmen, von einer älteren Version des Projekts abzweigen werden. Sie macht im Grunde genommen die Änderungen rückgängig, die Sie auf Ihrem `testing`-Branch vorgenommen haben, sodass Sie in eine andere Richtung gehen können. [NOTE] From b5c1ec85618f3dbe0d71b3d1c30e58c149663825 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Fri, 8 Feb 2019 11:23:07 +0100 Subject: [PATCH 3/7] Update nutshell.asc Korrigiere Rechtschreibfehler. --- book/03-git-branching/sections/nutshell.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index feeeba2bc..9e8fd922d 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -6,7 +6,7 @@ Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Sc Wie Sie vielleicht von <<_getting_started>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von Momentaufnahmen. Wenn Sie einen Commit anlegen, dann speichert Git ein `commit`-Objekt, welches einen Zeiger zu der Momentaufnahme der Inhalte enthält, welche sich in der Staging Area bzw. im Index befinden. -Dieses Objekt beinhaltet den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und Zeiger zu dem Commit oder den Commits, welche direkt vor diesem Commit gemacht wurden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welche aus dem Zusammenführen von zwei oder mehr Branches resultiert. +Dieses Objekt beinhaltet den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und Zeiger zu dem Commit oder den Commits, welche direkt vor diesem Commit gemacht wurden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welcher aus dem Zusammenführen von zwei oder mehr Branches resultiert. Um das zu veranschaulichen, lassen Sie uns annehmen, Sie haben ein Verzeichnis, welches drei Dateien enthält, und Sie fügen alle Dateien zur Staging-Area hinzu und führen einen Commit durch. Durch das Hinzufügen der Dateien zur Staging Area erzeugt Git für jede Datei eine Prüfsumme (den SHA-1-Hashwert, den wir in <<_getting_started>> erwähnt haben), speichert diese Version der Datei im Git-Repository (Git verweist auf diese als Blobs) und fügt die Prüfsumme der Staging-Area hinzu: From f6ecad9620b3bee73cbe61d0427e94bdac96f35f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Fri, 8 Feb 2019 11:30:25 +0100 Subject: [PATCH 4/7] Update basic-branching-and-merging.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lösche Absatz des Originaltextes. --- .../sections/basic-branching-and-merging.asc | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 35744bdfb..e562b3d27 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -138,9 +138,6 @@ $ git commit -a -m 'finished the new footer [issue 53]' .Weitergeführte Arbeiten an `iss53` image::images/basic-branching-6.png[Weitergeführte Arbeiten an `iss53`.] -It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. -If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. - An dieser Stelle ist anzumerken, dass die Änderung, welche Sie auf Ihrem `hotfix`-Branch vorgenommen haben, nicht in den Dateien Ihres `iss53`-Branches enthalten ist. Wenn Sie diese einfließen lassen müssen, können Sie Ihren `master`-Branch mit der Anweisung `git merge master` mit Ihrem `iss53`-Branch zusammenführen, oder Sie können damit warten, diese Änderungen zu integrieren, bis Sie entscheiden, den `iss53`-Branch später in den `master`-Branch zurückzuführen. @@ -322,4 +319,4 @@ Conflicts: # ---- -Sie können dieser Commit-Nachricht noch Details darüber hinzufügen, wie Sie das Zusammenführen gelöst haben, wenn Sie denken, es könnte für künftige Betrachter dieses Commits hilfreich sein zu erklären, warum Sie getan haben, was Sie getan haben, falls es nicht offensichtlich ist. \ No newline at end of file +Sie können dieser Commit-Nachricht noch Details darüber hinzufügen, wie Sie das Zusammenführen gelöst haben, wenn Sie denken, es könnte für künftige Betrachter dieses Commits hilfreich sein zu erklären, warum Sie getan haben, was Sie getan haben, falls es nicht offensichtlich ist. From ed8e7e97d48708a5641ace6dc7b5a17c14acb076 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Fri, 8 Feb 2019 11:36:00 +0100 Subject: [PATCH 5/7] Update rebasing.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lösche Absatz vom Originaltext. --- book/03-git-branching/sections/rebasing.asc | 2 -- 1 file changed, 2 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 57e2e7e14..4292b016f 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -192,8 +192,6 @@ Wenn wir im vorhergehenden Szenario beispielsweise bei <<_pre_merge_rebase_work> * bestimmen, welche Commits nicht neu in den Zielbranch geschrieben wurden (bloß C2 und C3, da C4 der selbe Patch wie C4' ist) * diese Commits an der Spitze des Branches `teamone/master` anwenden -So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>. - Statt des Ergebnisses, welches wir in <<_merge_rebase_work>> sehen, würden wir etwas erhalten, was irgendwie mehr so wäre wie <<_rebase_rebase_work>>. [[_rebase_rebase_work]] From 6d5e6407ea95c854e766c7aa1255fae3677bd434 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Fri, 8 Feb 2019 11:40:06 +0100 Subject: [PATCH 6/7] Update basic-branching-and-merging.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lösche Leerzeile. --- book/03-git-branching/sections/basic-branching-and-merging.asc | 1 - 1 file changed, 1 deletion(-) diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index e562b3d27..4556ff4bc 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -177,7 +177,6 @@ Es ist wichtig herauszustellen, dass Git den besten gemeinsamen Vorgänger als G In Git ist das Zusammenführen dadurch wesentlich einfacher, als in diesen anderen Systemen. Da Ihre Änderungen jetzt eingeflossen sind, haben Sie keinen weiteren Bedarf mehr für den `iss53`-Branch. - Sie können das Ticket in Ihrem Ticket-Tracking-System schließen und den Branch löschen: [source,console] From 9e59856b77c3afeab5f18411ad010d5a52a812ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Fri, 8 Feb 2019 11:56:04 +0100 Subject: [PATCH 7/7] Update nutshell.asc Korrigiere Rechtschreibfehler. --- book/03-git-branching/sections/nutshell.asc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 9e8fd922d..71a3cbdfe 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -3,7 +3,7 @@ Um richtig zu verstehen, wie Git das Verzweigen realisiert, müssen wir einen Schritt zurückgehen und untersuchen, wie Git seine Daten speichert. -Wie Sie vielleicht von <<_getting_started>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern statt dessen als eine Reihe von Momentaufnahmen. +Wie Sie vielleicht von <<_getting_started>> in Erinnerung haben, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern stattdessen als eine Reihe von Momentaufnahmen. Wenn Sie einen Commit anlegen, dann speichert Git ein `commit`-Objekt, welches einen Zeiger zu der Momentaufnahme der Inhalte enthält, welche sich in der Staging Area bzw. im Index befinden. Dieses Objekt beinhaltet den Namen und die E-Mail-Adresse des Autors, die Nachricht, die Sie eingegeben haben, und Zeiger zu dem Commit oder den Commits, welche direkt vor diesem Commit gemacht wurden (zu seinem Vorgänger bzw. seinen Vorgängern): keine Vorgänger für den ersten Commit, einen Vorgänger für einen normalen Commit und mehrere Vorgänger für einen Commit, welcher aus dem Zusammenführen von zwei oder mehr Branches resultiert. @@ -61,8 +61,8 @@ $ git branch testing Dies erzeugt einen neuen Zeiger, der auf denselben Commit zeigt, auf dem Sie sich gegenwärtig befinden. -.Zwei Branches, die auf die selbe Serie von Commits zeigen -image::images/two-branches.png[Zwei Branches, die auf die selbe Serie von Commits zeigen.] +.Zwei Branches, die auf dieselbe Serie von Commits zeigen +image::images/two-branches.png[Zwei Branches, die auf dieselbe Serie von Commits zeigen.] Woher weiß Git, auf welchem Branch Sie gegenwärtig sind? Es besitzt einen speziellen Zeiger namens `HEAD`. @@ -174,7 +174,7 @@ Da ein Branch in Git in Wirklichkeit eine einfache Datei ist, welche die 40 Zeic Einen neuen Branch anzulegen, geht so schnell und ist so einfach, wie 41 Bytes in eine Datei zu schreiben (40 Zeichen und ein Zeilenumbruch). Dies steht in krassem Gegensatz zu der Art und Weise, wie die meisten älteren Werkzeuge zur Versionsverwaltung Branches anlegen, was das Kopieren aller Projektdateien in ein zweites Verzeichnis einschließt. -Das kann, in Abhängigkeit von der Projektgröße, mehrere Sekunden oder sogar Minuten dauern, während bei Git dieser Prozess augenlicklich erledigt ist. +Das kann, in Abhängigkeit von der Projektgröße, mehrere Sekunden oder sogar Minuten dauern, während bei Git dieser Prozess augenblicklich erledigt ist. Da wir außerdem immer die Vorgänger mit aufzeichnen, wenn wir einen Commit durchführen, wird automatisch die Suche nach einer geeigneten Basis für das Zusammenführen für uns erledigt, was dadurch in der Regel sehr einfach erledigt werden kann. Diese Funktionen tragen dazu bei, die Entwickler zu ermutigen, häufig Branches zu erstellen und zu nutzen.