Merge pull request #155 from timglabisch/d_long_term_branches2

[de] long term branches

de/03-git-branching/01-chapter3.markdown

@@ -482,7 +482,7 @@ Now that you have the basics of branching and merging down, what can or should y
 Da Git das einfachen 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heisst, du kann mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen deines Entwicklungszyklus verwendung finden, und diese regelmäßig ineinander zusammenführen.
 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.
 
-Viele Git Entwickler verwenden einen Workflow, der den Ansatz unterstützt, der nur stabilen Code in der `master` Branch hält - möglicherweise nur Code, der released wurde oder werden kann. Sie führen parallel eine andere Branch zum Arbeiten oder Testen. Wenn diese einen stabilen Status erreicht, kann sie mit der `master` Branch zusammengeführt werden. Dies findet bei Themen bezogenen Branchen (kurzfristige Branches, wie die zuvor genante `iss53` Branch) Anwendung, um sicherzustellen, dass diese die Tests bestehen und keine Fehler verursachen.
+Viele Git Entwickler verwenden einen Workflow, der dem Ansatz folgt, nur stabilen Code in dem `master` Branch zu halten - idealerweise nur Code, der released wurde oder werden kann. Dazu wird parallel ein anderer Branch zum Arbeiten bzw. zum Testen geführt. Wenn dieser einen stabilen Status erreicht, kann er mit dem `master` Branch zusammengeführt werden. Dies findet bei themenbezogenen Branches (kurzfristige Branches, wie der zuvor erwähnte `iss53` Branch) Anwendung, um sicherzustellen, dass diese die Tests bestehen und keine Fehler verursachen.
 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.
 
 In Realität reden wir über sich bewegende Pointer, die die Commit Linie weiter wandern. The stabilen Branches liegen unten und die bleeding-edge Branches weiter oben in der Zeitlinie (siehe Abbildung 3-18).