[GIT] Productie .config merge

[ChaZy]

Hoi allemaal,

Mijn vraag is de volgende:

In de master branch heb ik een .config file zitten welke ik alleen een deze branch wil hebben zitten. Dus wanneer ik een merge ga doen van master naar demo wil ik niet dat deze in de demo branch komt te staan en andersom wil ik niet de de demo branch deze file overschrijft.

Ik heb al gekeken naar de oplossing met de "ours" merge driver in de .gitattributes, maar ik heb het idee dat deze niet werkt voor het excluden van file en alleen bij een merge conflict.

Ook heb ik gekeken naar .gitignore maar daar krijg ik het idee van dat deze dan de hele file niet "tracked" in git, maar dit is ook niet wat ik wil want mensen die wel rechten hebben op de master branch moeten deze file wel uit sourcecontrole kunnen halen.

Kort gezegd wil ik dus een file in mijn master branch hebben welke ge-exclude bij mergen naar andere branches.

Heeft iemand een idee of dit te realiseren is in GIT?

[EddoH]

De eerste vraag is waarom je master naar andere branches merged? In principe zou er alleen naar master gemerged moeten worden, niet andersom.

Het is verder natuurlijk heel gevaarlijk om files te excluden van mergen, je wilt juist bij verschillende branches de zekerheid dat ze na een merge gelijk zijn (of tenminste dat alle changes van branch A in zijn geheel in branch B zitten).

Ik zou een algemene dir maken waar de verschillende configs voor test,demo, acceptatie inzitten, samen met een script/setup whatever die de goede config op de (test/demo/acc) omgeving zet bij het deployen.

[ChaZy]

EddoH schreef op maandag 19 oktober 2015 @ 09:54:
De eerste vraag is waarom je master naar andere branches merged? In principe zou er alleen naar master gemerged moeten worden, niet andersom.

Hotfixes die op de master branch worden gedaan die zou ik ook terug willen mergen naar de demo. Of kies ik dan een verkeerde strategie?

EddoH schreef op maandag 19 oktober 2015 @ 09:54:
Het is verder natuurlijk heel gevaarlijk om files te excluden van mergen, je wilt juist bij verschillende branches de zekerheid dat ze na een merge gelijk zijn (of tenminste dat alle changes van branch A in zijn geheel in branch B zitten).

Eens maar juist deze file wil ik excluden omdat deze niet aangepast mag worden door gebruikers die rechten hebben om de demo branch maar geen rechten op de master branch. Daarom heb ik ook het liefst dat deze file helemaal niet in de demo branch terecht komt.

EddoH schreef op maandag 19 oktober 2015 @ 09:54:
Ik zou een algemene dir maken waar de verschillende configs voor test,demo, acceptatie inzitten, samen met een script/setup whatever die de goede config op de (test/demo/acc) omgeving zet bij het deployen.

Het gaat niet alleen om deployment, met deze config files kunnen er ook vanuit de ontwikkelomgeving, visual studio in dit geval, connectie gemaakt worden met de live omgeving. Dit wil ik niet voor iedereen mogelijk maken.

[Creepy]

EddoH schreef op maandag 19 oktober 2015 @ 09:54:
De eerste vraag is waarom je master naar andere branches merged? In principe zou er alleen naar master gemerged moeten worden, niet andersom.

Niet iedereen gebruikt gitflow, dus het is nogal kort door de bocht om te zeggen dat je vanuit master niet naar andere branches mmag ergen.

Anyway, configuratie die echt moet afwijken zou je niet in je repo moeten opnemen. Ook als je iets niet wilt mogelijk maken voor andere devvers, moet je het simpelweg niet inchecken. Je kan dan beter een config file opnemen met goede defaults en een andere file (die je dus niet incheckt) om die default mee te kunnen overriden.

[EddoH]

ChaZy schreef op maandag 19 oktober 2015 @ 10:16:
[...]


Hotfixes die op de master branch worden gedaan die zou ik ook terug willen mergen naar de demo. Of kies ik dan een verkeerde strategie?

Hotfixes zou ik op een aparte hotfix branch doen. Deze merge dan zowel anar master als naar demo.

Eens maar juist deze file wil ik excluden omdat deze niet aangepast mag worden door gebruikers die rechten hebben om de demo branch maar geen rechten op de master branch. Daarom heb ik ook het liefst dat deze file helemaal niet in de demo branch terecht komt.


