Wow. Habe noch nie so eine Art von Git(hub)-Video gesehen. Jemand der mal wirklich zeigt, wie es in einem Unternehmen laufen sollte mit Github. Klasse Video. Sehr informativ und habe noch den einen oder anderen Tipp mitnehmen können. Vielen Dank :)
Das ist echt das beste Video was ich zu dem Thema Gitflow gefunden habe. Ich habe schon seit langem mit dem Thema Branches, Pull Requests usw. meine Struggles gehabt. Aber jetzt ist die schwere Zeit endlich vorbei. Ich bin überglücklich das ich, dass jetzt auch verstehe
Danke, wie immer sehr informativ! Mich hat schon eine ganze weile interessiert was denn Github ist und warum es so fame is... Jetzt weiss ich endlich was das ist und dass es für mich nichts ist da ich alleine und lokal arbeite... Trotzdem Danke, cool zu wissen! 👍
Also GitHub != GitFlow. Auch wenn du Alleine Entwickelt würde ich zu 200% GitHub und Git nutzen weil es dir sehr sehr viele Vorteile bringt. GitFlow, das worum es in diesem Video geht ist ein Konzept für die Zusammenarbeit im Team mit Git :)
@@UnleashedDesign 🤣🤣🤣👍 Ein Freund sah deine Antwort und blieb beim "!=" hängen und ich musste lachen weil mir das nicht mal auffiel sondern selbstverständlich war... Also den Nutzen von GitHub check ich dann wirklich nicht, gerade wenn ich alleine und fast ausschließlich lokal arbeite (ich gehe nur online zum veröffentlichen usw.). Vielleicht kannst du ja mal ein Video machen und das mal erklären/zeigen... Falls du mal Zeit und Lust hast oder dir die Ideen für neue Videos ausgehen (was ich nicht glaube, hast wahrscheinlich mehr Themen als umsetzbar wäre...)
Etwas bequemer ist es auch, wenn man den "Develop"-Branch als "Default" markiert. Dann wird dieser direkt beim Clone ausgecheckt und in der UI wird er dann auch bei einigen Aktionen immer standardmäßig ausgewählt. Erspart ein paar Klicks und u.U. etwas Ärger...
Den dev branch kann man sich theoretisch auch sparen und direkt in den Master mergen, da die Features ha getestet und vollständig sein sollten, bevor sie gemerged werden.
Jetzt bin ich aber baff. Wir arbeiten genau so in der Firma wo ich arbeite und konnte mir gar net vorstellen, dass du Vor kurzem erst davon hörtest. Macht auf jedenfall Sinn so zu arbeiten
@@UnleashedDesign hab extra nochmal auf das Veröffentlichungsdatum geschaut und 2 Monate. Aber ja, da wurde das Video hochgeladen, ich weiß ;-) War auch nicht böse gemeint. Achso, sind hier auf dem Kanal meine ersten 2 Posts. Dann lass ich einfach gleich mal ein Lob da. Top Kanal, super erklärt und auch wenn ich Dinge schon kenne, schau ich es mir trotzdem an ;-) Also, bis dende....
15:27 da bin ich nicht mitgekommen. Fehlt da dieser Schritt wenn man den main in den develop branch merged? Ansonsten ein tolles Video und genau das, was ich gerade dringend brauche!
Tolles Video. Könntest du noch was dazu sagen ob du einen Stage branch verwendest der um den Kunden Änderungen usw. Zu zeigen oder wie machst du das um dem Kunden Features zu präsentieren bevor sie live gehen.
Du hast am Anfang git flow erklärt aber das, was du im github durchspielst ist ein ganz normaler MANUELLER git Workflow und hat eigentlich nichts mit git flow zu tun. Ein Beispiel: du gehst im github hin und merged dein feature manuell in develop und löscht den feature Branch manuell. Nach git flow wäre es so: du commitest deine Anpassungen und wenn du meinst alles ist gut (evtl. durch einen PR absegnen lassen), dann beendest du dein Feature über git flow (git flow feature finish XYZ). Was git flow jetzt macht: * git flow merged dein Feature in den develop * git flow löscht den Featurebranch Das, was du händisch macht, macht gitflow. Und vor Allem hilft git flow ja dabei, das man nichts vergisst (so wie du das löschen des Releasebranches). Und was bringt dir das Erstellen der Regeln, wenn du ein manuelles Löschen erlaubst :/ Ich hätte mir gewünscht, dass du dir etwas mehr zeit für commit messages und vor Allem das squashing genommen hättest. Ein unerfahrener Entwickler wird nach dem Video höchstens im github rumklicken können, aber nicht wissen, was git flow ist, nämlich eine Sammlung und autom. Ausführen von best Practices. Die beste Anlaufstelle ist wohl danielkummer.github.io/git-flow-cheatsheet/
Ergänzend dazu, wenn ein Release erstellt wurde und gefinished wurde, merged Git-Flow automatisch in Master UND Develop! In deinem Video merged du erst in den Master und nach einem erneuten "OK" durch zwei weitere Devs geht es erst in den Develop. Und der Versions-Tag wird nach meinen Erfahrungen direkt beim Erstellen des Releases erstellt.
Hatte ja zu Beginn gesagt das es kein Video für jemand ist der noch nie gut genutzt hat. Die Seite die du verlinkt hast kannte ich aber noch nicht werde ich mir mal ansehen klingt spannend. 👌
Hi, wo kommt denn die Nummer hinter #{nummer} her? Wenn ich eine neue Feature Branch anlegen weiß man doch vorher was es für ne ID sein soll. Noch ne andere Frage: Wird beim Review nur der Code angeschaut oder hat der Reviewer auch ne funktionierende Anwendung um alles zu testen? Nur vom Ansehen des Codes kann man doch eigentlich kein vernünftiges Review machen oder hab ich da nen Denkfehler?
Testen != Review. Bei einer Code Review geht es nicht darum sicherzustellen das es Funktioniert. In der Regel hat der Entwickler ja Unittests geschrieben und die Funktionsweise ausreichen selbst getestet. Es geht mehr darum das jemand ohne Tiefe Kenntnisse des Codes diesesn Lesen, Verstehen und ggf. Erweitern/Warten könnte. Also es wird viel auf Naming, Struktur, Vorgehen, Dokumentation und Kompatibilität geachtet weniger das die Funktionen erfüllt sind. (Natürlich startet man als Reviewer aber auch die Anwendung in den jeweiligen Branch um zu testen, aber es steht halt nicht im Fokus eines Reviews). Ob der Code Korrekt Funktioniert wird meistens je nach größe des Teams von enem Tester durchgeführt.
@@UnleashedDesign danke für die Erklärung. Aus der Praxis kann ich sagen, das Unittests zwar die Regel sein sollten, aber da ist einfach keine Zeit. Am Donnerstag kommt ein Featurwunsch bzw. Änderungen, die so dringend sind, dass es Montag fertig sein muss. Meist fällt erst dem Tester auch auf, welche Grenzfälle man noch bedenken muss. Das hat der Entwickler einfach nicht auf dem Schirm, komplett alle Fälle abzudecken. Aber du hast recht, das sind zwei verschiedene paar Schuhe. Danke nochmal fürs einordnen :-)
Nutzt mir nichts wenn mir GitHub sagt, das ich erst mal dafür in meine Tasche greifen muss. Das wurde hier in dem Video nicht erwähnt, oder übersehe ich etwas?
In dem Video geht es um GIT am Beispiel von GitHub :) es gibt viele Dienste die, diese Funktionen bieten und das auch gratis. Auch GitHub ist soweit ich weis gratis zumindest die wichtigsten Features
git ist cool. Noch Cooler sind z.b in gitlab die CI/CD Pipelines zum deployen von verschiedensten Branches auf verschiedensten URL's mittels k8s, docker, helm/helmCharts als Infrastruktur. Wie habe ich es vor git gemacht: Nun ja, ich hatte viele Ordner mit Versionen auf meinem Filesystem und habe, wenn ich mir dachte das wäre i.o., einen diff gemacht. Nach dem diff musste ich es per FTP dementsprechend hochladen. Und wenn man denn noch konfigurations Files anpassen musste, d.h. wenn diese local und live unterschiedlich sind, ist es ne kack arbeit, da man immer was vergisst. Deswegen helm wo man auch environment Variablen einfügen kann die dann auch unterschiedlich von URL zu URL sein kann. Beispielsweise MailURL's, Keys, DB-Zugänge usw. Aber sehr schönes Video, sehr verständlich weil gleich mit einem Tutorial dazu!! TOP!
kann ich dir zu zustimmen, also CI/CD bei GitLab sind deutlich "übersichtlicher" (Nutze es dort selbst). Aber man muss dazu sagen das man bei GitHub die Aktions hat was quasi genau die gleiche Funktion bietet nur halt etwas mehr richtung NPM & Azure Cloud. Aber es ist schon deutlich schöner mit solchen Pipelines zu arbeiten bei großen Projekten.
Der Masterbranch erhält über den Releasebranch die Features aus den Featurebranches. Der Master muss (und sollte) also nicht zurück in den develop gemerged werden. Erst Recht nicht dann, wenn die Entwicklung bereits fortgeschritten ist und der develop dem master voraus ist.
@@The4tticuz Aber der Fix vom Release Branch hat es doch so wie es im Video gezeigt wurde niemals in den develop Branch geschafft, oder? Der Fix war ja niemals auf dem develop Branch und der entsprechend Release Branch wurde nach dem Merge in Master gelöscht. Oder habe ich hier Einen Denkfehler drinnen?
@@LastChaosTyp Nein du hast keinen Denkfehler :) Das ist ein Problem von diesem Tutorial. Es zeigt leider überhaupt nicht den git flow - Workflow. Es ist nämlich so: wenn du in einem Releasebranch einen Fix mergest, dann wird nach git flow beim Schließen von diesem Fix der Bugfix Branch (eigentlich) automatisch gelöscht. Wenn dein Release dann fertig ist und geschlossen wird, ist es eigentlich (nach git flow) so: * Release wird per git flow beendet (git flow release finish XYZ) * git flow merged das Release in den master * GIT FLOW MERGED DAS RELEASE IN DEN DEVELOP (!) * git flow löscht den Releasebranch * git flow erstellt das Release Tag Der ganze Workflow im Video hat kaum was mit git flow zu tun und bei dem wilden Geklicke ist es meiner Meinung nach verständlich, dass unerfahrene Entwickler nicht mitkommen. Um git flow zu verstehen, würde ich die Konsole empfehlen. Hier sagt dir git flow sogar genau, was es gerade gemacht hat (wenn du z.B. ein Feature beendet hast). Schau dir mal diesen Link an, das macht es wahrscheinlich leichter danielkummer.github.io/git-flow-cheatsheet/
Kann man so machen... muss man aber nicht... gerade in größeren Entwicklerteams und bzw. besonders bei festen Releaseterminen ist dieser Workflow eher ungeeignet...
Also habe es schon in sehr großen Projekten eingesetzt, auch mit festen Release Terminen. Also es funktioniert wunderbar da es ja kein "Workflow" bzw. eine Art der Arbeitsteilung wie z.B. Scrum ist sondern nur eine Art sein Git zu Strukturieren.
ich kannte das quasi seit ich Freiberuflich gearbeitet habe auch nur so ;) also seit Jahren aber du glaubst nicht wie viele "große" Unternehmen nicht so arbeiten und teilweise sogar alle auf dem Master Commiten xD
@@UnleashedDesign oha, okay 😅 Haben die dann überhaupt sowas wie Jenkins oder Travis? Clean Code Development wahrscheinlich komplett an den vorbei gegangen 😂
Ja hier... 😂😂😂 unternehmen mit ca 800 Mitarbeitern. Davon ca. 12 Entwickler... alles immer auf den Master... wenn ein dringender Bug kam, wurden die Änderungen manuell kopiert... immer wieder grosser Aufwand. Man kannte es nicht anders... vor ca. einem Jahr habe ich es mal vorgestellt... hat bis heute gedauert, bis man es akzeptiert hat.
Git und GitLab sind ja zwei unterschiedliche Themen und würde hier jedem empfehlen einfach Git und die Consolen Commands zu lernen :) weil man im Alltag eh jeden Hoster (GitHub/BitBucket/GitLab usw.) nutzen wird
![GitHub Beginner Tutorial in 20 Minuten deinen Workflow verbessern! [Deutsch/Tutorial]](http://i.ytimg.com/vi/0jzjz4MZ4ZU/mqdefault.jpg)
![GitHub Beginner Tutorial in 20 Minuten deinen Workflow verbessern! [Deutsch/Tutorial]](/img/tr.png)
GitFlow ist wirklich essenziell. Wenn mich mal wieder jemand fragt, wie das genau funktioniert, weiß ich sofort, welches Video ich empfehlen kann.
Haha nice danke :)
Wow. Habe noch nie so eine Art von Git(hub)-Video gesehen. Jemand der mal wirklich zeigt, wie es in einem Unternehmen laufen sollte mit Github. Klasse Video. Sehr informativ und habe noch den einen oder anderen Tipp mitnehmen können. Vielen Dank :)
Freut mich wenn dir das Video gefällt :)
Das ist echt das beste Video was ich zu dem Thema Gitflow gefunden habe. Ich habe schon seit langem mit dem Thema Branches, Pull Requests usw. meine Struggles gehabt. Aber jetzt ist die schwere Zeit endlich vorbei. Ich bin überglücklich das ich, dass jetzt auch verstehe
Das freut mich sehr wenn dir das Video helfen konnte um zu verstehen wie das alles funktioniert :)
👍 Gut erklärt, gerne mehr git videos! :]
Vielleicht sowas wie Squash oder CherryPick...
Wird kommen aber erst im nächsten Jahr denke ich :)
Durchhalte vermögen zahlt sich aus - tolle videos, hast dir jeden Sub verdient!
musste grade kurz überlegen :D dein Name kam mir aber direkt bekannt vor :) danke
Danke, wie immer sehr informativ! Mich hat schon eine ganze weile interessiert was denn Github ist und warum es so fame is... Jetzt weiss ich endlich was das ist und dass es für mich nichts ist da ich alleine und lokal arbeite... Trotzdem Danke, cool zu wissen! 👍
Also GitHub != GitFlow. Auch wenn du Alleine Entwickelt würde ich zu 200% GitHub und Git nutzen weil es dir sehr sehr viele Vorteile bringt. GitFlow, das worum es in diesem Video geht ist ein Konzept für die Zusammenarbeit im Team mit Git :)
@@UnleashedDesign 🤣🤣🤣👍
Ein Freund sah deine Antwort und blieb beim "!=" hängen und ich musste lachen weil mir das nicht mal auffiel sondern selbstverständlich war...
Also den Nutzen von GitHub check ich dann wirklich nicht, gerade wenn ich alleine und fast ausschließlich lokal arbeite (ich gehe nur online zum veröffentlichen usw.).
Vielleicht kannst du ja mal ein Video machen und das mal erklären/zeigen... Falls du mal Zeit und Lust hast oder dir die Ideen für neue Videos ausgehen (was ich nicht glaube, hast wahrscheinlich mehr Themen als umsetzbar wäre...)
Etwas bequemer ist es auch, wenn man den "Develop"-Branch als "Default" markiert.
Dann wird dieser direkt beim Clone ausgecheckt und in der UI wird er dann auch bei einigen Aktionen immer standardmäßig ausgewählt.
Erspart ein paar Klicks und u.U. etwas Ärger...
das ist eine echt gute idee, hab ich noch nicht dran gedacht.
Den dev branch kann man sich theoretisch auch sparen und direkt in den Master mergen, da die Features ha getestet und vollständig sein sollten, bevor sie gemerged werden.
Jetzt bin ich aber baff. Wir arbeiten genau so in der Firma wo ich arbeite und konnte mir gar net vorstellen, dass du Vor kurzem erst davon hörtest. Macht auf jedenfall Sinn so zu arbeiten
Naja vor kurzem ist relativ 😂😂😂
@@UnleashedDesign hab extra nochmal auf das Veröffentlichungsdatum geschaut und 2 Monate. Aber ja, da wurde das Video hochgeladen, ich weiß ;-) War auch nicht böse gemeint. Achso, sind hier auf dem Kanal meine ersten 2 Posts. Dann lass ich einfach gleich mal ein Lob da. Top Kanal, super erklärt und auch wenn ich Dinge schon kenne, schau ich es mir trotzdem an ;-) Also, bis dende....
super schnell und super praktisch erklärt! Top!
Danke freut mich wenn dir das Video geholfen hat :)
15:27 da bin ich nicht mitgekommen. Fehlt da dieser Schritt wenn man den main in den develop branch merged? Ansonsten ein tolles Video und genau das, was ich gerade dringend brauche!
Normalerweise wird der Release branch in den Main UND den develop branch gemerged. ✌🏻
Tolles Video. Könntest du noch was dazu sagen ob du einen Stage branch verwendest der um den Kunden Änderungen usw. Zu zeigen oder wie machst du das um dem Kunden Features zu präsentieren bevor sie live gehen.
main = master branch?
Ja
Super, sehr schön erklärt. Vielen Dank
PS: Klappt natürlich auch mit GITEA
Danke freut mich wenn dir das Video helfen konnte :)
Super Danke.
Freut mich wenn es dir gefällt :)
Aus welchem Buch/Information quellen hat du das video erarbeitet?
Internet, Blogs und persönlichen Erfahrungen über Jahre :)
Du hast am Anfang git flow erklärt aber das, was du im github durchspielst ist ein ganz normaler MANUELLER git Workflow und hat eigentlich nichts mit git flow zu tun.
Ein Beispiel:
du gehst im github hin und merged dein feature manuell in develop und löscht den feature Branch manuell.
Nach git flow wäre es so:
du commitest deine Anpassungen und wenn du meinst alles ist gut (evtl. durch einen PR absegnen lassen), dann beendest du dein Feature über git flow (git flow feature finish XYZ).
Was git flow jetzt macht:
* git flow merged dein Feature in den develop
* git flow löscht den Featurebranch
Das, was du händisch macht, macht gitflow.
Und vor Allem hilft git flow ja dabei, das man nichts vergisst (so wie du das löschen des Releasebranches).
Und was bringt dir das Erstellen der Regeln, wenn du ein manuelles Löschen erlaubst :/
Ich hätte mir gewünscht, dass du dir etwas mehr zeit für commit messages und vor Allem das squashing genommen hättest.
Ein unerfahrener Entwickler wird nach dem Video höchstens im github rumklicken können, aber nicht wissen, was git flow ist, nämlich eine Sammlung und autom. Ausführen von best Practices.
Die beste Anlaufstelle ist wohl
danielkummer.github.io/git-flow-cheatsheet/
Ergänzend dazu, wenn ein Release erstellt wurde und gefinished wurde, merged Git-Flow automatisch in Master UND Develop! In deinem Video merged du erst in den Master und nach einem erneuten "OK" durch zwei weitere Devs geht es erst in den Develop. Und der Versions-Tag wird nach meinen Erfahrungen direkt beim Erstellen des Releases erstellt.
Hatte ja zu Beginn gesagt das es kein Video für jemand ist der noch nie gut genutzt hat. Die Seite die du verlinkt hast kannte ich aber noch nicht werde ich mir mal ansehen klingt spannend. 👌
Hi, wo kommt denn die Nummer hinter #{nummer} her? Wenn ich eine neue Feature Branch anlegen weiß man doch vorher was es für ne ID sein soll. Noch ne andere Frage: Wird beim Review nur der Code angeschaut oder hat der Reviewer auch ne funktionierende Anwendung um alles zu testen? Nur vom Ansehen des Codes kann man doch eigentlich kein vernünftiges Review machen oder hab ich da nen Denkfehler?
Testen != Review. Bei einer Code Review geht es nicht darum sicherzustellen das es Funktioniert. In der Regel hat der Entwickler ja Unittests geschrieben und die Funktionsweise ausreichen selbst getestet. Es geht mehr darum das jemand ohne Tiefe Kenntnisse des Codes diesesn Lesen, Verstehen und ggf. Erweitern/Warten könnte. Also es wird viel auf Naming, Struktur, Vorgehen, Dokumentation und Kompatibilität geachtet weniger das die Funktionen erfüllt sind. (Natürlich startet man als Reviewer aber auch die Anwendung in den jeweiligen Branch um zu testen, aber es steht halt nicht im Fokus eines Reviews). Ob der Code Korrekt Funktioniert wird meistens je nach größe des Teams von enem Tester durchgeführt.
@@UnleashedDesign danke für die Erklärung. Aus der Praxis kann ich sagen, das Unittests zwar die Regel sein sollten, aber da ist einfach keine Zeit. Am Donnerstag kommt ein Featurwunsch bzw. Änderungen, die so dringend sind, dass es Montag fertig sein muss. Meist fällt erst dem Tester auch auf, welche Grenzfälle man noch bedenken muss. Das hat der Entwickler einfach nicht auf dem Schirm, komplett alle Fälle abzudecken. Aber du hast recht, das sind zwei verschiedene paar Schuhe. Danke nochmal fürs einordnen :-)
Nutzt mir nichts wenn mir GitHub sagt, das ich erst mal dafür in meine Tasche greifen muss. Das wurde hier in dem Video nicht erwähnt, oder übersehe ich etwas?
In dem Video geht es um GIT am Beispiel von GitHub :) es gibt viele Dienste die, diese Funktionen bieten und das auch gratis. Auch GitHub ist soweit ich weis gratis zumindest die wichtigsten Features
git ist cool. Noch Cooler sind z.b in gitlab die CI/CD Pipelines zum deployen von verschiedensten Branches auf verschiedensten URL's mittels k8s, docker, helm/helmCharts als Infrastruktur. Wie habe ich es vor git gemacht: Nun ja, ich hatte viele Ordner mit Versionen auf meinem Filesystem und habe, wenn ich mir dachte das wäre i.o., einen diff gemacht. Nach dem diff musste ich es per FTP dementsprechend hochladen. Und wenn man denn noch konfigurations Files anpassen musste, d.h. wenn diese local und live unterschiedlich sind, ist es ne kack arbeit, da man immer was vergisst. Deswegen helm wo man auch environment Variablen einfügen kann die dann auch unterschiedlich von URL zu URL sein kann. Beispielsweise MailURL's, Keys, DB-Zugänge usw.
Aber sehr schönes Video, sehr verständlich weil gleich mit einem Tutorial dazu!! TOP!
kann ich dir zu zustimmen, also CI/CD bei GitLab sind deutlich "übersichtlicher" (Nutze es dort selbst). Aber man muss dazu sagen das man bei GitHub die Aktions hat was quasi genau die gleiche Funktion bietet nur halt etwas mehr richtung NPM & Azure Cloud. Aber es ist schon deutlich schöner mit solchen Pipelines zu arbeiten bei großen Projekten.
Ich finde cool dass es so ein Video auf UA-cam gibt, jedoch hast du meiner Meinung alles zu schnell erklärt :)
seh ich genauso, und das sagt einer mit einem tldw Akronym.
Fehlte da nicht noch der letzte Schritt? Also den Stand vom Master in den anderen Branches zu etablieren?
Der Masterbranch erhält über den Releasebranch die Features aus den Featurebranches. Der Master muss (und sollte) also nicht zurück in den develop gemerged werden. Erst Recht nicht dann, wenn die Entwicklung bereits fortgeschritten ist und der develop dem master voraus ist.
@@The4tticuz Aber der Fix vom Release Branch hat es doch so wie es im Video gezeigt wurde niemals in den develop Branch geschafft, oder? Der Fix war ja niemals auf dem develop Branch und der entsprechend Release Branch wurde nach dem Merge in Master gelöscht. Oder habe ich hier Einen Denkfehler drinnen?
@@LastChaosTyp Nein du hast keinen Denkfehler :) Das ist ein Problem von diesem Tutorial. Es zeigt leider überhaupt nicht den git flow - Workflow.
Es ist nämlich so: wenn du in einem Releasebranch einen Fix mergest, dann wird nach git flow beim Schließen von diesem Fix der Bugfix Branch (eigentlich) automatisch gelöscht.
Wenn dein Release dann fertig ist und geschlossen wird, ist es eigentlich (nach git flow) so:
* Release wird per git flow beendet (git flow release finish XYZ)
* git flow merged das Release in den master
* GIT FLOW MERGED DAS RELEASE IN DEN DEVELOP (!)
* git flow löscht den Releasebranch
* git flow erstellt das Release Tag
Der ganze Workflow im Video hat kaum was mit git flow zu tun und bei dem wilden Geklicke ist es meiner Meinung nach verständlich, dass unerfahrene Entwickler nicht mitkommen.
Um git flow zu verstehen, würde ich die Konsole empfehlen. Hier sagt dir git flow sogar genau, was es gerade gemacht hat (wenn du z.B. ein Feature beendet hast).
Schau dir mal diesen Link an, das macht es wahrscheinlich leichter
danielkummer.github.io/git-flow-cheatsheet/
@@LastChaosTyp Nein was du sagst is völlig richtig.
Kann man so machen... muss man aber nicht... gerade in größeren Entwicklerteams und bzw. besonders bei festen Releaseterminen ist dieser Workflow eher ungeeignet...
Also habe es schon in sehr großen Projekten eingesetzt, auch mit festen Release Terminen. Also es funktioniert wunderbar da es ja kein "Workflow" bzw. eine Art der Arbeitsteilung wie z.B. Scrum ist sondern nur eine Art sein Git zu Strukturieren.
danke dir
Gerne :)
Ich hab das gleiche Hintergrundbild😯
Guter Geschmack 😌
Ich kenne es nur so.
Wie hast du den bitte davor gearbeitet? :O
ich kannte das quasi seit ich Freiberuflich gearbeitet habe auch nur so ;) also seit Jahren aber du glaubst nicht wie viele "große" Unternehmen nicht so arbeiten und teilweise sogar alle auf dem Master Commiten xD
@@UnleashedDesign oha, okay 😅
Haben die dann überhaupt sowas wie Jenkins oder Travis?
Clean Code Development wahrscheinlich komplett an den vorbei gegangen 😂
Dont know 🤷♂️😅 vill ja vill nicht bei mir läuft alles über GIT Actions und docker 👌
@@UnleashedDesign 👌🏽
Ja hier... 😂😂😂 unternehmen mit ca 800 Mitarbeitern. Davon ca. 12 Entwickler... alles immer auf den Master... wenn ein dringender Bug kam, wurden die Änderungen manuell kopiert... immer wieder grosser Aufwand. Man kannte es nicht anders... vor ca. einem Jahr habe ich es mal vorgestellt... hat bis heute gedauert, bis man es akzeptiert hat.
ich würde ein Video git+gitlab bevorzugen
Git und GitLab sind ja zwei unterschiedliche Themen und würde hier jedem empfehlen einfach Git und die Consolen Commands zu lernen :) weil man im Alltag eh jeden Hoster (GitHub/BitBucket/GitLab usw.) nutzen wird
er muss ge-reviewed werden
echt jetzt ?
Weißt du überhaupt etwas über Git ????
Denke schon :) Hast du etwas gefunden das in dem Video nicht stimmt?