[Git] [Git Flow] [SourceTree] Working branch, pushen, help!

[TheNephilim]

Sinds een tijdje aan de slag met git en gedwongen eens aan de slag gegaan met git flow. Nu moet ik eerlijk zeggen dat het idee me aanspreekt en wil er graag gebruik van maken.

Goed, een project waar ik aan werk gebranched. Een develop branch aangemaakt en daar in gaan werken. Altans, dat dacht is de bedoeling. Ik zit hier achter een Windows machine, heb SourceTree geïnstalleerd en werk met Bitbucket.

SourceTree geeft aan bij het commiten in welke branch ik werk en dat is develop. Echter, als ik push staan develop & master er beide in met ook beide vinkjes standaard aan. Dus...

Moet ik alleen pushen naar develop?

Dan kijk ik op Bitbucket en staan er 2 branches. Master (main) en develop. Bij develop staat behind: 2 en grijs gekleurd, ahead: ook 2 maar blauw. Dus ik ga er dan vanuit dat develop 2 commits voor loopt op master. Toch? Als ik dan klik op de branch develop (klikken op master kan niet), dan staat er weer "2 commits behind master. Sync now." Dus...

Wat is deze? Mijn working branch is toch develop en als ik daar naar push zou het andersom moeten zijn toch?

Kijk, ik snap dat er nog veel te doen is met het git flow gebeuren. Eigenlijk zou ik moeten werken met release en feature branches. Echter is dat voor deze website een beetje teveel van het goede. Gewoon een develop branch waar ik tegenaan develop (en die gedeployed word naar staging/preview) is hier even goed genoeg. De master branch moet straks naar productie, maar de website gaat voorlopig nog niet online.

Kunnen jullie helpen met deze praktische vragen? Misschien krijg ik het nog eens in de vingers

[Firesphere]

SourceTree heeft standaard inderdaad de actieve branches aangevinkt, maar als er niets te pushen valt naar een branch, wordt het daar ook niet heen gepushed.

Het vinkje heeft dus geen effect, het is alleen om aan te geven welke branches je wil pushen.

Je Master loopt nooit voor op de develop, als dat wel zo is, heb je waarschijnlijk ergens perongeluk naar de master gepushed in plaats van naar develop.
Dan kun je het beste je lokale checkout nalopen en de master in de develop mergen handmatig.

In principe werk je altijd op develop, daar push je ook naar toe.
Zodra je hele staging/preview akkoord is, maak je een release-branch versie 1.0 aan in SourceTree.
Deze finish je daarna, waardoor alle wijzigingen ook naar de Master worden gezet.

DAT is het moment dat je weer wel de Master moet pushen.

[mrwiggs]

Allereerst zou ik je aanraden het eerst via de commandline te doen om Git te leren begrijpen.

Hoe ik het doe:

master branch = production branch, hier staat alleen volledig werkende code in en die is gelijk aan de code op de productieserver

vervolgens maak ik voor elke feature die ik bouw een aparte branch aan, bijv. feature123. Als die klaar is, merge ik die weer met master en deploy ik hem.

Mocht je tijdens het bouwen van een feature snel een bugfix moeten verwerken, kun je vanaf de master branch een bugifx123 branch maken, bug oplossen, mergen met master en deployen.

Als feature123 daarna pas klaar is kun je hem gewoon mergen met master (evt. conflicten oplossen).

[Creepy]

Als je alleen commits doet in develop dan kan je master blijven pushen wat je wil, maar dat zorgt dan niet voor veranderingen. Met pushen van een branche duw je alleen de commits door die jij lokaal hebt staan naar een remote git repo. Als je je beide branches in sync wil houden dan kan je die dus altijd pushen naar github.

Dat behind is per branche. Dus als jij lokaal twee commits doet in develop, dan loopt develop op github dus twee commits achter. Als iemand anders een commit doet in develop en dat pusht naar jouw github, dan is jouw lokale develop dus 1 commit achter.

[ Voor 27% gewijzigd door Creepy op 19-03-2014 11:59 ]

[Caelorum]

Snooby schreef op woensdag 19 maart 2014 @ 11:55:
Allereerst zou ik je aanraden het eerst via de commandline te doen om Git te leren begrijpen.[...]

Ik lees dit wel vaker, maar snap de redenering erachter nog steeds niet. Als je Git wilt begrijpen lees je gewoon de documentatie. De commandline heeft daar verder niet zo veel mee te maken. Ik denk zelfs dat een goede GUI met wat diagrammen er in alles duidelijker kan maken dan die commandline ooit zal kunnen. Die commandline zou ik dan ook alleen maar aan beginnen als de GUI niet meer toereikend is.

[mrwiggs]

Caelorum schreef op woensdag 19 maart 2014 @ 12:14:
[...]

Ik lees dit wel vaker, maar snap de redenering erachter nog steeds niet. Als je Git wilt begrijpen lees je gewoon de documentatie. De commandline heeft daar verder niet zo veel mee te maken. Ik denk zelfs dat een goede GUI met wat diagrammen er in alles duidelijker kan maken dan die commandline ooit zal kunnen. Die commandline zou ik dan ook alleen maar aan beginnen als de GUI niet meer toereikend is.