[...]


Het gaat niet alleen om deployment, met deze config files kunnen er ook vanuit de ontwikkelomgeving, visual studio in dit geval, connectie gemaakt worden met de live omgeving. Dit wil ik niet voor iedereen mogelijk maken.

Als je zorgt dat master nooit gemerged wordt richting demo dan heb je het probleem helemaal niet
Voor zover ik weet is het niet mogelijk om files van een merge te excluden.

Creepy schreef op maandag 19 oktober 2015 @ 10:28:
[...]

Niet iedereen gebruikt gitflow, dus het is nogal kort door de bocht om te zeggen dat je vanuit master niet naar andere branches mmag ergen.

Ook zonder gitflow zie ik weinig goede redenen om master naar een andere branch te mergen eigenlijk...

[ Voor 38% gewijzigd door EddoH op 19-10-2015 10:42 ]

[Sardaukar]

EddoH schreef op maandag 19 oktober 2015 @ 10:39:
Ook zonder gitflow zie ik weinig goede redenen om master naar een andere branch te mergen eigenlijk...

Onzin. Voor Git is master een branch net als alle andere branches. Alleen omdat wij als gebruikers meestal afspreken dat master een bepaalde betekenis heeft wordt deze ook als bijzonder gezien.

Niets weerhoudt je echter om zelf een branchstructuur in te richten waarbij master een andere betekenis heeft (en waarbij het dus prima mogelijk is dat je vanuit master gaat mergen naar een andere branch).

[EddoH]

Ok zit wat in. Wellicht wat kortzichtig gedacht. Alleen is er natuurlijk wel een reden dat master in 90% van de gevallen zo gebruikt wordt..

[ Voor 48% gewijzigd door EddoH op 19-10-2015 10:59 ]

[CyBeR]

EddoH schreef op maandag 19 oktober 2015 @ 10:39:
[...]

Ook zonder gitflow zie ik weinig goede redenen om master naar een andere branch te mergen eigenlijk...

Onzin. Master merge je richting feature branches waar je een tijdje mee bezig bent zodat je up-to-date blijft met de wijzigingen in master en niet aan het einde van de rit een maand lang merge conflicts moet gaan zitten oplossen.

[EddoH]

CyBeR schreef op maandag 19 oktober 2015 @ 11:01:
[...]


Onzin. Master merge je richting feature branches waar je een tijdje mee bezig bent zodat je up-to-date blijft met de wijzigingen in master en niet aan het einde van de rit een maand lang merge conflicts moet gaan zitten oplossen.

Onzin. Dat doe je met develop branch, als we het toch over gitflow hebben.
Edit: schijnen diverse filosofiën over te bestaan. Wij mergen nooit master ergens heen. De orignele gitflow gedachte gaat er van uit dat master niet terug wordt gemerged.

[ Voor 17% gewijzigd door EddoH op 19-10-2015 11:08 ]

[Sardaukar]

EddoH schreef op maandag 19 oktober 2015 @ 10:58:
Alleen is er natuurlijk wel een reden dat master in 90% van de gevallen zo gebruikt wordt..

Er is geen enkele technische reden. (Probeer het maar eens: je kunt 'master' gewoon hernoemen of zelfs verwijderen).

[EddoH]

Sardaukar schreef op maandag 19 oktober 2015 @ 11:06:
[...]


Er is geen enkele technische reden. (Probeer het maar eens: je kunt 'master' gewoon hernoemen of zelfs verwijderen).

Dat snap ik, ik claim ook nergens dat dat technisch niet kan. Master heeft in veel gevallen een bepaalde semantiek, dat is wat ik bedoel.

[Sardaukar]

EddoH schreef op maandag 19 oktober 2015 @ 11:06:
[...]
Dat snap ik, ik claim ook nergens dat dat technisch niet kan. Master heeft in veel gevallen een bepaalde semantiek, dat is wat ik bedoel.

Master heeft alleen maar die semantiek die *jij* eraan geeft. Master heeft uit zichzelf geen enkele betekenis.

[EddoH]

Jaaahaa, ik bedoel dat 90% van de gebruikers van git dezelfde semantiek aan master geeft, omdat dit veelgemaakte problemen (kan)voorkomen en nu eenmaal wat duidelijkheid verschaft...

