Skip to content
This repository

[de] long term branches #155

Merged
merged 2 commits into from over 2 years ago

2 participants

Tim Glabisch Scott Chacon
Tim Glabisch

make it readable in german and fix some articles

Scott Chacon schacon merged commit 6c8115f into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.

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).

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.