Door de command line te gebruiken weet je wat er gebeurt. Door het drukken op een knop in een GUI weet je niet welke Git-commando's er worden uitgevoerd. Het lijkt me essentieel voor mensen die beginnen met Git te weten wat wat doet.

[Caelorum]

Een knop pull of push is nou niet echt rocketscience nadat je de documentatie hebt doorgenomen. Die knoppen zijn in SourceTree vaak een 1 op 1 vertaling van de achterliggende commando's.

[TheNephilim]

Firesphere schreef op woensdag 19 maart 2014 @ 11:54:
SourceTree heeft standaard inderdaad de actieve branches aangevinkt, maar als er niets te pushen valt naar een branch, wordt het daar ook niet heen gepushed.

Het vinkje heeft dus geen effect, het is alleen om aan te geven welke branches je wil pushen.

Oké dat klinkt ook wel logisch. Gewoon alle vinkjes aan laten staan dus, als ik die branches wil pushen.

Je Master loopt nooit voor op de develop, als dat wel zo is, heb je waarschijnlijk ergens perongeluk naar de master gepushed in plaats van naar develop.
Dan kun je het beste je lokale checkout nalopen en de master in de develop mergen handmatig.

Bij de merge, van mijn develop <-> master verhaal, gaf hij wel aan 'van develop naar master'. Dus het zal wel kloppen, al is de zinsopbouw van het eerste sync gedeelte wat vaag.

In principe werk je altijd op develop, daar push je ook naar toe.
Zodra je hele staging/preview akkoord is, maak je een release-branch versie 1.0 aan in SourceTree.
Deze finish je daarna, waardoor alle wijzigingen ook naar de Master worden gezet.

DAT is het moment dat je weer wel de Master moet pushen.

Oké ik zit misschien nog te veel in Bitbucket te kijken, zal ook eens die merges in SourceTree doen. Releases zal ik eens gaan bekijken. Snap het idee wel en het lijkt me ook erg handig, maar veel van de website die we maken gaan worden ontwikkeld, krijgen een beetje feedback en gaan dan online. Weinig vlees voor een release misschien.

Al zou het logisch zijn als ik begin in develop (en die deploy naar staging) en pas als de website online gaat, een release maak, die push naar master en dan ook deploy. Tot die tijd is de master dan leeg?

---

Snooby schreef op woensdag 19 maart 2014 @ 11:55:
Allereerst zou ik je aanraden het eerst via de commandline te doen om Git te leren begrijpen.

Ik ben erg visueel ingesteld. Al kan ik de cmd best waarderen, maar hiervoor heb ik liever een GUI. Daarmee moet ik volgens mij prima uit kunnen vinden hoe Git werkt en wat ik ermee kan.

Hoe ik het doe:

master branch = production branch, hier staat alleen volledig werkende code in en die is gelijk aan de code op de productieserver

vervolgens maak ik voor elke feature die ik bouw een aparte branch aan, bijv. feature123. Als die klaar is, merge ik die weer met master en deploy ik hem.

Mocht je tijdens het bouwen van een feature snel een bugfix moeten verwerken, kun je vanaf de master branch een bugifx123 branch maken, bug oplossen, mergen met master en deployen.

Als feature123 daarna pas klaar is kun je hem gewoon mergen met master (evt. conflicten oplossen).

Duidelijk! In SourceTree zit zelfs een 'git flow' knopje (), waarmee je dat klaarblijkelijk initaliseert.

---

Creepy schreef op woensdag 19 maart 2014 @ 11:56:
Als je alleen commits doet in develop dan kan je master blijven pushen wat je wil, maar dat zorgt dan niet voor veranderingen. Met pushen van een branche duw je alleen de commits door die jij lokaal hebt staan naar een remote git repo. Als je je beide branches in sync wil houden dan kan je die dus altijd pushen naar github.

Zoals ik hierboven al aangaf, ik moet denk ik eens alles proberen te doen vanuit SourceTree, ook het mergen dus. Nu krijg ik een pull melding in SourceTree omdat ik in Bitbucket de merges gedaan heb.

Begin het al te snappen!

Dat behind is per branche. Dus als jij lokaal twee commits doet in develop, dan loopt develop op github dus twee commits achter. Als iemand anders een commit doet in develop en dat pusht naar jouw github, dan is jouw lokale develop dus 1 commit achter.

Oké dat spreekt voor zich. Ik werk overigens tot zover altijd alleen aan een website, dus dat hele teamgebeuren zal ik ook nog eens moeten oefenen. Als je meerdere mensen hebt die aan verschillende delen van één website werken. Bijvoorbeeld handig als een stagiaire om de hoek komt kijken. Die laat je misschien eerder een klein onderdeel maken of aanpassing doen. Dan kan ik het bekijken (in Bitbucket) en eventueel mergen naar master als ik het goed genoeg vind. Toch?