Jezus, is het maandag ofzo.

[XyritZz]

EddoH schreef op maandag 19 oktober 2015 @ 11:04:
[...]


Onzin. Dat doe je met develop branch, als we het toch over gitflow hebben.
Edit: schijnen diverse filosofiën over te bestaan. Wij mergen nooit master ergens heen. De orignele gitflow gedachte gaat er van uit dat master niet terug wordt gemerged.

Ligt er maar net aan hoe je het gebruikt. Zelf merk ik dat bij projecten met een hoge mate van ontwikkeling het onderscheid tussen master/develop gewenst is, maar bij kleinere projecten die traag ontwikkelen is dat totaal niet nodig en is enkel een master al ruim voldoende om netjes te werken. Develop voegt dan enkel overhead toe wat onnodig is.

Komt nog bij dat in de projecten die ik ken develop/master altijd identiek zijn qua inhoud. Het enige verschil is dat develop vaak voorloopt op master. Met andere woorden; dan zou je alsnog hetzelfde probleem hebben als wat beschreven wordt, je werkt dan alleen met een andere branch.

Persoonlijk zou ik de oplossing van dit probleem niet zoeken in de werkwijze met Git, maar in de structuur van je project. Als ik meerdere config files nodig heb dan zijn alle config files in alle branches beschikbaar; ik switch die op de server dan op basis van bijv. een environment variable.

[Sardaukar]

EddoH schreef op maandag 19 oktober 2015 @ 11:17:
Jaaahaa, ik bedoel dat 90% van de gebruikers van git dezelfde semantiek aan master geeft, omdat dit veelgemaakte problemen (kan)voorkomen en nu eenmaal wat duidelijkheid verschaft...

Jezus, is het maandag ofzo.

"Arguing with an engineer is like fighting a pig in mud. After the first few hours, you realise they enjoy it."

[CyBeR]

EddoH schreef op maandag 19 oktober 2015 @ 11:04:
[...]


Onzin. Dat doe je met develop branch, als we het toch over gitflow hebben.
Edit: schijnen diverse filosofiën over te bestaan. Wij mergen nooit master ergens heen. De orignele gitflow gedachte gaat er van uit dat master niet terug wordt gemerged.

Dat is weer een specifieke functie aan specifieke branches hangen en dat hadden we je net verteld is niet iets dat inherent is aan git maar slechts aan de werkwijze die jij zelf bedenkt.

[Sardaukar]

Ik heb zojuist een project opgeleverd waarbij we met 5 ontwikkelaars samenwerken.

Omdat een aantal mensen nog redelijk onbekend was met Git heb ik expliciet niet voor iets als Gitflow gekozen. Waarom? In mijn ogen teveel overhead voor kleinere projecten en het werkt alleen als iedereen ook goed op de hoogte is van Git.

Wat hebben we dan wel gedaan? Master beschouwen we als stable trunk. Voorwaarden om op te leveren naar master zijn: het doorloopt de gehele build inclusief alle unittesten.

Iedereen ontwikkelt in zijn eigen branch en rebased deze zodra men wil opleveren naar master.

Releases zijn tags op master. Indien nodig kunnen we hiervan een branch aanmaken indien we support moeten leveren op een specifieke versie.

Voor onze situatie werkte dit prima.

Weer even on-topic: ik denk dat ik ook iets met een environment variabele zou doen voor het probleem wat de poster aankaart.

[ Voor 9% gewijzigd door Sardaukar op 19-10-2015 11:29 ]

[Hydra]

EddoH schreef op maandag 19 oktober 2015 @ 09:54:
De eerste vraag is waarom je master naar andere branches merged? In principe zou er alleen naar master gemerged moeten worden, niet andersom.

Nee hoor. Het is doodnormaal om je master naar je feature branch te mergen voor je een pull request aanbiedt. Dan weet je zeker dat je eventuele merge conflicts al opgelost hebt.

ChaZy schreef op maandag 19 oktober 2015 @ 09:47:
In de master branch heb ik een .config file zitten welke ik alleen een deze branch wil hebben zitten.

Dat regel je in je build tool, niet in je versioning tool. Daarbij zet je nooit en te nimmer zaken als passwords in config files in je repo; die zijn namelijk erg lastig weer te verwijderen.

