Softwarequalitätsmanagement - Versionsgeschichte

Drlue: /* Beispiel */

2021-02-23T19:56:13Z

Beispiel

← Nächstältere Version		Version vom 23. Februar 2021, 19:56 Uhr
Zeile 353:		Zeile 353:
	'''Repository'''<br>'''https://gitlab.drlue.at/root/webservice.git'''		'''Repository'''<br>'''https://gitlab.drlue.at/root/webservice.git'''

	'''Aufgabe'''<br>{{Link\|Branch}} ~~'''~~feature_login''' soll in '''development''' gemerged und anschließend gepusht werden.		'''Aufgabe'''<br>'''{{Link\|Branch}} feature_login''' soll in '''{{Link\|Branch}} development''' gemerged und anschließend soll '''development''' gepusht werden.
	{{BML\|code=		{{BML\|code=
	#Clonen des Repositories		#Clonen des Repositories

Drlue: /* Beispiel */

2021-02-23T19:55:20Z

Beispiel

← Nächstältere Version		Version vom 23. Februar 2021, 19:55 Uhr
Zeile 351:		Zeile 351:
	== Beispiel ==		== Beispiel ==
	Im folgenden Beispiel soll veranschaulicht werden wie zwei {{Link\|Branch\|Branches}} zusammengeführt werden:		Im folgenden Beispiel soll veranschaulicht werden wie zwei {{Link\|Branch\|Branches}} zusammengeführt werden:
	* Das Repository: '''https://gitlab.drlue.at/root/webservice.git'''		'''Repository'''<br>'''https://gitlab.drlue.at/root/webservice.git'''
	* Aufgabe: {{Link\|Branch}} '''feature_login''' soll in '''development''' gemerged und anschließend gepusht werden
			'''Aufgabe'''<br>{{Link\|Branch}} '''feature_login''' soll in '''development''' gemerged und anschließend gepusht werden.
	{{BML\|code=		{{BML\|code=
	#Clonen des Repositories		#Clonen des Repositories

Drlue: /* Beispiel */

2021-02-23T19:54:45Z

Beispiel

← Nächstältere Version		Version vom 23. Februar 2021, 19:54 Uhr
Zeile 352:		Zeile 352:
	Im folgenden Beispiel soll veranschaulicht werden wie zwei {{Link\|Branch\|Branches}} zusammengeführt werden:		Im folgenden Beispiel soll veranschaulicht werden wie zwei {{Link\|Branch\|Branches}} zusammengeführt werden:
	* Das Repository: '''https://gitlab.drlue.at/root/webservice.git'''		* Das Repository: '''https://gitlab.drlue.at/root/webservice.git'''
	* {{Link\|Branch}} '''feature_login''' soll in '''development''' gemerged und anschließend gepusht werden		* Aufgabe: {{Link\|Branch}} '''feature_login''' soll in '''development''' gemerged und anschließend gepusht werden
	{{BML\|code=		{{BML\|code=
	#Clonen des Repositories		#Clonen des Repositories
Zeile 359:		Zeile 359:
	cd webservice		cd webservice
	#Initial befinden wir uns im Main Branch und wechseln auf feature_login.		#Initial befinden wir uns im Main Branch und wechseln auf feature_login.
	#Dies ist nötig, da nach dem clonen noch keine lokale Version von feature_login vorhanden ist, nur die ~~Remote~~ Version		#Dies ist nötig, da nach dem clonen noch keine lokale Version von feature_login vorhanden ist, nur die remote Version
	git checkout feature_login		git checkout feature_login
	#Wechseln auf development, damit auch dieser Branch lokal verfügbar ist		#Wechseln auf development, damit auch dieser Branch lokal verfügbar ist

Drlue: /* Qualitätskontrolle Pull/Merge Requests */

2021-02-23T19:53:30Z

Qualitätskontrolle Pull/Merge Requests

← Nächstältere Version		Version vom 23. Februar 2021, 19:53 Uhr
Zeile 336:		Zeile 336:

	== Qualitätskontrolle Pull/Merge Requests ==		== Qualitätskontrolle Pull/Merge Requests ==
	Für eine leichtere Lesbarkeit wird im Folgenden nur noch von '''Merge Request''' gesprochen. Je nach ~~verwendetem~~ '''Git''' ~~System~~ wird ein anderer Begriff dafür verwendet:		Für eine leichtere Lesbarkeit wird im Folgenden nur noch von '''Merge Request''' gesprochen. Je nach verwendeter '''Git Platform''' wird ein anderer Begriff dafür verwendet:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
Zeile 347:		Zeile 347:
	\| [https://gitlab.com Gitlab] \|\| Merge Request		\| [https://gitlab.com Gitlab] \|\| Merge Request
	\|}		\|}
	In größeren Softwareprojekten, erfolgt die Qualitätskontrolle sehr oft über '''Merge Requests'''. Wird ein neues '''Feature''' entwickelt, so erfolgt eine Abzweigung vom aktuellen Entwicklungsbranch '''development''' {{Link\|Branch}} (natürlich ist auch das Abzweigen von anderen {{Link\|Branch\|Branches}} möglich). Der Entwickler programmiert, {{Link\|Commit_2\|commitet}} und {{Link\|Push\|pusht}}, solange an dem '''Feature''' gearbeitet wird, nur im eigenen {{Link\|Branch}}. Von Zeit zu Zeit kann es nötig sein, dass der eigene {{Link\|Branch}} mit den Änderungen aus dem '''development''' {{Link\|Branch}} aktualisiert werden muss, dies kann über {{Link\|Merge\|merge}} oder {{Link\|Rebase\|rebase}} stattfinden. Ist das '''Feature''' abgeschlossen, so startet der '''Merge Request'''. Dieser wird meist über die Webseite ~~des~~ verwendeten '''Git''' ~~Systems~~ gestartet. Ein anderer Entwickler erhält den '''Merge Request''' und übernimmt die Qualitätskontrolle, den '''Peer Review'''. Dabei wird die Funktionalität, Coding Conventions, usw. geprüft. Gibt es nichts zu beanstanden, so erfolgt, der eigentliche {{Link\|Merge_2\|Merge}} in den gewünschten {{Link\|Branch}}. Ansonsten wird der '''Merge Request''' für weitere Verbesserungen zurückgewiesen und muss dann erneut gestellt werden.		In größeren Softwareprojekten erfolgt die Qualitätskontrolle sehr oft über '''Merge Requests'''. Wird ein neues '''Feature''' entwickelt, so erfolgt eine Abzweigung vom aktuellen Entwicklungsbranch '''development''' {{Link\|Branch}} (natürlich ist auch das Abzweigen von anderen {{Link\|Branch\|Branches}} möglich). Der Entwickler programmiert, {{Link\|Commit_2\|commitet}} und {{Link\|Push\|pusht}}, solange an dem '''Feature''' gearbeitet wird, nur im eigenen {{Link\|Branch}}. Von Zeit zu Zeit kann es nötig sein, dass der eigene {{Link\|Branch}} mit den Änderungen aus dem '''development''' {{Link\|Branch}} aktualisiert werden muss, dies kann über {{Link\|Merge\|merge}} oder {{Link\|Rebase\|rebase}} stattfinden. Ist das '''Feature''' abgeschlossen, so startet der '''Merge Request'''. Dieser wird meist über die Webseite der verwendeten '''Git Platform''' gestartet. Ein anderer Entwickler erhält den '''Merge Request''' und übernimmt die Qualitätskontrolle, den '''Peer Review'''. Dabei wird die Funktionalität, Coding Conventions, usw. geprüft. Gibt es nichts zu beanstanden, so erfolgt, der eigentliche {{Link\|Merge_2\|Merge}} in den gewünschten {{Link\|Branch}}. Ansonsten wird der '''Merge Request''' für weitere Verbesserungen zurückgewiesen und muss dann erneut gestellt werden.

	== Beispiel ==		== Beispiel ==

Drlue: /* Rebase/Merge */

2021-02-23T19:51:12Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 19:51 Uhr
Zeile 331:		Zeile 331:
	<gallery widths="300" heights="234">		<gallery widths="300" heights="234">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' ~~{{Link\|Branch}}~~ wird mit '''Master''' ~~{{Link\|Branch}}~~ '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature Branch''' wird mit '''Master Branch''' '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>
	Datei:Rebase-then-merge.svg\|3) '''Merge''' von '''Feature''' ~~{{Link\|Branch}}~~ in den '''Master''' ~~{{Link\|Branch}}~~<ref name="git_graphics"/>		Datei:Rebase-then-merge.svg\|3) '''Merge''' von '''Feature Branch''' in den '''Master Branch'''<ref name="git_graphics"/>
	</gallery>		</gallery>

Drlue: /* Rebase/Merge */

2021-02-23T19:50:30Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 19:50 Uhr
Zeile 328:		Zeile 328:
	=== Rebase/Merge ===		=== Rebase/Merge ===
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden geht jedoch verloren, wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden geht jedoch verloren, wenn kein '''Merge Commit erzwungen wird'''.
	<gallery widths="300" heights="234">		<gallery widths="300" heights="234">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>

Drlue: /* Rebase/Merge */

2021-02-23T19:50:00Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 19:50 Uhr
Zeile 328:		Zeile 328:
	=== Rebase/Merge ===		=== Rebase/Merge ===
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden geht jedoch verloren, wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="300" heights="234">		<gallery widths="300" heights="234">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>

Drlue: /* Rebase/Merge */

2021-02-23T18:59:46Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 18:59 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="~~400~~" heights="~~312~~">		<gallery widths="300" heights="234">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>

Drlue: /* Rebase/Merge */

2021-02-23T18:58:29Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 18:58 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="400" heights="~~400~~">		<gallery widths="400" heights="312">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>

Drlue: /* Rebase/Merge */

2021-02-23T18:57:22Z

Rebase/Merge

← Nächstältere Version		Version vom 23. Februar 2021, 18:57 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="400">		<gallery widths="400" heights="400">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>

← Nächstältere Version		Version vom 23. Februar 2021, 18:59 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="~~400~~" heights="~~312~~">		<gallery widths="300" heights="234">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>

← Nächstältere Version		Version vom 23. Februar 2021, 18:58 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="400" heights="~~400~~">		<gallery widths="400" heights="312">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>

← Nächstältere Version		Version vom 23. Februar 2021, 18:57 Uhr
Zeile 329:		Zeile 329:
	Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.		Eine Kombination aus beidem ist eine sehr gebräuchliche Vorgehensweise. Wird an einem '''Feature''' gearbeitet, so erfolgt zuerst ein '''Rebase''' mit dem {{Link\|Branch\|Zielbranch}} und dann wird in den {{Link\|Branch\|Zielbranch}} '''gemerged'''. Dadurch bleibt die '''History''' geradlinig.
	Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''		Die Information welche {{Link\|Commit\|Commits}} im '''Feature Branch''' erzeugt wurden, geht jedoch verloren wenn kein '''Merge Commit erzwungen wird'''
	<gallery widths="400">		<gallery widths="400" heights="400">
	Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>		Datei:Forked-history.svg\|500px\|1) Ausgangssituation<ref name="git_graphics"/>
	Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>		Datei:Git-rebase.svg\|2) '''Feature''' {{Link\|Branch}} wird mit '''Master''' {{Link\|Branch}} '''rebased''' (ACHTUNG 3ter Knödel bei Feature Branch fehlt)<ref name="git_graphics"/>