---

Heb al heel wat dingen gelezen over het git flow gebeuren. Vooral https://www.atlassian.com/git/workflows#!workflow-gitflow is erg handig! Toch moet alles even op z'n plaats vallen in de praktijk denk ik.

[Firesphere]

Om dit topic een schop te geven.

Ik heb met m'n collega een meningsverschil.

Hij is van mening dat ook hotfixes gepushed moeten worden "zodat collega's zien welke hotfix er loopt".

Met als gevolg, dat er erg veel hotfixes van hem op de remote blijven staan.

Ikzelf vind dat een hotfix een single issue quickfix zou moeten zijn, en dat het in zo min mogelijk commits, zonder push naar de remote moet worden afgesloten.

Mijn voorkeur is, als ik het goed zie, gelijk aan wat atlassian zegt.

Maar we worden het niet eens. Iemand die zich verplicht voelt z'n mening te geven hierover?

[Tacow]

Een hotfix is bedoeld om in 1 of een paar commits een aanpassing te doen op de master branch.
Naarmate dit meestal hoge prioriteit heeft (anders moet het gewoon bij een volgende release meekomen),
lijkt het me dus ook logisch dat deze zo snel mogelijk toegepast wordt.

Het naar de server pushen van zo'n wijziging lijkt me niet nodig, als het goed is communiceren jullie als team met elkaar en weet je dus precies wie welke hotfixes aan het doen zijn.

Als je zoveel hotfixes hebt dat je het overzicht niet meer hebt, dan zijn dat geen hotfixes meer te noemen..


Kortom, ik geef jou volledig gelijk

[royduin]

Gewoon een aantal "resources" mbt Git Flow:

Ik heb deze naast me op de muur hangen (mocht je met Git Flow even in de knoei zitten):



Waarschijnlijk ben je deze twee al tegen gekomen:
- http://nvie.com/posts/a-successful-git-branching-model/
- http://danielkummer.github.io/git-flow-cheatsheet/

Houdt altijd in het achterhoofd dat Git Flow een richtlijn is, niet de heilige graal!

[ Voor 29% gewijzigd door royduin op 01-08-2014 17:01 ]

[Firesphere]

Zijn argumenten voor, zijn trouwens opvallend.

Namelijk dat je ziet wat er in die branch is gebeurd (AKA, ik zeg, dat kun je aan de tag zien).
Dan weet je dat iemand met een hotfix bezig is, als die 3 dagen duurt. (Als een hotfix 3 dagen duurt, is het geen hotfix/had je de hotfix branch nog niet moeten starten, maar eerst het probleem vinden en identificeren)

Mijn argumenten:
Als je de hotfixes pusht, en niet opruimt, heb je kans dat iemand perongeluk/expres in die hotfix gaat werken. Dat is onwenselijk.
Een hotfix gaat om een enkele issue. Totdat je de issue kan reproduceren en fixen, start je de hotfix nog niet (collega wel, die start de hotfix op het moment van melden vanuit de klant).

Ik ben van mening dat alleen features en evt. releases (een release hoort eigenlijk ook uit zo min mogelijk commits te bestaan) naar de remote mogen, en dat hotfixes absoluut alleen lokaal blijven, tenzij je je lokale repository niet vertrouwd.

[robkorv]

Bekijk deze workflow eens:

Simpele uitleg -> https://guides.github.com/introduction/flow/
Achtergrond artikel -> http://scottchacon.com/2011/08/31/github-flow.html

Voor veel projecten is een master als stable production en al het werk doen in topic branches voldoende. Dit kan je eventueel uitbreiden met een develop branch als je met releases gaat werken. Je merged dan topic branches voor de volgende release naar de develop, fixes voor de productie gaan naar master.

Als je applicatie nog niet gereleased is heb je niet eens een flow nodig. Wel raad ik je aan om voor elke wijziging een topic branch vanuit de master te maken en na test en review pas weer te mergen. Je maakt branches zodat andere geen last hebben van de steeds wijzigende code.

[Creepy]

Als je Git aan het gebruiken bent om in de gaten te gaan houden hoe lang iemand ergens aan bezig is, dan gebruik je git verkeerd. Dat kan echt geen argument zijn. Gewoon de hotfix doen op de branch waarvan je je stable tags maakt. Nieuwe tag en gaan

[Firesphere]

Creepy schreef op zaterdag 02 augustus 2014 @ 16:40:
Als je Git aan het gebruiken bent om in de gaten te gaan houden hoe lang iemand ergens aan bezig is, dan gebruik je git verkeerd. Dat kan echt geen argument zijn. Gewoon de hotfix doen op de branch waarvan je je stable tags maakt. Nieuwe tag en gaan

Nja, het gaat hem niet om het "checken hoe lang iemand bezig is", maar om dat je via pushes, in ieder geval kan zien dat *mocht* een hotfix lang duren, het versienummer direct publiek is, ipv dat je conflicting versie-nummers kan krijgen.