[ Voor 32% gewijzigd door Hydra op 19-10-2015 11:29 ]

[EddoH]

Hydra schreef op maandag 19 oktober 2015 @ 11:28:
[...]


Nee hoor. Het is doodnormaal om je master naar je feature branch te mergen voor je een pull request aanbiedt. Dan weet je zeker dat je eventuele merge conflicts al opgelost hebt.

Inderdaad dat ook nog. Sterker nog dat doe ik zelf ook weleens. Vergeet mijn eerder suggesties dan ook. Domme opmerking, maar dat is nu wel duidelijk. Misschien kan iedereen ook suggesties voor de TS geven. Het lijkt wel een the roast of EddoH

CyBeR schreef op maandag 19 oktober 2015 @ 11:22:
[...]


Dat is weer een specifieke functie aan specifieke branches hangen en dat hadden we je net verteld is niet iets dat inherent is aan git maar slechts aan de werkwijze die jij zelf bedenkt.

Ik ging ervan uit dat je het over het gitflow model had. En daar hebben specifieke branches inderdaad specifieke functies.
Ik snap git. Ik snap dat je branches willekeurige namen kan geven. Ik snap dat een branch alleen de semantiek heeft die jij eraan geeft. Mijn eerste post was bedoeld om de TS een suggestie te geven zodat zijn specifieke probleem deels opgelost zou worden, doormiddel van het toekennen van specifieke functies aan de naam van een branch. Het was kortzichtig en klopte niet, I know.

[ Voor 25% gewijzigd door EddoH op 19-10-2015 11:34 ]

[Hydra]

EddoH schreef op maandag 19 oktober 2015 @ 11:29:
Ik ging ervan uit dat je het over het gitflow model had. En daar hebben specifieke branches inderdaad specifieke functies.

Ook binnen gitflow is het gebruikelijk om voor het aanbieden van een PR eerst de branch waar je naar toe gaat mergen in jouw feature branch te mergen.

[EddoH]

Klopt. Niet aan gedacht. Voor mij is het ook maandag. Zie mijn eerdere post.

[Sardaukar]

Koffie dan maar?

[CyBeR]

EddoH schreef op maandag 19 oktober 2015 @ 11:29:
[...]

Het was kortzichtig en klopte niet, I know.

Mooi. Niet nog een keer doen he

[EddoH]

Sardaukar schreef op maandag 19 oktober 2015 @ 11:36:
Koffie dan maar?

Doe maar iets sterkers.

CyBeR schreef op maandag 19 oktober 2015 @ 11:37:
[...]

Mooi. Niet nog een keer doen he

Je mag een motie van wantrouwen indienen. Mijn account zal worden opgedoekt, ik zal geen enkele ondoordachte uitspraak meer kunnen doen, ik zal wenend over straat gaan en eenzaam sterven.

Is de TS nu al geholpen? Loopt een beetje offtopic dit.

[ChaZy]

Het lijkt er inderdaad steeds meer op dit dit geen probleem van GIT
(en mijn onkunde met GIT, Altijd jammer wanneer een ingehuurde kracht iets introduceert maar vervolgens geen kennis overdracht doet(!))
is maar van de structuur van het project ten opzichte van .config files.

Als ik alles goed begrijp moet ik naar "config management" tools o.i.d. gaan kijken en .config files uit de GIT flow houden.

[ Voor 15% gewijzigd door ChaZy op 19-10-2015 11:49 ]

[XyritZz]

ChaZy schreef op maandag 19 oktober 2015 @ 11:48:
Het lijkt er inderdaad steeds meer op dit dit geen probleem van GIT
(en mijn onkunde met GIT, Altijd jammer wanneer een ingehuurde kracht iets introduceert maar vervolgens geen kennis overdracht doet(!))
is maar van de structuur van het project ten opzichte van .config files.

Als ik alles goed begrijp moet ik naar "config management" tools o.i.d. gaan kijken en .config files uit de GIT flow houden.

Ligt er aan wat er in de config files staat. Wachtwoorden moet je niet in versiebeheer stoppen, dus als er wachtwoorden in staan zou ik een alternatief gaan zoeken voor het beheer hiervan.

