Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Merge pull request #155 from timglabisch/d_long_term_branches2

[de] long term branches
  • Loading branch information...
commit 6c8115fc4cffd7699ba1972e1105faf46373e05f 2 parents 7218d25 + 63e53fe
Scott Chacon schacon authored

Showing 1 changed file with 1 addition and 1 deletion. Show diff stats Hide diff stats

  1. +1 1  de/03-git-branching/01-chapter3.markdown
2  de/03-git-branching/01-chapter3.markdown
Source Rendered
@@ -482,7 +482,7 @@ Now that you have the basics of branching and merging down, what can or should y
482 482 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.
483 483 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.
484 484
485   -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.
  485 +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.
486 486 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.
487 487
488 488 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).

0 comments on commit 6c8115f

Please sign in to comment.
Something went wrong with that request. Please try again.