Als er geen wachtwoorden in staan maar het meer globale configuratie is, dan zou ik gewoon meerdere config files naast elkaar in een map stoppen en iets inbouwen dat de juiste config pakt op basis van de omgeving waar de applicatie draait.

[ChaZy]

XyritZz schreef op maandag 19 oktober 2015 @ 12:02:
[...]
Ligt er aan wat er in de config files staat. Wachtwoorden moet je niet in versiebeheer stoppen, dus als er wachtwoorden in staan zou ik een alternatief gaan zoeken voor het beheer hiervan.

Als er geen wachtwoorden in staan maar het meer globale configuratie is, dan zou ik gewoon meerdere config files naast elkaar in een map stoppen en iets inbouwen dat de juiste config pakt op basis van de omgeving waar de applicatie draait.

Er staan inderdaad wel connectionstrings in naar azure e.d. Dat is ook de enige reden waarom ik deze config niet voor ieder gebruiker beschikbaar wil hebben.

[H!GHGuY]

Zoals iedereen zegt config files horen niet in je source control thuis, of toch op z'n minst niet op een locatie waar er iets mee gedaan wordt. Je kan ze bvb in een andere directory zetten waarvan je dan verwacht dat de user zelf de juiste file op de juiste plaats zet.

Maar om op je vraag te antwoorden:
Doe de merge gevolgd door een "git rm".
De volgende keren dat je merged zal git je niet meer lastig vallen met changes in die file.

[XyritZz]

ChaZy schreef op maandag 19 oktober 2015 @ 12:13:
[...]


Er staan inderdaad wel connectionstrings in naar azure e.d. Dat is ook de enige reden waarom ik deze config niet voor ieder gebruiker beschikbaar wil hebben.

In dat geval; weghalen uit versiebeheer en iets anders voor verzinnen . Kijk eens naar hoe grote frameworks het afhandelen, die hebben allemaal wel een systeem om configs vast te leggen zonder gevoelige data in versiebeheer te mikken.

[Hydra]

ChaZy schreef op maandag 19 oktober 2015 @ 11:48:
Het lijkt er inderdaad steeds meer op dit dit geen probleem van GIT
(en mijn onkunde met GIT, Altijd jammer wanneer een ingehuurde kracht iets introduceert maar vervolgens geen kennis overdracht doet(!))

Sorry hoor maar van iedere developer kan je verwachten dat 'ie iets generieks als git zichzelf eigen maakt. Je kunt niet altijd maar naar anderen wijzen.

[ChaZy]

Hydra schreef op maandag 19 oktober 2015 @ 14:11:
[...]
Sorry hoor maar van iedere developer kan je verwachten dat 'ie iets generieks als git zichzelf eigen maakt. Je kunt niet altijd maar naar anderen wijzen.

O zeker mag je dat ook verwachten en dat ben ik nu ook aan het doen (anders stel ik deze vraag niet ), maar als externe git implementeren terwijl die persoon ook niet de benodigde basis kennis heeft EN dan ook nog het bedrijf achter laten zonder overdracht? dan moet je het met me eens zijn dat dit geen juiste manier is om het bedrijf achter te laten.

[ Voor 3% gewijzigd door ChaZy op 19-10-2015 14:31 ]

[igmar]

ChaZy schreef op maandag 19 oktober 2015 @ 09:47:
In de master branch heb ik een .config file zitten welke ik alleen een deze branch wil hebben zitten. Dus wanneer ik een merge ga doen van master naar demo wil ik niet dat deze in de demo branch komt te staan en andersom wil ik niet de de demo branch deze file overschrijft.

Niet : Config files met prod info horen niet in git thuis. Die laat je door je build scripts van extern halen.

[ChaZy]

Misschien nog weer een hele andere vraag, maar kan iemand mij wat naslagwerk aanbevelen voor branch strategieen voor GIT?

[H!GHGuY]

Lees even deze reactie van me in een ander topic:
H!GHGuY in "[git] Naast develop & master een staging branch?"

Kijk gerust naar branch strategieën en in het bijzonder dit hoofdstuk in het git book
maar laat je hoofd ook niet dol maken. Het is belangrijkst dat je je eigen workflow in branches omzet.

Dat je naar aanleiding van wat je leest een betere/andere workflow kiest, met meer voordelen/minder nadelen (en dus ook een andere branch strategie) is waar het eigenlijk om draait.

[ Voor 10% gewijzigd door H!GHGuY op 21-10-2015 12:38 ]

[ChaZy]

H!GHGuY schreef op woensdag 21 oktober 2015 @ 12:36:
Lees even deze reactie van me in een ander topic:
H!GHGuY in "[git] Naast develop & master een staging branch?"

Kijk gerust naar branch strategieën en in het bijzonder dit hoofdstuk in het git book
maar laat je hoofd ook niet dol maken. Het is belangrijkst dat je je eigen workflow in branches omzet.

Dat je naar aanleiding van wat je leest een betere/andere workflow kiest, met meer voordelen/minder nadelen (en dus ook een andere branch strategie) is waar het eigenlijk om draait.

Super tof! dankjewel voor je antwoord.

[luxan]

Volgens mij kun je dit oplossen door elke branch een .config file te geven en gebruik te maken van de "ours" driver. In de demo branch laat je de .config file gewoon leeg. Hiermee trigger je een merge conflict dat door de "ours" driver opgelost word door het bestaande bestand in de eigen branch te gebruiken. Moet je wel goed blijven opletten dat het .config bestand aanwezig is in de demo branch zodat je niet alsnog je master .config in je demo branch merged.

Dat neemt overigens niet weg dat config management tools een betere oplossing zijn.

[gybrus]

Wat ik zou aanraden is om alle branches zoveel mogelijk hetzelfde te houden, dat betekend letterlijk elk bestand in elke branch identiek te houden.

Zoals eerder aangegeven is het aan te raden om belangrijke configuratie waardes buiten de git 'history' te houden, deze krijg je er namelijk NOOIT meer uit zonder de gehele git history op zijn gat te helpen. Binnen veel web gebaseerde/PHP projecten wordt daarom gekozen om 'credentials' leeg te laten en deze in een later stadium vanuit de enviroment in te laden.
Dit heeft als voordeel dat je zonder wijzigingen in je code voor verschillende platformen production, development en staging andere configuraties kan toepassen.

Een mooi voorbeeld is het Laravel PHP framework welke .env files gebruikt voor dit soort configuraties.

Meer informatie over .env files binnen Laravel: http://laravel.com/docs/5.1#environment-configuration

Wat branch management betreft is het gangbaar dat de master branch productie code bevat. Hier hoeft niks aan aangepast te worden voordat deze in productie gebruikt kan worden.

De development branch is de meest actieve branch, hier komen alle features op binnen. Om de ontwikkeling van nieuwe features zo makkelijk mogelijk te houden gebruikt men meestal feature branches tijdens de ontwikkeling van een nieuwe feature.

Features worden los getrokken vanuit development gezien dit de laatste versie van je code bevat en om zo conflicten tijdens de ontwikkeling met andere features minimaal te houden. Wanneer een feature af is gaat deze terug development in.

Om code vervolgens klaar te maken voor productie gaat men vaak vanuit development waar de laatste wijzigingen in staan, richting een release branch. Deze gaat wat nieuwe features betreft figuurlijk op slot en de focus komt nu te liggen op het fixen van bugs en eventuele ontwerp fouten.
Eenmaal klaar gaat deze richting zowel master als development zodat deze beide de bugfixes krijgen.

Is er achteraf toch iets aan de hand met de productie code wordt dit hotfixed. Dit komt er op neer dat op de 'hete' productie code een fix wordt toegepast. Dit wordt meestal vanuit master gedaan en gaat vervolgens richting de master branch en development.

Meer informatie over 'een' succesvol branching model: http://nvie.com/posts/a-successful-git-branching-model/

Tevens is het aan te raden om tijdens lange ontwikkel trajecten de feature branches up-to-date te houden met de development branch. Dit scheelt in een later stadium veel geneuzel met het fixen van conflicten.
Wat ik prefereer is om hier je code te 'rebasen' inplaats van 'mergen'. Dit laat de achterlijke "Merged 'x' into 'y'" namelijk achterwege en legt simpelweg jouw wijzigingen over de branch waarop je rebased.
Het kan dat er nog steeds conflicten optreden in zulke gevallen, maar deze worden dan meegenomen in jouw initiële commit en niet in een extra conflict commit.

Meer informatie over rebasen en git over het algemeen: https://git-scm.com/book/en/v2/Git-Branching-Rebasing