Git Clients

[Juup]

Tijd voor een discussie over git clients?
Mijn shortlist (allemaal werkend op macOS)

• GitHub Desktop³
• GitKraken¹
• SourceTree¹
• Tower⁴
• Fork

¹ Vereist applicatie-specifiek account aanmaken of linken
² Kan geen diff van 1 file tonen tussen twee verschillende (te kiezen) commits
³ Toont geen mooie/handige graph van branches en commits
⁴ Niet gratis

Screenshot van Fork (die gebruik ik nu)


Zo jammer dat die geen diff kan tonen van 1 (of meerdere) files over 2 te kiezen commits / branches.

Edit: Fork kan nu wel de verschillen tussen 2 commits laten zien. Cmd ingedrukt houden bij het selecteren van de 2e commit. Thanks Dan Pristupov!

[ Voor 8% gewijzigd door Juup op 24-02-2017 23:15 ]

[Kwistnix]

Gewoon Git op de command line vind ik t fijnst. Die grafische tools vind ik alleen maar verwarrend en beperkend.

[Creepy]

Juup schreef op zaterdag 28 januari 2017 @ 17:31:
Tijd voor een discussie over git clients?

Nee?

Tenzij je het topic iets meer wilt laten zijn dan een dom opsom topic. Dus voordelen, nadelen, etc. (en dat is meer dan de paar puntjes die je nu neerzet) Een beetje devver kan echt wel een git client vinden of de git opties in een IDE gebruiken

[Daos]

Kwistnix schreef op zaterdag 28 januari 2017 @ 18:36:
Gewoon Git op de command line vind ik t fijnst. Die grafische tools vind ik alleen maar verwarrend en beperkend.

Ben jij ook zo'n figuur die liever in een tekst-editor programmeert dan in een volwaardige IDE? Doet mij denken aan Mag mijn werkgever mijn code editor bepalen? Wat doe jij dan op de command-line wat niet in een grafisch programma kan?

Thuis gebruik ik Git GUI: ding dat met de installatie van git meekwam. Ik doe thuis niets anders dan committen en pushen en dit programma volstaat (al heb ik wel vaak last van vastlopers).

Op het werk gebruik ik SourceTree. Je ziet dan snel wat er in een commit of stash zit door er op te klikken. Je kan in SourceTree wel 2 commits vergelijken als je de command-toets ingedrukt houdt en er 2 selecteert. Grafische weergave van de branches vind ik ook erg handig. Dan zie je bv in 1 oogopslag welke branches nog niet gemerged zijn en je kan makkelijk spieken waar je collega's mee bezig zijn.

[Juup]

Daos schreef op zaterdag 28 januari 2017 @ 19:22:
Op het werk gebruik ik SourceTree. Je ziet dan snel wat er in een commit of stash zit door er op te klikken. Je kan in SourceTree wel 2 commits vergelijken als je de command-toets ingedrukt houdt en er 2 selecteert.

Als ze die feature nou porten naar Fork dan zou het echt helemaal goed zijn.

[Kwistnix]

Daos schreef op zaterdag 28 januari 2017 @ 19:22:
[...]


Ben jij ook zo'n figuur die liever in een tekst-editor programmeert dan in een volwaardige IDE? Doet mij denken aan Mag mijn werkgever mijn code editor bepalen? Wat doe jij dan op de command-line wat niet in een grafisch programma kan?

Nee. Ik gebruik wel de tool of werkwijze die wat mij betreft het best aansluit op wat ik wil bereiken. Voor Git is dat voor mij de command line. Sowieso is dat op Linux vaak iets waar je veel gemak van kan hebben, zeker in combinatie met een fatsoenlijke scripting taal, Ruby of zo.

[Hydra]

Daos schreef op zaterdag 28 januari 2017 @ 19:22:
Ben jij ook zo'n figuur die liever in een tekst-editor programmeert dan in een volwaardige IDE? Doet mij denken aan Mag mijn werkgever mijn code editor bepalen? Wat doe jij dan op de command-line wat niet in een grafisch programma kan?

Mijn programmeerwerk doe ik in IntelliJ (Java programmeren in een text-editor wil ik niemand aanraden) maar alles kwa Git doe ik via de command-line. Voor een commit moet je toch een commit-message intypen dus je moet je handen op je KB hebben, dan is een "git commit -am "<branch> Wat ik gedaan heb"" voor mij practischer dan een grafische client gebruiken.

Een ander voordeel is dat als ik een keer op een server inlog via SSH ofzo hetzelfde kan doen. Op een gegeven moment wordt dit gewoon muscle memory.

Dus nee, ik zie geen correlatie tussen het gebruiken van een IDE en grafische Git clients.

Een collega van me, ook Java dev die 't liefst op Linux werkt, vind me een complete idioot dat ik niet de IntelliJ UI hiervoor gebruik overigens

[ Voor 7% gewijzigd door Hydra op 29-01-2017 10:09 ]

[xehbit]

Gebruik eigenlijk het liefst zo veel mogelijk tools op de commandline, dat is voor mij toch het meest efficient (probeer zo veel mogelijk het gebruik van de muis te vermijden).

Naast alleen git op de commandline heb ik hier een aantal aliasses voor gemaakt waardoor ik nog sneller git kan gebruiken. Ook maak ik gebruik van tig (https://github.com/jonas/tig) om door de commits heen te browsen (vim like bindings) en gebruik ik de fugitive plugin voor vim (https://github.com/tpope/vim-fugitive).

[Matis]

Wij gebruiken SmartGit (Mac, Linux, Windows). Groot voordeel is dat je licentie persoonsgebonden is en je hem op zoveel machines mag gebruiken als je gebruikt.
De licentie is ook eenmalig. Gedurende een jaar mag je alle majors meenemen. Daarna binnen de major alle minors.
Met SmartGit 17 is ook DeepGit toegevoegd. Erg fijne aanvulling en voldoet aan je wensen.

Daarnaast heeft het ook goede integratie met Github, GitLab, Jira en een aantal andere (zakelijke) tools.

[Mercatres]

Op 't werk (en thuis) gebruik ik SourceTree. Echter is dat ding zo lomp aan het worden als je met meerdere (grotere) repos zit, dat ik op dit moment weer eerder naar de Git command line ga, toch voor simpele commits. Mergen doen we sowieso al vanuit VS2015 (omdat die beter context-aware werkt; behalve voor XML dan ).

[P_Tingen]

Voor mijn privé repo's gebruik ik gewoon de ingebouwde git ondersteuning van Eclipse of git gui en - als die tegenstribbelen - de cli. Andere grafische clients zijn voor mijn privédingetjes in ieder geval zwaar overkill en te lomp. Zo heb ik de github client al eens geprobeerd maar die was 127MB aan download en dat vond ik wat al te gek voor een grafische schil.

[steveman]

Ik red me (werk en privé) met commandline, soms Git Gui en zo nu en dan een blik op de webinterface van Bitbucket (thuis bitbucket.org, op 't werk hosten we hem zelf).

[GrooV]

Ik gebruik eigenlijk al jaren de command line, in het begin gebruikte ik GUI's maar met de cli begrijp je Git in eens een stuk beter.

Laatst nog eens met een lastige merge een Gui gebruikt (SmartGit volgens mij), en dat heeft me een dag werk gekost... nooit meer Git Gui's voor mij

[ Voor 36% gewijzigd door GrooV op 01-02-2017 12:03 ]

[Verwijderd]

Ik gebruik nu sinds een half jaar Git Extensions https://gitextensions.github.io/ , het ziet er grafisch wat ouderwets uit maar werkt snel en is overzichtelijk. Daarnaast wordt het nog steeds actief onderhouden.
Ook de mogelijke Windows Explorer en Visual Studio integratie werken goed

[pedorus]

Juup schreef op zaterdag 28 januari 2017 @ 17:31:
Zo jammer dat die geen diff kan tonen van 1 (of meerdere) files over 2 te kiezen commits / branches.

Dat klinkt wel als een erg basic functionaliteit die mist.. Bijvoorbeeld TortoiseGit heeft dit wel, en ik gebruik het voor alle files of een subdir tegelijkertijd (en dan eventueel inzoomen op een bepaalde file).

[peterrus_]

GrooV schreef op woensdag 1 februari 2017 @ 12:02:
Ik gebruik eigenlijk al jaren de command line, in het begin gebruikte ik GUI's maar met de cli begrijp je Git in eens een stuk beter.

Laatst nog eens met een lastige merge een Gui gebruikt (SmartGit volgens mij), en dat heeft me een dag werk gekost... nooit meer Git Gui's voor mij

Ik sluit me hier volledig bij aan. Het is in tegenstelling tot wat Daos zegt niet persé elitisme, maar veel git GUI's trachten de onderliggende concepten te maskeren, dat kan voor een beginner heel verwarrend zijn, vooral wanneer ze iets willen doen wat in die GUI niet kan, en vervolgens niets begrijpen van de officiële git documentatie. Overigens vind ik dat ze dit in GitKraken best netjes aanpakken, toch hou ik het zelf liever bij de command-line.

(En Daos: bovenstaand vind ik dan weer niet gelden voor een IDE

Edit: Pedorus, peterrus, toevallig

[ Voor 3% gewijzigd door peterrus_ op 04-02-2017 02:25 ]

[base_]

Heel leuk die gui's maar als developers me vragen hoe ze de gui client moeten instellen raad ik ze toch echt aan eerst even met de cli te beginnen, zeker als er nog niet eens verschillende branches of releases zijn en alleen een HEAD....

[ Voor 4% gewijzigd door base_ op 04-02-2017 03:07 ]

[Hydra]

base_ schreef op zaterdag 4 februari 2017 @ 03:06:
Heel leuk die gui's maar als developers me vragen hoe ze de gui client moeten instellen [...]

"Geen idee".

Sorry maar als je zonodig een grafische client wil installeren moet je dat toch echt zelf gaan regelen. Onderzoeken / uitvogelen is ongeveer je primaire taak als dev.

[pedorus]

Hydra schreef op zaterdag 4 februari 2017 @ 13:21:
[...]


"Geen idee".

Sorry maar als je zonodig een grafische client wil installeren moet je dat toch echt zelf gaan regelen. Onderzoeken / uitvogelen is ongeveer je primaire taak als dev.

Klinkt niet effectief als iedereen dat voor zichzelf moet gaan doen. En het is ook handig als meerderen dezelfde GUI-app gebruiken. En als het een keertje echt ingewikkeld wordt lever ik wel een lijstje CLI commando's aan.

Hydra schreef op zondag 29 januari 2017 @ 10:06:
dan is een "git commit -am "<branch> Wat ik gedaan heb"" voor mij practischer dan een grafische client gebruiken.

Het mooie van een GUI is dat je precies kan zien welke bestanden je commit, eventueel minder/meer kan selecteren, en/of even kan klikken op een bestandje om te zien wat er dan in dat bestand gewijzigd is. Die laatste 2 zijn een stuk meer werk op de command line.

[base_]

pedorus schreef op zaterdag 4 februari 2017 @ 14:54:
Klinkt niet effectief als iedereen dat voor zichzelf moet gaan doen. En het is ook handig als meerderen dezelfde GUI-app gebruiken. En als het een keertje echt ingewikkeld wordt lever ik wel een lijstje CLI commando's aan.

Lijkt me geen overbodige luxe om een beetje te begrijpen hoe git werkt als je ermee samen moet werken, zo moeilijk is die cli niet.

Het mooie van een GUI is dat je precies kan zien welke bestanden je commit, eventueel minder/meer kan selecteren, en/of even kan klikken op een bestandje om te zien wat er dan in dat bestand gewijzigd is. Die laatste 2 zijn een stuk meer werk op de command line.

Het is toch helemaal niet gebruikelijk om bepaalde bestanden niet te commiten? (m.u.v. de gitignores uiteraard) Als je een aantal aanpassingen apart wilt houden dan parkeer je die toch in een andere branch.

[CH4OS]

Ik gebruik ook veel liever Git via CLI (zowel zakelijk als prive). Reden hiervoor is heel simpel; je bent je veel bewuster in wat je doet en wat er fout gaat.

[ Voor 9% gewijzigd door CH4OS op 04-02-2017 17:18 ]

[P_Tingen]

Bij Git kun je met goed fatsoen niet om de cli heen. Dat is wel jammer, want Git vind ik in essentie ruk.

Dat mag shocking zijn voor sommigen hier, maar de cli is een ramp qua consistentie. Als je niet al te gekke dingen doet met je project, kun je lachend volstaan met een grafische client. Pas als daar iets fout gaat, moet je het via de cli herstellen.

[kaesve]

Hier nog een fervent gebruiker van tig en git op de command line. Ik gebruik ook wel IntelliJ's ingebouwde git-client, maar alles voor alles wat ik niet in IntelliJ schrijf (en dat is het meeste) gebruik ik graag git en tig. Zeker

tig status

vind ik een heel relaxte manier om code te stagen en de huidige status te zien.

Ik doe dit trouwens in Bash on Windows, wat ik erg prettig vind werken

[Hydra]

pedorus schreef op zaterdag 4 februari 2017 @ 14:54:
Klinkt niet effectief als iedereen dat voor zichzelf moet gaan doen. En het is ook handig als meerderen dezelfde GUI-app gebruiken.

Waarom? Ik gebruik geen UI en ga dat nooit doen. Ik ga net zo goed mensen niet opdringen IntelliJ te gebruiken. Als je Eclipse beter vindt; prima. Jouw feestje. Maar ik ga je dan ook niet helpen met je Eclipse of Git-ui instellingen; dat mag je dan zelf doen. Niet dat ik weiger te helpen ofzo, maar ik heb net zo min ervaring met zo'n Git UI dus primair ligt het dan bij die persoon.

Het mooie van een GUI is dat je precies kan zien welke bestanden je commit

git status

eventueel minder/meer kan selecteren,

git add <filter>

en/of even kan klikken op een bestandje om te zien wat er dan in dat bestand gewijzigd is.

git diff HEAD^ HEAD <filter>

[Mavamaarten]

Zo goed als alles gebeurt bij mij via Tower. Het is naar mijn mening gewoon zoveel gemakkelijker om even visueel te gaan kijken wat er met branches is gebeurd, pull requests te maken met een right click, enkele lijnen te stagen en sommige niet, ... Ja het kan met de CLI, maar veel zaken zijn gewoon veel simpeler met een GUI.

Mergen doe ik met CLion/IntelliJ/Android Studio.

Ik heb zo ongeveer elk tooltje wel geprobeerd, maar uiteindelijk vind ik SourceTree en Tower de meest gebruiksvriendelijke. Gitkraken zag er heel fancy uit maar is veel te ingewikkeld. Fork is wel mooi maar een beetje te simpel imo.

[ Voor 23% gewijzigd door Mavamaarten op 04-02-2017 19:55 ]

[technorabilia]

Het is mijns inziens beter om eerst eens op de command line te beginnen voordat je GUI tools gaat gebruiken. Ook is het raadzaam om de documentatie en het boek op https://git-scm.com door te nemen. Hoeft niet per se allemaal maar wel goed als je echt wilt weten hoe git werkt. Als je git snapt inclusief branching etc. zou ik pas naar GUI tools grijpen. Zo zorg je dat je altijd en overal met git uit de voeten kunt.

[Hydra]

kraades schreef op zaterdag 4 februari 2017 @ 20:13:
Het is mijns inziens beter om eerst eens op de command line te beginnen voordat je GUI tools gaat gebruiken.

Niet in de laatste plaats omdat je via SSH op een linux bak weinig keus hebt

[P1nGu1n]

Ik gebruik zelf de combi van command line en GUI (SourceTree).

Voor alles als commit/pull/push/checkout/merge/stash etc gebruik ik de command line. Als ik wat meer overzicht wil, bijvoorbeeld branches gevisualiseerd zijn of een specifieke commit bekijken, doe ik dat in SourceTree. SourceTree is dus eigenlijk read-only.

Zoals TS zegt, je moet hier een account voor aanmaken, maar hier kan je gewoon 10minutemail voor gebruiken (hier hoef je nooit meer iets mee te doen verder). 'tig' klinkt interessant, klinkt als een mogelijke vervanger voor SourceTree, die ga ik binnenkort eens proberen.

[ Voor 3% gewijzigd door P1nGu1n op 04-02-2017 20:29 ]

[technorabilia]

Hydra schreef op zaterdag 4 februari 2017 @ 20:28:
[...]


Niet in de laatste plaats omdat je via SSH op een linux bak weinig keus hebt

Tuurlijk is het dan handig om de CLI te kennen maar serieus development doe je niet op de prompt. Dat heb je een IDE voor nodig.

[Hydra]

kraades schreef op zaterdag 4 februari 2017 @ 20:49:
Tuurlijk is het dan handig om de CLI te kennen maar serieus development doe je niet op de prompt. Dat heb je een IDE voor nodig.

Ik had het ook niet over development werk maar over deployments e.d.

[pottink]

Gewoon commandline meestal of via PHPStorm zelf werkt voor mij het lekkerst.

[Verwijderd]

CLi git is hetzelfde als met nano code aanpassen, ik gebruik smart-git en moet zeggen die wordt steeds beter, heeft ook een goede conflict solver en je kan heel makkelijk discard gebruiken

[PainkillA]

een beetje dev gebruikt een fatsoenlijke ide waar ook eigenlijk altijd goede git suport in zit. Integreerd veel beter in de workflow dan 3rd party progs erbij

[ShitHappens]

Daar doe je echter gelijk de aanname dat iedereen dit Git gebruikt, ook een devver is. Nu zal dit misschien een uitzondering zijn, maar bij ons is 40% van de Git gebruikers géén devver. Op hun machines ga je dus ook geen IDE aantreffen. Vervolgens gebruikt de ene weer CLI omdat dat nooit iets anders is dan pull/edit/commit/push, en de ander Sourcetree omdat het soms wat ingewikkelder wordt dan dat. Waarom Sourcetree? Geen andere reden dan dat het al bij Bitbucket zit

[Ryur]

ShitHappens schreef op vrijdag 10 februari 2017 @ 12:19:
Daar doe je echter gelijk de aanname dat iedereen dit Git gebruikt, ook een devver is. Nu zal dit misschien een uitzondering zijn, maar bij ons is 40% van de Git gebruikers géén devver. Op hun machines ga je dus ook geen IDE aantreffen.

Ik kan mij eigenlijk geen situatie voorstellen dat iemand die geen ontwikkelaar is Git gebruikt.
Ben benieuwd welke gebruikers bij jullie dus Git gebruiken dan

(Note: waarschijnlijk kan ik ze mij niet voorstellen hoor, bedoel dit niet als kritiek!)

[ Voor 8% gewijzigd door Ryur op 10-02-2017 13:50 ]

[technorabilia]

Testers, Product Owners, ...
Deployment, Ops, ...
...

[ Voor 36% gewijzigd door technorabilia op 10-02-2017 14:06 ]

[incaz]

Ik zou trouwens ook niet weten waarom dit iets is dat devvers zo goed moeten kunnen. Het heeft voor mij niet echt veel te maken met de vaardigheden die ik in de rest van het devwerk nodig heb.

[MarcoC]

Mijn gebruik van Git is zo basaal (push, add, commit, pull) dat een GUI alleen maar onnodige overhead is.

[Rushleader]

Wat trouwens ook een mooie optie kan zijn (IMO) is een combinatie van GitLab + command line.
Je standaard commando's (denk aan develop terug mergen in een feature branch) kunnen makkelijk via CLI, maar de belangrijkere merges (develop/release --> master) gaan dan via GitLab en optioneel via 4-eyes principe.

Heb je gelijk je Diff tool, Network graph logging en git blame/history views.

[technorabilia]

Git branching!?

Edit:
Reactie was @basaal gebruik. Je mist dan m.i. veel van de krachtige opties van git w.o. het branching model.

[ Voor 79% gewijzigd door technorabilia op 10-02-2017 14:15 ]

[Rushleader]

kraades schreef op vrijdag 10 februari 2017 @ 14:13:
Git branching!?

Ja ? Via het git-flow idee. Werkt best lekker als je het doorhebt.

Edit: Git Flow

[ Voor 18% gewijzigd door Rushleader op 10-02-2017 14:17 ]

[ShitHappens]

Ryur schreef op vrijdag 10 februari 2017 @ 13:49:
[...]

Ik kan mij eigenlijk geen situatie voorstellen dat iemand die geen ontwikkelaar is Git gebruikt.
Ben benieuwd welke gebruikers bij jullie dus Git gebruiken dan

(Note: waarschijnlijk kan ik ze mij niet voorstellen hoor, bedoel dit niet als kritiek!)

Dit gaat om:
- SQL queries van team datamigratie
- Config files voor de servers (beheerd door devops)
- Config files voor de mapping tussen accounts en servers (testteam beheert dan testserver, datamigratie de datastaging servers etc)
- Config files voor administrator accounts
- Prijslijsten die in de applicatie oproepbaar zijn (beheerd door datamigratie)

[technorabilia]

Rushleader schreef op vrijdag 10 februari 2017 @ 14:15:
[...]


Ja ? Via het git-flow idee. Werkt best lekker als je het doorhebt.

Reactie was op eerdere reacties op basaal gebruik en dat je het als developer niet onder de knie hoeft te hebben. M.i. is goed gebruik van git (of versiebeheer) essentieel voor efficiënt development.

[incaz]

Ik weet wel waarom je het nodig hebt, ik weet alleen niet waarom het logisch is dat je er vrij automatisch goed in zou moeten zijn, en vaak zonder het ergens echt geleerd te krijgen.
Versiebeheer is hartstikke nuttig - waarom is de tool ervoor dan iets waar je uren en uren in moet steken om het te kunnen, met vrij veel mogelijkheden om dingen permanent stuk te maken?

[Down]

Het lijkt me voornamelijk belangrijk dat je je workflow gewoon naar behoren kunt uitvoeren, of dat nou met de command line of een grafische tool is. Ik gebruik zelf voornamelijk TortoiseGit. Wellicht kan de command line je helpen om concepten sneller onder knie te krijgen, maar dat verschilt ook per persoon. Git kan voor nieuwe gebruikers best intimiderend zijn en goede grafische tools kunnen de drempel verlagen.

Wat ik zelf erg prettig vind is dat TortoiseGit erg snel is (t.o.v b.v. SourceTree) en vanuit de explorer (Windows) werken vind ik ook erg prettig. Ik kan alles wat onze workflow vereist snel en prettig uitvoeren; merge, (interactive) rebase, reset, checkout, cherry pick etc. Veel collega's geven de voorkeur aan SourceTree. Whatever works

PainkillA schreef op vrijdag 10 februari 2017 @ 12:09:
een beetje dev gebruikt een fatsoenlijke ide waar ook eigenlijk altijd goede git suport in zit. Integreerd veel beter in de workflow dan 3rd party progs erbij

Oneens. Zo heb ik source control integratie in de meeste IDE'S altijd een drama gevonden. Buggy en instabiel vooral. Visual Studio (zelfs de meest recente versie) wordt niet altijd even blij van een checkout van een andere branch, zeker niet als je ook database projects in je solution heb. Gewoon gebruiken wat het beste voor jou werkt.

[Hydra]

incaz schreef op vrijdag 10 februari 2017 @ 14:25:
Ik weet wel waarom je het nodig hebt, ik weet alleen niet waarom het logisch is dat je er vrij automatisch goed in zou moeten zijn

Definieer 'goed'? Version control is een belangrijke skill voor iedere serieuze developer. Als je denkt dat je weg kan komen met gewoon kopieen van files maken dan leef je echt in 1999. Daarnaast heb je de basics in een uur onder de knie; je gaat me niet vertellen dat je problemen van gebruikers om kan zetten in werkende software maar dat git opeens te complex voor je is.

Ryur schreef op vrijdag 10 februari 2017 @ 13:49:
Ik kan mij eigenlijk geen situatie voorstellen dat iemand die geen ontwikkelaar is Git gebruikt.

In een vorig project gebruikten de testers Eclipse om JBehave scripts bij te werken en gebruikten ze ook git om die te committen. Maar dat was een erg basale flow met alleen add, commit en push. Dat kan echt iedereen leren.

[ Voor 26% gewijzigd door Hydra op 11-02-2017 09:35 ]

[incaz]

Hydra schreef op zaterdag 11 februari 2017 @ 09:33:
Definieer 'goed'? Version control is een belangrijke skill voor iedere serieuze developer. Als je denkt dat je weg kan komen met gewoon kopieen van files maken dan leef je echt in 1999. Daarnaast heb je de basics in een uur onder de knie; je gaat me niet vertellen dat je problemen van gebruikers om kan zetten in werkende software maar dat git opeens te complex voor je is.

Nou, blijkbaar ga ik dat wel vertellen Misschien denk ik wat dat betreft teveel als een gebruiker, in hoe dingen makkelijk en overzichtelijk gemaakt kunnen en moeten worden, en ben ik daarmee mijn feeling voor onvriendelijke en obscure commands verloren? Geen idee.

Definieer goed... goed is in elk geval meer dan committen. Committen is inderdaad niet zo moeilijk. Maar 'goed' betekent ook het kunnen herstellen van fouten (daar heb je het toch voor) en het betekent bv dat je soms halverwege je werk ineens bedenkt dat je het beter een andere branch kunt noemen, maar veel van dat soort gegoochel leidt bij mij al snel tot detached heads, resets die mogelijk dataloss geven, en andere ongein.

Nou zou ik dat wellicht misschien kunnen leren, door er eerst uren in te stoppen (met 1 uur krijg ik dat in elk geval niet duidelijk, omdat mijn manier van denken fundamenteel anders is dan linux man-pages, dus ik hoop nog steeds op iets dat wel aansluit bij mijn manier van denken, en bij de scenario's die ik tegenkom. Ik heb bv 'version control by example' en dat kan ik goed volgen. Klinkt logisch, klinkt redelijk... en het zijn niet de problemen die ik op wil lossen) en daarna steeds blijven herhalen en actief dat te blijven onderhouden... alleen illustreert dat vooral dat het z'n status als tool die mijn leven makkelijker moet maken niet echt verdient, want iets wat zo'n tijdsinvestering vraagt om te begrijpen, is niet echt meer een tool die het leven makkelijker maakt.

(Overigens, is de toon die je zet met uitspraken als "als je denkt dat je weg kan komen met" en "je gaat me niet vertellen dat" nou echt nodig?)

[Hydra]

incaz schreef op zaterdag 11 februari 2017 @ 10:41:
(Overigens, is de toon die je zet met uitspraken als "als je denkt dat je weg kan komen met" en "je gaat me niet vertellen dat" nou echt nodig?)

Tja. Het spijt me maar die houding staat me een beetje tegen. Het is ff een paar uurtjes experimenteren maar dan heb je wel een stuk kennis opgedaan waar je de rest van je leven wat aan hebt. Maak gewoon een aparte repo en ga een zaterdag experimenteren ofzo. Maak opzettelijk wat fouten en fix die met behulp van google.

Daarbij is het gewoon dagelijks gebruik, add, commit, push, pull, branch en merge echt binnen een uur tot een paar uur wel onder de knie te krijgen. Je kunt dan misschien wel fouten in je flow maken; het is vrijwel onmogelijk om dingen echt stuk te maken. Je kunt vrijwel altijd een checkout doen naar een vorige commit indien mogelijk. En dan ben je die commit daarna ook nog steeds niet kwijt; die bestaat nog gewoon.

Ik vind de "ik denk anders" houding gewoon storend. Het heeft niks met hoe je denkt te maken; iedereen moet die learning curve door. Het is gewoon een kwestie van doorzetten.

En gelukkig ben ik maar gewoon een persoon met een mening. Je mag het gerust met me oneens zijn

[incaz]

Hydra schreef op zaterdag 11 februari 2017 @ 11:16:
Tja. Het spijt me maar die houding staat me een beetje tegen. Het is ff een paar uurtjes experimenteren maar dan heb je wel een stuk kennis opgedaan waar je de rest van je leven wat aan hebt.

Nou, blijkbaar dus niet.

Daarbij is het gewoon dagelijks gebruik, add, commit, push, pull, branch en merge echt binnen een uur tot een paar uur wel onder de knie te krijgen. Je kunt dan misschien wel fouten in je flow maken; het is vrijwel onmogelijk om dingen echt stuk te maken.

Ja, da's dus een beetje het punt: ik heb git niet voor het dagelijks gebruik, dat gaat inderdaad prima, als alles volgens plan verloopt. Maar git is een veiligheidsnet, dus vooral nuttig en nodig als het mis gaat. En dan worden de zaken exponentieel snel complex. Misschien dat de git-theorie goed past bij hoe jouw hersenen werken, de mijne vinden ze knap ingewikkeld. Zolang ik binnen de lijntjes blijf is er niets aan de hand, maar juist voor de complexe zaken biedt het geen veiligheid.

Leuk dat jij kunt oordelen dat het niet zo is, maar daar heb ik niet zoveel aan

Ik vind de "ik denk anders" houding gewoon storend. Het heeft niks met hoe je denkt te maken; iedereen moet die learning curve door. Het is gewoon een kwestie van doorzetten.

En dat staat mij dan weer tegen, want dat is precies waarom we zo'n ongelofelijke hoeveelheid aan gebruiksonvriendelijke software hebben: het idee dat het logischer is om een enorme commitment te vragen van je gebruikers (en ze voor dom, pebcak, whatever uit te maken als ze iets niet snappen) dan om die dingen voor te zijn.

Uiteindelijk is het pure inefficientie dat de miljoenen developers over de wereld allemaal uren per persoon moeten investeren in het leren van een veiligheidsnet dat wel belangrijk en nuttig is, maar tegelijkertijd geen deel uitmaakt van de core. (En extra probleem daarbij is dat het dus een grote drempel geeft voor veel mensen die best op bepaalde deelgebieden enige expertise hebben maar geen fullstack developer zijn of willen zijn, en dus ook niet uren tijd willen verspillen aan zo'n systeem.)

Zinloos, verspillend, jammer.

[technorabilia]

kraades schreef op zaterdag 4 februari 2017 @ 20:13:
Ook is het raadzaam om de documentatie en het boek op https://git-scm.com door te nemen.

Echt heel verhelderd.

[Hydra]

incaz schreef op zaterdag 11 februari 2017 @ 11:26:
Ja, da's dus een beetje het punt: ik heb git niet voor het dagelijks gebruik, dat gaat inderdaad prima, als alles volgens plan verloopt. Maar git is een veiligheidsnet, dus vooral nuttig en nodig als het mis gaat. En dan worden de zaken exponentieel snel complex. Misschien dat de git-theorie goed past bij hoe jouw hersenen werken, de mijne vinden ze knap ingewikkeld. Zolang ik binnen de lijntjes blijf is er niets aan de hand, maar juist voor de complexe zaken biedt het geen veiligheid.

Welke complexe zaken heb je het over? Wat je meldde over een detached head is gewoon user error. Dan kun je gewoon terug naar je HEAD (git checkout HEAD). Je hebt iets verkeerd gedaan maar dat kan eigenlijk altijd gefixt worden.

Daarnaast is version control niet alleen "voor als iets misgaat". Het is gewoon een onderdeel van je workflow; je werkt in een aparte branch zodat je teamgenoten geen last hebben van je werk. Je kunt doen wat je wil op je eigen branch, die je ook kunt pushen zodat 'ie veilig gesteld is, en deze pas naar een gedeelde branch mergen als je klaar bent.

Daarbij levert het je ook nog eens een history op; je kunt altijd terugkijken wie een bepaalde change gedaan heeft. Gebeurt me regelmatig dat ik die persoon vragen stel over het waarom van z'n oplossing.

En dat staat mij dan weer tegen, want dat is precies waarom we zo'n ongelofelijke hoeveelheid aan gebruiksonvriendelijke software hebben: het idee dat het logischer is om een enorme commitment te vragen van je gebruikers (en ze voor dom, pebcak, whatever uit te maken als ze iets niet snappen) dan om die dingen voor te zijn.

Sorry maar er is echt niks gebruikersonvriendelijk aan git. Git add, commit, push, pull, merge en branch zijn eigenlijk de enige die je in een workflow echt nodig hebt. Daar is toch niks complex aan? Je moet alleen ff weten wat die commando's doen. Of gebruik je alleen maar for-loops omdat while en do-while "gebruiksonvriendlijk" zijn? Die heb je toch ook leren gebruiken? Je weet wat het verschil is tussen een interface en een abstract class toch? Allemaal gewoon een onderdeel van je werk kunnen doen.

Uiteindelijk is het pure inefficientie dat de miljoenen developers over de wereld allemaal uren per persoon moeten investeren in het leren van een veiligheidsnet dat wel belangrijk en nuttig is, maar tegelijkertijd geen deel uitmaakt van de core.

Versiebeheer is net zo goed een core skill als het schrijven van tests bijvoorbeeld. Dat jij het daar niet mee eens bent is je goed recht; maar je gaat je hiermee in interviews in je voet schieten als je niet uitkijkt.

(En extra probleem daarbij is dat het dus een grote drempel geeft voor veel mensen die best op bepaalde deelgebieden enige expertise hebben maar geen fullstack developer zijn of willen zijn, en dus ook niet uren tijd willen verspillen aan zo'n systeem.)

We zitten hier in PRG en ik ga er dan even vanuit dat ik te maken heb met iemand die code produceert. Dat een PO git niet snapt begrijp ik best. Maar die snapt de code in een git repo net zo goed niet.

Kijk ik snap best dat ik jouw mening waarschijnlijk niet ga veranderen (en da's je goed recht) maar ik hoop vooral te voorkomen dat beginners denken dat het acceptabel is nooit met git te werken.

[RagingPenguin]

incaz schreef op zaterdag 11 februari 2017 @ 11:26:
Ja, da's dus een beetje het punt: ik heb git niet voor het dagelijks gebruik, dat gaat inderdaad prima, als alles volgens plan verloopt. Maar git is een veiligheidsnet, dus vooral nuttig en nodig als het mis gaat. En dan worden de zaken exponentieel snel complex. Misschien dat de git-theorie goed past bij hoe jouw hersenen werken, de mijne vinden ze knap ingewikkeld. Zolang ik binnen de lijntjes blijf is er niets aan de hand, maar juist voor de complexe zaken biedt het geen veiligheid.

Git is versiebeheer, geen veiligheidsnet. Versiebeheer is vooral nuttig om met mensen samen te werken en je project te managen. Dat je dingen kan terugdraaien is een leuke (en soms nuttige) feature, maar niet waar Git primair om draait.

En hoewel je van mij geen Git hoeft te gebruiken is versiebeheer iets waar je als dev gewoon niet om heen komt. Het is heel leuk dat jij in je hoekje code kan kloppen, maar daar heeft de rest van de wereld niets aan als je het niet fatsoenlijk deelt.

[incaz]

Hydra schreef op zaterdag 11 februari 2017 @ 13:33:
[...]


Welke complexe zaken heb je het over? Wat je meldde over een detached head is gewoon user error.

Hier stuiten we denk ik op een belangrijk verschil in filosofie. Als dev, juist als dev, vind ik vrijwel iedere user error die veelvuldig voorkomt een fout in het design van de software. Het is leuk dat het gefixt kan worden, maar het blijft neerkomen op dat ik een heleboel van mijn tijd, energie, en aandacht moet besteden aan het bedenken wat git van mij wil, in plaats van dat het al werkt op een manier die aansluit bij mijn manier van doen.

Nou wil ik best erkennen dat het niet eenvoudig is om iets te maken dat goed aansluit bij de gebruikers... maar er zijn wel mogelijkheden.

Daarnaast is version control niet alleen "voor als iets misgaat". Het is gewoon een onderdeel van je workflow; je werkt in een aparte branch zodat je teamgenoten geen last hebben van je werk. Je kunt doen wat je wil op je eigen branch, die je ook kunt pushen zodat 'ie veilig gesteld is, en deze pas naar een gedeelde branch mergen als je klaar bent.

Sla de aanmatigendheid maar over, ik weet best waar version control voor is. Maar ook history, blame en dat soort dingen zijn vooral nuttig in contexten waar dingen mis gaan. (Bovendien heb je voor dergelijke basis dingen niet zoveel complexiteit nodig.
Zeker, het helpt ook wel om af en toe de code van anderen door te kijken als preventief middel, en soms is de geschiedenis ook best interessant op zich, maar dat is toch echt een stuk minder in tijd en een stuk minder in belangrijkheid.

Sorry maar er is echt niks gebruikersonvriendelijk aan git. Git add, commit, push, pull, merge en branch zijn eigenlijk de enige die je in een workflow echt nodig hebt. Daar is toch niks complex aan?

Nogmaals: blijkbaar dus niet. Ik denk niet dat je hier zonder checkout kunt.

Je moet alleen ff weten wat die commando's doen. Of gebruik je alleen maar for-loops omdat while en do-while "gebruiksonvriendlijk" zijn? Die heb je toch ook leren gebruiken? Je weet wat het verschil is tussen een interface en een abstract class toch? Allemaal gewoon een onderdeel van je werk kunnen doen.

Nee, dat is het dus niet. Want interfaces en abstract classes zijn dingen die mijn doel zijn (nou ja, niet echt, omdat mijn focus op wat andere terreinen zijn) maar ze zijn deel zeg maar van de 'productie', van het eindresultaat. Git is een tool, geen doel op zich. Dat is een fundamenteel verschil.

(Maar ook wat code betreft heb ik de neiging om te gaan voor saai en degelijk, en niet voor de meest esoterische flexibele mogelijkheden van een taal.)

Versiebeheer is net zo goed een core skill als het schrijven van tests bijvoorbeeld. Dat jij het daar niet mee eens bent is je goed recht; maar je gaat je hiermee in interviews in je voet schieten als je niet uitkijkt.

Het is aanmatigend en het blijft aanmatigend.

Kijk ik snap best dat ik jouw mening waarschijnlijk niet ga veranderen (en da's je goed recht) maar ik hoop vooral te voorkomen dat beginners denken dat het acceptabel is nooit met git te werken.

Mooie stropop . Maar eh, beginners die meelezen: version control is nuttig en belangrijk, maar laat je niet aanpraten dat het altijd aan jou ligt als software complex is en veel tijd kost en een gigantische learning curve heeft. Soms is dat gewoon een resultaat van slecht design (of van design met hele andere prioriteiten dan die jij hebt.)
Dat maakt je niet minderwaardig, geen mindere ontwikkelaar, niet gek - helaas is de sfeer in de IT nogal eens erg gericht op het op een voetstuk plaatsen van kunstmatige en onnodige barrieres als een soort test van geschiktheid.

En daarom kijgen we veel software die weinig snapt van gebruikers, want daar kijkt men nogal op neer.

Hydra, ik ben bang dat ik je mening niet kan veranderen, maar ik hoop hiermee te voorkomen dat toekomstige IT'ers die rare houding internaliseren.

[technorabilia]

incaz schreef op zondag 12 februari 2017 @ 14:04:
Het is aanmatigend en het blijft aanmatigend.

Waarom? Een dev die in teamverband niet met versiebeheer kan of wil werken heeft een manco en niet de voorkeur. Dat is toch de realiteit? Dan kies ik liever iemand die er wel fatsoenlijk mee kan werken.

[Kwistnix]

kraades schreef op zondag 12 februari 2017 @ 14:23:
[...]

Waarom? Een dev die in teamverband niet met versiebeheer kan of wil werken heeft een manco en niet de voorkeur. Dat is toch de realiteit? Dan kies ik liever iemand die er wel fatsoenlijk mee kan werken.

Ja, dat is de realiteit. Voor een ontwikkelaar is ervaring met een VCS (niet eens persé Git) wat mij betreft meer dan een pré, zeker als je in teamverband wil werken. Het is een kerncompetentie en ook zeker niet de enige. Je kan er niet mee wegkomen om met oogkleppen op alles wat niet binnen de scope van een bepaalde taal of een IDE valt af te serveren, omdat het complex is (wat best waar kan zijn) en tijd kost om onder de knie te krijgen. Softwareontwikkeling is inherent een complexe aangelegenheid en die complexiteit kan je simpelweg niet altijd vangen in een GUI of DSL en als ontwikkelaar zal je dat moeten accepteren. Ik vind het persoonlijk juist een van de leuke aspecten van het vak.
Beheersing van andere talen naast de taal waarin je ontwikkelt is ook zoiets. Meer dan relevant als je het mij vraagt. SQL is daar misschien wel een aardig voorbeeld. Leuk dat je een ORM oplossing kan inzetten om die complexiteit af te schermen - hoewel zo goed als altijd een lekker abstractie is - toch hoor je wat mij betreft als ontwikkelaar met SQL uit de voeten te kunnen.

[Verwijderd]

incaz schreef op zaterdag 11 februari 2017 @ 11:26:
Maar git is een veiligheidsnet, dus vooral nuttig en nodig als het mis gaat.

Git is geen veiligheidsnet, punt. Git is bedoeld om samen aan een project te werken. En Git is ook handig om (met behulp van andere tools) te deployen.

En dan worden de zaken exponentieel snel complex.

Gebruik je git? git was gemaakt, omdat ze snel een interface voor Git moesten hebben en zodat ze nieuwe features van Git snel uit kunnen testen, waardoor het zaken direct aan de gebruiker presenteerd op de manier dat het intern wordt afgehandeld. De bedoeling was dat andere mensen een betere interface voor Git maken en tot die tijd tijdelijk git gebruiken. git is dus nooit bedoeld geweest om echt gebruikt te worden door gebruikers.

[ Voor 9% gewijzigd door Verwijderd op 12-02-2017 15:33 ]

[Hydra]

incaz schreef op zondag 12 februari 2017 @ 14:04:
Hydra, ik ben bang dat ik je mening niet kan veranderen, maar ik hoop hiermee te voorkomen dat toekomstige IT'ers die rare houding internaliseren.

Tja. Blijf jezelf gerust aanpraten dat het "te complex" is. Het is uiteindelijk jouw carriere. In bedrijven met een hoog maturity level is version control zoals git gewoon verplichte kost. In een team samenwerken aan dezelfde software zonder fatsoenlijke version control is onbegonnen werk. En distributed version control is gewoon de defacto standaard tegenwoordig, en daarin is git veruit de grootste. Bedrijven met die maturity zijn ook de bedrijven die over 't algemeen 't beste betalen.

Je koppigheid om Git "te complex" te vinden schaadt uiteindelijk maar een persoon; jezelf. Nu kun je met een dergelijke kinderachtige sneer eindigen maar het is uiteindelijk gewoon heel erg niet mijn probleem.

[technorabilia]

Verwijderd schreef op zondag 12 februari 2017 @ 15:31:
git is dus nooit bedoeld geweest om echt gebruikt te worden door gebruikers.

?

Ik denk dat het er eerder iets mee te maken heeft dat Linus Torvalds er iets mee te maken heeft. Briljant maar...

[incaz]

kraades schreef op zondag 12 februari 2017 @ 14:23:
[...]


Waarom?

Waarom dat aanmatigend is? Omdat Hydra zich ongevraagd gaat bemoeien met carriere-advies.

Maar ik maak me geen zorgen hoor. Ik zou namelijk gewoon benadrukken dat ik goed met de client mee kan denken, het ook leuk vind om uit te vinden wat gebruikers nodig hebben en hoe dingen makkelijker gemaakt kunnen worden zodat software niet iets is wat ergens tussenin staat maar juist zoveel mogelijk faciliterend. Ook dat is een kwaliteit die gewaardeerd kan worden op de juiste plek :j

Verwijderd schreef op zondag 12 februari 2017 @ 15:31:
[...]
Git is geen veiligheidsnet, punt. Git is bedoeld om samen aan een project te werken. En Git is ook handig om (met behulp van andere tools) te deployen.

Wellicht verklaart dat veel van de frustratie: het is dus blijkbaar geen tool voor devs maar meer voor program managers en sysadmins. Da's prima. Ik ben er altijd vrij eerlijk over dat daar mijn talenten niet liggen.

Dan maar eens op zoek naar iets anders dat dan wel als fijn veiligheidsnet kan dienen - want dat is iets waar ik als ontwikkelaar met regelmaat behoefte aan heb.

(Dat maakt de tijd die ik aan git besteed wel nog inefficienter moet ik zeggen - uiteindelijk is het toch een vorm van overhead - en zoals veel overhead kan het nuttig zijn, maar er komt altijd een breekpunt. Hoe minder nuttig de output van git is, zoals geen veiligheidsnet zijn voor coders, maar vooral een workflow-tool, des te meer dat punt opschuift naar inefficient.)

De bedoeling was dat andere mensen een betere interface voor Git maken en tot die tijd tijdelijk git gebruiken. git is dus nooit bedoeld geweest om echt gebruikt te worden door gebruikers.

Zou leuk zijn als ze dat er ooit nog van komt (maar gezien de minachting voor toegankelijke software ga ik er niet vanuit.) De andere gitclients zijn voor een groot deel 1-op-1-implementatie van de commands, niet een andere vorm met meer gebruiksvriendelijke logica, helaas.

Ik had er wel een gezien (dat was een commandline tool meen ik me te herinneren) dat een paar veelgebruikte scenario's had geimplementeerd. Alleen zou ik echt werkelijk niet meer weten hoe het heet.

[Verwijderd]

kraades schreef op zondag 12 februari 2017 @ 16:30:
[...]


?

Ik denk dat het er eerder iets mee te maken heeft dat Linus Torvalds er iets mee te maken heeft. Briljant maar...

[video]

Ik zei alleen maar wat mij ooit is verteld, maar met Linus Torvalds is het logisch inderdaad…

[ Voor 6% gewijzigd door Verwijderd op 12-02-2017 21:27 ]

[Hydra]

incaz schreef op zondag 12 februari 2017 @ 17:11:
Wellicht verklaart dat veel van de frustratie: het is dus blijkbaar geen tool voor devs maar meer voor program managers en sysadmins. Da's prima. Ik ben er altijd vrij eerlijk over dat daar mijn talenten niet liggen.

[gekkie]

incaz schreef op zondag 12 februari 2017 @ 17:11:
[...]
Wellicht verklaart dat veel van de frustratie: het is dus blijkbaar geen tool voor devs maar meer voor program managers en sysadmins. Da's prima. Ik ben er altijd vrij eerlijk over dat daar mijn talenten niet liggen.

Dan maar eens op zoek naar iets anders dat dan wel als fijn veiligheidsnet kan dienen - want dat is iets waar ik als ontwikkelaar met regelmaat behoefte aan heb.

(Dat maakt de tijd die ik aan git besteed wel nog inefficienter moet ik zeggen - uiteindelijk is het toch een vorm van overhead - en zoals veel overhead kan het nuttig zijn, maar er komt altijd een breekpunt. Hoe minder nuttig de output van git is, zoals geen veiligheidsnet zijn voor coders, maar vooral een workflow-tool, des te meer dat punt opschuift naar inefficient.)

Errrr. misschien mis ik iets, maar wat zoek jij dan precies in een "veiligheidsnet" ?

Op je lokale tree ben je heer en meester dus er is geen enkele veiligheid ten opzichte van je eigen falen.
Als je Torvalds heet of een ander geweldig project hebt dan heb je wellicht "backups-a-la-torvalds" doordat andere je repo gecloned hebben. Als je dat als nog wilt vernaggelen met je eigen falen dan kan ook dat maar moet je eerst meer mensen er van overtuigen en is er dus toch een zekere rem.

Verder houdt git prima de schiedenis bij, stelt je in staat in de history heen en weer te gaan etc.
Ja je kunt je tree prima vernaggelen met de wat geavanceerdere zaken, dan kan het op zich geen kwaad om dat eerst op een kopietje van je tree te doen en goed te verifieren, zodat het eenvoudig te herstellen is.

[Bigs]

Je kunt je met Git aardig in je voet schieten, maar dankzij de eenvoudige opzet kun je je werk altijd weer herstellen met commando's als git reflog.

Het is voor elke dev de moeite waard om het Git Internals hoofdstuk door te lezen. Het is moeilijk om geen waardering te hebben voor de elegante eenvoud die ten grondslag ligt aan Git. Bovendien snap je dan ook beter _waarom_ bepaalde dingen mis gaan.

On-topic: HIer Sourcetree (macOS). Gebruik het alleen om een complexe deelcommit te doen ('stage selected lines') en om wat overzicht te krijgen. Daarvoor voldoet het prima. Verder gebruik ik voornamelijk de command line, fugitive.vim en de standaard difftool die git mergetool op macOS gebruikt.

[ Voor 26% gewijzigd door Bigs op 12-02-2017 20:57 ]

[incaz]

gekkie schreef op zondag 12 februari 2017 @ 19:46:
[...]

Errrr. misschien mis ik iets, maar wat zoek jij dan precies in een "veiligheidsnet" ?

Voornamelijk dat ik makkelijk iets terug kan zetten als ik bedenk dat iets niet is zoals ik wil, maar ik ook niet meteen al mijn code weg wil gooien. Volgens mij treden conflicten en problemen bv op (maar ik heb nu niet een kant-en-klare lijst met problemen paraat) als je git commit v3 doet, dan git commit v4, en dan git checkout v3 en dat dan weer wilt committen.

(Ah, nee, kijk: http://stackoverflow.com/...tory-to-a-previous-commit
Dan ben ik er in elk geval achter waar de verwarring vandaan komt: in mijn hoofd is het inhoudelijk vrijwel hetzelfde om uncommitted en committed changes te veranderen. Gewoon: je gaat voorwaarts in de tijd, je construeert je nieuwe werkelijkheid en dat is het nieuwe normaal. Dus commit en be done with it. Maar bij committed changes moet je reverten maar kun je niet checkout gebruiken, en bij uncommitted changes kun je niet reverten en moet je checkout gebruiken, en als je een combinatie van beide hebt, dan.... eerst checkout en dan revert misschien?)

Misschien dat het vanuit het model van git bezien logisch is, maar ik vind zelf dus dat je model altijd zo dicht mogelijk bij de werkelijkheid moet blijven, en niet andersom.

De merge-problemen uit https://reprog.wordpress....ith-added-actual-reasons/ ben ik trouwens ook al eens tegengekomen.

En tegelijkertijd kom ik deze problemen dus niet vaak genoeg tegen om precies te onthouden hoe dat allemaal werkt (of om een actueel lijstje te kunnen geven op het moment dat de discussie optreedt.)

Dat is ten eerste een kwestie van herhaling: om complexe dingen actueel te houden, heb je oefening nodig. Als ik maanden geen mysql doe, heb ik echt weer even nodig om het tot in detail te snappen. Idem voor javascript - een deel ervan zit er nog wel, maar ligt niet meer aan de oppervlakte als ik het een tijd niet gebruik.

Ten tweede is er het punt van context switching: als ik in mijn hoofd de code actueel heb, dan verdwijnt het git mental model even naar de achtergrond. Dat is waarom het als ik er dedicated tijd aan besteed en bijvoorbeeld een testrepo doe veel minder problemen heb: dan staat git front en center. Maar bij het programmeren heb ik die mentale ruimte dus al voor iets anders actief.

Het punt is: ik heb geen zin om (bv wekelijks) oefensessies te gaan houden om mijn git-complexe-situaties-skill up-to-date te houden. Want javascript en mysql zijn onderdeel van wat ik daadwerkelijk doe, het programmeren zelf, maar git is een tool die vooral faciliterend moet zijn. Als ik moet kiezen waar ik mijn studietijd aan wil besteden, dan is het iedere keer weer het vakinhoudelijke deel.

Ik heb me er voor de gein overigens in verdiept, en ik ben blijkbaar zeker niet de enige die het zo vindt. En ik denk dat het deels gewoon jammer is dat er te vaak wordt herhaald dat git fantastisch is als je het eenmaal weet - en dat dat voor veel mensen (/situaties) gewoon niet zo is wordt te snel op de persoon gespeeld.

Als ik me daar jaren terug bewust van was geweest had ik beslist meer druk gezet op het kiezen van een ander vcs, omdat het gewoon niet echt de mogelijkheid heeft om het op een simpele manier te gebruiken.
Je komt al heel snel in de buurt van de complexe dingen: een detached head bv is simpel gecreerd, en uitvogelen hoe je dat herstelt zonder code loss is niet echt zo simpel als add-commit-push. (En ik dacht dus echt iets heel onschuldigs te doen.)

Maar daarmee is het eigenlijk niet de beste oplossing ons scenario, en het is jammer dat dat niet eerder duidelijk was. (En je weet pas dat het blijkbaar niet lukt om dingen na een steile learning curve te leren als het niet gelukt is en het dus al heel veel uren heeft gekost. Het is vrijwel onmogelijk om dat soort dingen vooraf realistisch in te schatten omdat je niet weet wat je nog niet weet.)

Hydra schreef op zondag 12 februari 2017 @ 19:35:
[...]

Wat een constructieve inhoudelijke reactie. De IT is zo'n fijne, respectvolle sector.

[gekkie]

incaz schreef op zondag 12 februari 2017 @ 20:21:
[...]
Voornamelijk dat ik makkelijk iets terug kan zetten als ik bedenk dat iets niet is zoals ik wil, maar ik ook niet meteen al mijn code weg wil gooien. Volgens mij treden conflicten en problemen bv op (maar ik heb nu niet een kant-en-klare lijst met problemen paraat) als je git commit v3 doet, dan git commit v4, en dan git checkout v3 en dat dan weer wilt committen.

(Ah, nee, kijk: http://stackoverflow.com/...tory-to-a-previous-commit
Dan ben ik er in elk geval achter waar de verwarring vandaan komt: in mijn hoofd is het inhoudelijk vrijwel hetzelfde om uncommitted en committed changes te veranderen. Gewoon: je gaat voorwaarts in de tijd, je construeert je nieuwe werkelijkheid en dat is het nieuwe normaal. Dus commit en be done with it. Maar bij committed changes moet je reverten maar kun je niet checkout gebruiken, en bij uncommitted changes kun je niet reverten en moet je checkout gebruiken, en als je een combinatie van beide hebt, dan.... eerst checkout en dan revert misschien?)

Misschien dat het vanuit het model van git bezien logisch is, maar ik vind zelf dus dat je model altijd zo dicht mogelijk bij de werkelijkheid moet blijven, en niet andersom.

De merge-problemen uit https://reprog.wordpress....ith-added-actual-reasons/ ben ik trouwens ook al eens tegengekomen.

En tegelijkertijd kom ik deze problemen dus niet vaak genoeg tegen om precies te onthouden hoe dat allemaal werkt (of om een actueel lijstje te kunnen geven op het moment dat de discussie optreedt.)

Dat is ten eerste een kwestie van herhaling: om complexe dingen actueel te houden, heb je oefening nodig. Als ik maanden geen mysql doe, heb ik echt weer even nodig om het tot in detail te snappen. Idem voor javascript - een deel ervan zit er nog wel, maar ligt niet meer aan de oppervlakte als ik het een tijd niet gebruik.

Ten tweede is er het punt van context switching: als ik in mijn hoofd de code actueel heb, dan verdwijnt het git mental model even naar de achtergrond. Dat is waarom het als ik er dedicated tijd aan besteed en bijvoorbeeld een testrepo doe veel minder problemen heb: dan staat git front en center. Maar bij het programmeren heb ik die mentale ruimte dus al voor iets anders actief.

Het punt is: ik heb geen zin om (bv wekelijks) oefensessies te gaan houden om mijn git-complexe-situaties-skill up-to-date te houden. Want javascript en mysql zijn onderdeel van wat ik daadwerkelijk doe, het programmeren zelf, maar git is een tool die vooral faciliterend moet zijn. Als ik moet kiezen waar ik mijn studietijd aan wil besteden, dan is het iedere keer weer het vakinhoudelijke deel.

Ik heb me er voor de gein overigens in verdiept, en ik ben blijkbaar zeker niet de enige die het zo vindt. En ik denk dat het deels gewoon jammer is dat er te vaak wordt herhaald dat git fantastisch is als je het eenmaal weet - en dat dat voor veel mensen (/situaties) gewoon niet zo is wordt te snel op de persoon gespeeld.

Als ik me daar jaren terug bewust van was geweest had ik beslist meer druk gezet op het kiezen van een ander vcs, omdat het gewoon niet echt de mogelijkheid heeft om het op een simpele manier te gebruiken.
Je komt al heel snel in de buurt van de complexe dingen: een detached head bv is simpel gecreerd, en uitvogelen hoe je dat herstelt zonder code loss is niet echt zo simpel als add-commit-push. (En ik dacht dus echt iets heel onschuldigs te doen.)

Maar daarmee is het eigenlijk niet de beste oplossing ons scenario, en het is jammer dat dat niet eerder duidelijk was. (En je weet pas dat het blijkbaar niet lukt om dingen na een steile learning curve te leren als het niet gelukt is en het dus al heel veel uren heeft gekost. Het is vrijwel onmogelijk om dat soort dingen vooraf realistisch in te schatten omdat je niet weet wat je nog niet weet.)

Het is kennelijk vooral de opdeling en benaming van de verschillende commando's (en opties) wat je dwars zit ?
Misschien dat mecurial je dan meer ligt (opzich wel vaker ergens gelezen dat er mensen waren die dat gebruikersvriendelijker vonden).
Het blijft semi-low-level annoteren en hacken van een graph, maar als het goed is doet een revert op een
uncommitted file daar wel wat je wilt.

Wat een constructieve inhoudelijke reactie. De IT is zo'n fijne, respectvolle sector.

Achja een hele briljante opmerking was het dan misschien ook wel niet, of denk je werkelijk dat bijvb. de linux-kernel in elkaar geklooid wordt door een aantal managers en een stel sys-admins ?

Maarja ... forum is net als git, lastig om de history nu nog te rewriten

Overigens vraag ik me dan af of mysql ook niet een martelgang moet zijn. Je krijgt of de verkeerde data terug omdat je de verkeerde vraag gesteld had, of een ook niet altijd even duidelijke foutmelding, of in het geval van Mysql ook nog eens de kans op arbitraire data (er vanuitgaande dat ze bij groupby's er nog steeds potentieel een zooitje van maken). Dan ben je uiteindelijk misschien toch ondanks dat het ook niet ideaal is, beter af met een horkerige tool die iets weigert uit te voeren omdat het wellicht ambigu is wat je bedoeld.

Er zijn best zaken die gebruiksvriendelijker zouden kunnen, sommige daarvan worden al geadresseerd in third party GUI's, andere zijn misschien ook gewoon niet zo eenvoudig als het lijkt (zeker niet in het niet generieke non-lineaire history geval).

[ Voor 11% gewijzigd door gekkie op 12-02-2017 22:30 ]

[ZaZ]

Ik snap wel wat Hydra bedoelt en ben ook van mening dat een beetje investeren de moeite waard is, maar wat incaz zegt volg ik ook wel een beetje.
Ik vind het te makkelijk om te zeggen met dingen zoals een detached head van "dan doe je gewoon iets fout"
Ik heb flink wat ervaring met git en er zijn tig situaties te bedenken waar je toch zomaar op 'gevaarlijk' terrein komt.
Een detached head kan je zomaar te pakken hebben als je bijvoorbeeld met submodules werkt.
Als je dat dan niet door hebt en je gaat lekker door met commiten en je switched naar een andere branch dan zijn de commits 'weg'
Dan moet je gaan neuzen met reflog om te kijken waar ze zijn (als je op tijd bent), maar genoeg mensen die niet verder gaan dan commit en push en die niet weten hoe de ingewanden van git eruitzien en die hebben dan al opgegeven en gaan op een andere manier de fout herstellen.

Of een rebase waar je een conflict niet goed oplost en daardoor bijvoorbeeld alleen maar extra conflicten om je oren krijgt gedurende rebase actie.
Als je dan de boel abort kom je in niemandsland.
Tuurlijk; reset op de oude SHA en je kan het weer proberen.
Zeg dat eens tegen iemand met minder ervaring. Ook daar al vaker gezien dat mensen dan gaan googlen en voor je het weet zijn ze merges en cherry picks aan het doen omdat ze zo hun branch weer een beetje terug proberen te krijgen. Of gewoon het verlies nemen en de code maar opnieuw gaan schrijven.

Of een long living branch die up to date wordt gehouden door periodieke merges.
Een werknemer krijgt conflicten op een van de merges en snapt het niet meer en wil het gewoon 'weg' hebben.
Dus die discard vervolgens alles en kan nog steeds niet verder omdat dat stomme systeem toch wil dat er een commit wordt uitgevoerd. Nou, dan maar een lege commit, da's vast niet zo erg.
Daarna gewoon verder gaan met werken en commits doen op de long living branch en dan erachter komen dat die 'lege' merge toch wel behoorlijk wat schade heeft aangericht.
Heel veel succes met oplossen! Een revert van de merge gaat hier niet werken kan ik je zeggen en veel plezier met het doorvoeren van alle cherry picks waar je regelmatig conflicten kan gaan oplossen.

Als je dan van mening bent dat versiebeheer eigenlijk meer alleen maar een tijdslijn moet zijn zodat je terugkan naar gisteren en van daar weer naar morgen zonder dat je de repository 'sloopt', dan is git misschien inderdaad geen goede keuze.
Ik denk dat je dan zelfs nog beter voor subversion kan kiezen.

[Hydra]

incaz schreef op zondag 12 februari 2017 @ 20:21:
Wat een constructieve inhoudelijke reactie. De IT is zo'n fijne, respectvolle sector.

Sorry maar met een opmerking als "het is dus blijkbaar geen tool voor devs maar meer voor program managers en sysadmins." maak je jezelf behoorlijk belachelijk.

Wat jij doet is gewoon een term voor: expert beginner.

ZaZ schreef op maandag 13 februari 2017 @ 00:21:
Tuurlijk; reset op de oude SHA en je kan het weer proberen.

Maar dat is dus het hele punt. Het is extreem moeilijk om in Git iets permanent te verkloten. Rebase heb je bijvoorbeeld helemaal niet nodig. Als je een rebase gebaseerde workflow gaat gebruiken (ben er zelf geen fan van, zie liever de originele history) dan lijkt het me dat je je ook een beetje gaat verdiepen in hoe rebase werkt.

En zelf als je een fuck-up in een merge of rebase maakt; je kunt altijd terug. Commits kun je altijd in je reflog terug vinden.

Ik heb vroeger nog met Visual Source Safe gewerkt en hoewel de user interface simpel was, kon je ook echt makkelijk shit kwijtraken. Met git is dat praktisch onmogelijk. En als je dan een keer iets verkeerd doet kun je de oplossing simpel googlen. Ik krijg een beetje het idee dat sommige mensen dan maar willekeurige git commando's in gaan typen zonder te snappen wat ze aan 't doen zijn. Da's een beetje zoals na een rm -rf data heen en weer gaan moven in de hoop dat je data terugkomt.

Git is enorm uitgebreid (wat fantastisch is, ik heb een pre-commit hook gemaakt die een commit afwijst als hij niet begint met de branch-naam of de branchnaam niet volgens een bepaald patroon is) maar dat maakt het niet complex. Een basale feature-branch workflow heb je maar een paar commandos voor nodig. En het is gewoon kennis die je als dev op moet doen.

[incaz]

Hydra schreef op maandag 13 februari 2017 @ 08:06:
[...]


Sorry maar met een opmerking als "het is dus blijkbaar geen tool voor devs maar meer voor program managers en sysadmins." maak je jezelf behoorlijk belachelijk.

Vind je het echt zo moeilijk om je voor te stellen dat er diverse dev-functies zijn die nauwelijks bestaan uit integratie van branches en uit deployment, waar dat gewoon niet tot de dagelijkse of zelfs maar wekelijkse activiteiten van de betreffende dev behoort?

Maar dat is dus het hele punt. Het is extreem moeilijk om in Git iets permanent te verkloten. [...]
Met git is dat praktisch onmogelijk. En als je dan een keer iets verkeerd doet kun je de oplossing simpel googlen.

Nou, blijkbaar dus niet. Wees blij dat je de manier van denken van Linus deelt, zo te lezen zowel in zijn manier van software bedenken als in je visie op mensen/gebruikers. Tegelijkerijtd jammer dat je je wel bekwaamd hebt in technische zaken, maar zo te lezen niet echt in het verplaatsen in andere gezichtspunten en gebruikservaringen. (Als dat vaker zou gebeuren zou de softwareindustrie daar volgens mij een stuk beter van worden.)

Ik krijg een beetje het idee dat sommige mensen dan maar willekeurige git commando's in gaan typen zonder te snappen wat ze aan 't doen zijn.

Tsja, dat is je eigen fantasie - al snap ik die wel als je echt niet kunt begrijpen tegen welke problemen andere gebruikers aanlopen, dan is in het wilde weg proberen inderdaad ongeveer de enige verklaring mogelijk.

Maar in werkelijkheid blijkt (bijvoorbeeld) dat een deel van die zo makkelijk bij elkaar te googlen oplossingen gewoon ronduit fout zijn, en je van de wal in de sloot helpen. Die herken je wel als je heel veel met git bezig bent en het helemaal goed kent, maar nou net niet in de situatie waarin je (blijkbaar) bent uitgegaan van verkeerde aannamen, daardoor iets verkeerds hebt gedaan maar niet precies weet wat of waarom het verkeerd was, en dan bij een verkeerd advies uitkomt.

Jammer verder dat je niet ingaat op mijn argumenten van context switchting en retention. Dat zijn namelijk beide belangrijke bezwaren voor mij. Dat is extra nadrukkelijk een probleem als ik iets lastigs aan het bouwen ben, halverwege merk dat ik een probleem verkeerd aan het oplossen ben, en daarom opnieuw wil beginnen met de code zoals die was (maar liefst met behoudt van toegang tot code die ik al geschreven heb.)
Dat is niet alleen een situatie die voor git iets lastiger is dan een simpele commit, het is vooral ook een situatie waarin IK een complex probleem in mijn hoofd heb dat mijn aandacht vraagt, wat het overzicht op git wegdrukt. Maak ik dan een task switch naar git, dan raak ik in elk geval een deel kwijt van wat er aan dat moment in mijn hoofd zit over het probleem waar ik mee bezig was.

Als jij daar geen last van hebt: fijn, wees blij, tel je zegeningen. Maar voor mij is het een groot probleem, en het maakt het gebruik van git enorm verspillend en frustrerend.

Een basale feature-branch workflow heb je maar een paar commandos voor nodig. En het is gewoon kennis die je als dev op moet doen.

Ja, als je git alleen maar gebruikt voor workflow, en nooit verkeerde paden op dwaalt, dan is het simpel. En je hebt er weinig aan, maar moeilijk is het dan inderdaad niet. Er is hier 1 project dat eigenlijk nogal verkeerd is opgebouwd, wat iets zou moeten doen met submodules of shared repositories ofzo, wat nu nog niet gebeurt, en waar de prioriteit om het te veranderen laag is.
Daar staat toch Git zodat er in elk geval iets gelogd is, en vragen als 'goh, was dat altijd al zo' beantwoord kunnen worden. Dat werkt echt perfect simpel, want ik hoef alleen maar git add en git commit te gebruiken. Heel misschien heb ik wel eens voorzichtig iets geprobeerd met git blame, maar dan heb je het wel zo'n beetje gehad. En lo and behold: geen merge conflicts, geen detached heads, geen branches die niet willen switchen... Dan is het inderdaad simpel.

[technorabilia]

Volgens mij mis je de de big picture van software development.

Heb je het artikel "expert beginner" van hierboven gelezen?

[Bigs]

Ik vemoed dat incaz (of zijn organisatie) ook niet heel hoog scoort in de 12 steps to better code test.

Jeetje, bij ons werken zelfs niet-devs als vertalers in Git om hun vertalingen te laten mergen. Voor testers is branches wisselen ook dagelijkse kost. Gaat prima.

[TheNephilim]

Wij werken hier met SourceTree in combinatie met Bitbucket. Over het algemeen doe ik voor Git niet veel in de commandline. Heel af en toe hebben we een project wat naar een server moet zonder remote, waardoor ik dan op de server in de commandline de masterbranch pull.

Het gros van de projecten hier zijn kleine (informatieve) bedrijfswebsites. Enkele projecten zijn kleine webshops en soms komt er een grotere (meer interactieve) website voorbij. Met twee developers is het vaak zo dat we toch aan ons eigen project werken en dus niet verder komen dan ontwikkelen in 'develop' en na een merge met 'master' wordt er automatisch gedeployed (via FTP) naar de server. Voor sommige projecten is er een git-remote op de productie server aanwezig, waar we 'master' naartoe pushen en op die manier deployen.

Meestal is het met die bedrijfswebsites een kwestie van ontwikkelen -> preview -> oplevering en is het project daarmee afgerond. Voor kleine wijzigingen als in feedback van vormgever; "knopje aanpassen" of "tekstuele aanpassing" gaan we hier geen feature-branches aanmaken, maar bij grotere changesets doen we dat wel. Alleen al om te voorkomen dat je bezig met met een wijziging die nog niet mee moet van 'develop' naar 'master' en dus productie.

Persoonlijk zou ik niet zeggen dat ik Git helemaal beheers, maar ik kan me goed redden. Commit/merge/checkout/pull/push is allemaal geen probleem. Aan rebase heb ik me overigens nog nooit gewaagd. Eigenlijk wil ik nog wat contributen aan open-source repo's om ook de workflow met meerdere ontwikkelaars een beetje beter te beheersen. Met twee developers kun je nog te makkelijk overleggen; "kun je even helpen?" "ja is goed, ik pull je project wel even", waarna ik dan aanpassingen doe en aangeef aan mijn collega dat ik klaar ben, waarna hij het verder oppakt.

[Bigs]

TheNephilim schreef op maandag 13 februari 2017 @ 11:21:
Wij werken hier met SourceTree in combinatie met Bitbucket. Over het algemeen doe ik voor Git niet veel in de commandline. Heel af en toe hebben we een project wat naar een server moet zonder remote, waardoor ik dan op de server in de commandline de masterbranch pull.

[..]

Je kunt ook het repository op die server als remote op je lokale station instellen, dan kun je er gewoon naar pushen. DVCS FTW

[incaz]

kraades schreef op maandag 13 februari 2017 @ 10:46:
Volgens mij mis je de de big picture van software development.

Wat is de big picture volgens jou? (Mij lijkt het dat het ligt op het ontwikkelen van software die goed te gebruiken is, maar misschien heb ik dat mis.)

Heb je het artikel "expert beginner" van hierboven gelezen?

Ja. Ik ben geen 'expert beginner', ik ben zeker ook geen expert - ik ben slechts iemand die vind dat de prioriteiten in de IT te vaak liggen op een soort van morele tests en het aangeven waarom anderen minderwaardig zijn (als dev, als gebruiker...)

Ik zie een steile learning curve, en vind dat mogelijk slecht design. Ik vind het mijn vak om dat - in de software waar ik bij betrokken ben - beter te doen waar ik kan. Anderen zien een steile learning curve en zien dat als iets van waarde, als iets om anderen mee neer te halen, 'dat je dat niet eens kunt, dan verdien je het niet om dev te zijn! Je bent expert beginner die niet meer wil leren! Je bent dom, iedereen kan dat! Je werkomgeving is slecht!'

Ik vind het nogal tekenend - en zorgelijker dan die 12 stappen.

[Hydra]

incaz schreef op maandag 13 februari 2017 @ 11:37:
Ja. Ik ben geen 'expert beginner', ik ben zeker ook geen expert - ik ben slechts iemand die vind dat de prioriteiten in de IT te vaak liggen op een soort van morele tests en het aangeven waarom anderen minderwaardig zijn (als dev, als gebruiker...)

Hebben jullie peer reviews en zo ja, hoe doen jullie die?

incaz schreef op maandag 13 februari 2017 @ 10:10:
Nou, blijkbaar dus niet. Wees blij dat je de manier van denken van Linus deelt, zo te lezen zowel in zijn manier van software bedenken als in je visie op mensen/gebruikers. Tegelijkerijtd jammer dat je je wel bekwaamd hebt in technische zaken, maar zo te lezen niet echt in het verplaatsen in andere gezichtspunten en gebruikservaringen. (Als dat vaker zou gebeuren zou de softwareindustrie daar volgens mij een stuk beter van worden.)

Hou eens op met deze nauwelijks verdekte beledigingen. Ik werk al tijden als consultant en heb daarbij ook zowel commerciele als technische rollen gehad. Ik neem het vak software engineer serieus; dat betekent dus ook luisteren naar gebruikers en hun wensen vertalen in software die waarde toevoegt. Daarbij werk ik meestal in teams en heb dus jaren ervaring met welk nut source control heeft.

Jij bent als dev gewoon buitengewoon moeilijk serieus te nemen met je claims over git en hoe het een tool zou zijn die niet voor devs is. Heel de fucking wereld is ondertussen aan de github en jij denkt dat je er als dev mee weg komt het niet te leren? Als je de rest van je leven wordpress templates wil knutselen prima, maar dat is geen software engineering.

[ Voor 61% gewijzigd door Hydra op 13-02-2017 11:43 ]

[incaz]

Hydra schreef op maandag 13 februari 2017 @ 11:39:
[...]
Hebben jullie peer reviews en zo ja, hoe doen jullie die?

Waarom wil je dat weten?

[Hydra]

incaz schreef op maandag 13 februari 2017 @ 11:40:
Waarom wil je dat weten?

Waarom geef je niet gewoon antwoord? Ik vraag mij af hoe het bedrijf waar jij werkt intern werkt kwa processen.

[ Voor 17% gewijzigd door Hydra op 13-02-2017 11:45 ]

[incaz]

Hydra schreef op maandag 13 februari 2017 @ 11:43:
[...]
Waarom geef je niet gewoon antwoord?

Omdat het niet echt ingegeven lijkt te zijn als basis voor een fijn en gelijkwaardig gesprek. Waarom zou ik dat soort vragen beantwoorden aan iemand die het eerder nodig vond om op aanmatigende toon mij van ongevraagd carriereadvies te voorzien, iets constructiefs als plaatste, en schreef dat ik mezelf enorm belachelijk maakte?

[TheNephilim]

Wat ik overigens nog wel mis, of misschien weet ik gewoon niet hoe dat moet ...

Stel ik pas wat dingen aan heb binnen SourceTree dan netjes de 'unstashed' files. Alleen heb ik dat in de 'develop' branch gedaan en wil eigenlijk een nieuwe branch maken (git-flow -> start new feature) dan moet ik eerst deze bestanden 'stashen' (en committen dacht ik).

Nu heeft PhpStorm een 'shelf' functie, waardoor ik de wijzigingen even in PhpStorm kan opslaan, dan een nieuwe branch aan kan maken en die changes dan 'unshelf' in de nieuwe branch.

Maar kan dat ook gewoon in SourceTree?

[Hydra]

TheNephilim schreef op maandag 13 februari 2017 @ 11:57:
Maar kan dat ook gewoon in SourceTree?

Ik ken sourcetree niet maar je kunt een changeset gewoon met "git stash" opbergen, een andere branch uitcheckken (git checkout dev), updaten (git pull), daarop een nieuwe feature branch maken (git checkout -b <naam>) en dan de changes terugzetten ("git stash pop").

Ik weet niet wat het sourcetree equivalent daarvan is maar ik neem aan dat dat ook allemaal kan. Ik vind het alleen zelf gewoon efficienter 't in te typen.

[farlane]

incaz schreef op maandag 13 februari 2017 @ 11:37:
[...]
Ja. Ik ben geen 'expert beginner', ik ben zeker ook geen expert - ik ben slechts iemand die vind dat de prioriteiten in de IT te vaak liggen op een soort van morele tests en het aangeven waarom anderen minderwaardig zijn (als dev, als gebruiker...)

Anderen zien een steile learning curve en zien dat als iets van waarde, als iets om anderen mee neer te halen, 'dat je dat niet eens kunt, dan verdien je het niet om dev te zijn! Je bent expert beginner die niet meer wil leren! Je bent dom, iedereen kan dat! Je werkomgeving is slecht!'

Ik vind het nogal tekenend - en zorgelijker dan die 12 stappen.

Misschien heb ik het verkeerd, maar in veel van je posts komen dit soort dingen naar boven : je hebt slechte ervaringen (gehad) en generaliseert dit vervolgens naar 'de hele IT'. (Je doet dit bijvoorbeeld ook als reactie op Hydra)

Ik vraag me af of dat wel terecht is.

[gekkie]

TheNephilim schreef op maandag 13 februari 2017 @ 11:21:
Eigenlijk wil ik nog wat contributen aan open-source repo's om ook de workflow met meerdere ontwikkelaars een beetje beter te beheersen. Met twee developers kun je nog te makkelijk overleggen; "kun je even helpen?" "ja is goed, ik pull je project wel even", waarna ik dan aanpassingen doe en aangeef aan mijn collega dat ik klaar ben, waarna hij het verder oppakt.

Meestal niet heel veel anders dan je nu doet.
Hooguit dat sommige projecten (die niet op github staan) alles (eerst) via mailinglists doen ter review en soms ook het committen via deze patches doen ipv git pulls, zeker voor het kleinbier.
Kortom git-format-patch en git send-email worden dan handig.
En uiteraard een signed-off-by ..

En verder blijven er 2 kansen, het wordt geaccepteerd of niet en het zou kunnen dat je bij conflicten gevraagd wordt het zelf te mergen, maar soms ook niet.

[gekkie]

incaz schreef op maandag 13 februari 2017 @ 11:37:
Ik zie een steile learning curve, en vind dat mogelijk slecht design. Ik vind het mijn vak om dat - in de software waar ik bij betrokken ben - beter te doen waar ik kan. Anderen zien een steile learning curve en zien dat als iets van waarde, als iets om anderen mee neer te halen, 'dat je dat niet eens kunt, dan verdien je het niet om dev te zijn! Je bent expert beginner die niet meer wil leren! Je bent dom, iedereen kan dat! Je werkomgeving is slecht!'

Proberen te solliciteren bij een van de GUI git clients dan maar ?
Je zou dan toch verwachten dat het een gat in de markt is, als alle tools op dit moment dermate beroerd zijn dat er zoveel mensen hun weg echt niet mee kunnen vinden.

En je voorbeeld van overnieuw beginnen, lijkt me toch niet zo'n punt.
Commit al je werk in een devel branch, checkout een nieuwe branch op het punt waar je opnieuw op wilt beginnen. Afhankelijk van of je nog stukken kunt hergebruiken cherrypick je die, of je copy en paste gewoon delen en gaat gewoon weer fijn delen opnieuw commiten.

Wat is het probleem er mee, conceptueel toch gewoon hoe je een breiwerkje ook uithaald en opnieuw begint, met als bonus een manier om stukken te cherrypicken ?

*whoops* dit had nog in in de vorige post erbij gemogen .. ahwel gemiste kans.

[ Voor 3% gewijzigd door gekkie op 13-02-2017 12:31 ]

[GrooV]

Vraag me toch af hoe dit topic heeft kunnen ontsporen om het nut van versie beheer aan te tonen

Ik gebruik zelfs Git voor mijn persoonlijke hobby projecten, tuurlijk kom ik ook bij klanten waar geen Git gebruikt wordt maar er is ALTIJD een VCS. Vaak bij Microsoft georiënteerde projecten is het TFS (of in het ergste geval SVN )

Maar Git is absoluut niet alleen een veiligheidsnet, integendeel, het is een essentieel onderdeel van je workflow als developer.

Verder dient Git ook niet als een backup van je code, daar heb je backups van je Git repo voor

[incaz]

GrooV schreef op dinsdag 14 februari 2017 @ 09:09:
Vraag me toch af hoe dit topic heeft kunnen ontsporen om het nut van versie beheer aan te tonen

Misschien omdat mensen denken dat het gaat om het nut van versiebeheer aan te tonen, terwijl volgens mij niemand het daarmee oneens is.

Ik ben helemaal voor versiebeheer. Ik heb het alleen graag in een vriendelijk, behulpzaam pakket ipv iets dat enorme overhead kost aan investeringen in de learning curve en het up-to-date houden van vaardigheden.

Als daar wat aan te doen is, dan zou ik helemaal gelukkig zijn. (Dus een cursus Git gegeven door mensen die iets weten van verschillende leerstijlen van mensen en hoe je daarbij aan kunt sluiten, en die kunnen helpen met hoe je de impact van context switching en retention kunt minimaliseren? Graag!)

Wel vraag ik me dus af waarom een versiebeheer niet zou dienen als veiligheidsnet. Uit het git handbook nota bene:

[A VCS] allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.

Onderdeel van de vele redenen om VCS te gebruiken. Alleen ik ben het dus niet eens met de laatste statement: dat je dat allemaal krijgt door erg weinig overhead. Voor mij is de overhead (namelijk de tijd die ik moet besteden aan het verkrijgen en onderhouden van vaardigheden voor git) niet 'very little' maar behoorlijk.
En in de tussentijd heeft het gebruik van Git vaker tot het verlies van code geleid dan het dat heeft voorkomen. En dat is wel degelijk een probleem want dat is in elk geval niet waar ik het voor gebruik.

[gekkie]

incaz schreef op dinsdag 14 februari 2017 @ 10:35:
[...]
Onderdeel van de vele redenen om VCS te gebruiken. Alleen ik ben het dus niet eens met de laatste statement: dat je dat allemaal krijgt door erg weinig overhead. Voor mij is de overhead (namelijk de tijd die ik moet besteden aan het verkrijgen en onderhouden van vaardigheden voor git) niet 'very little' maar behoorlijk.
En in de tussentijd heeft het gebruik van Git vaker tot het verlies van code geleid dan het dat heeft voorkomen. En dat is wel degelijk een probleem want dat is in elk geval niet waar ik het voor gebruik.

Ik vraag me dan toch af wat je allemaal doet in zeg 80 a 90% van de tijd dat je git gebruikt.

Bij mij is 80 a 90% van de tijd een git commit, waarbij de tijd besteed aan git nagenoeg 0 is.
De tijd besteed aan welke files of eventueel welke hunks/lines in een bepaalde commit moeten zeg 10% en wat een duidelijke commit beschrijving is zijn zo ongeveer hier weer 90% van de tijd.

Ik zie hier niet echt een "context switch" in, behalve dat je een moment neemt om heel oppervlakkig je code nog eens zelf te reviewen.

[GrooV]

incaz schreef op dinsdag 14 februari 2017 @ 10:35:
[...]


Misschien omdat mensen denken dat het gaat om het nut van versiebeheer aan te tonen, terwijl volgens mij niemand het daarmee oneens is.

Ik ben helemaal voor versiebeheer. Ik heb het alleen graag in een vriendelijk, behulpzaam pakket ipv iets dat enorme overhead kost aan investeringen in de learning curve en het up-to-date houden van vaardigheden.

Als daar wat aan te doen is, dan zou ik helemaal gelukkig zijn. (Dus een cursus Git gegeven door mensen die iets weten van verschillende leerstijlen van mensen en hoe je daarbij aan kunt sluiten, en die kunnen helpen met hoe je de impact van context switching en retention kunt minimaliseren? Graag!)

Wel vraag ik me dus af waarom een versiebeheer niet zou dienen als veiligheidsnet. Uit het git handbook nota bene:

[...]


Onderdeel van de vele redenen om VCS te gebruiken. Alleen ik ben het dus niet eens met de laatste statement: dat je dat allemaal krijgt door erg weinig overhead. Voor mij is de overhead (namelijk de tijd die ik moet besteden aan het verkrijgen en onderhouden van vaardigheden voor git) niet 'very little' maar behoorlijk.
En in de tussentijd heeft het gebruik van Git vaker tot het verlies van code geleid dan het dat heeft voorkomen. En dat is wel degelijk een probleem want dat is in elk geval niet waar ik het voor gebruik.

Selectief lezen is ook een vak, ik zeg dat Git niet alleen een veiligheidsnet is. Het is veel meer dan dat. Als je code verlies wil voorkomen kan je ook rsync gebruiken.

Het lijkt me beter dat je de tijd die je gebruikte om te reageren in dit topic had kunnen besteden om Git te leren ipv in een Git client topic te reageren dat je Git niet snapt en vervolgens er niks mee wil doen

[Rushleader]

incaz schreef op dinsdag 14 februari 2017 @ 10:35:
[...]
... snip ...
En in de tussentijd heeft het gebruik van Git vaker tot het verlies van code geleid dan het dat heeft voorkomen. En dat is wel degelijk een probleem want dat is in elk geval niet waar ik het voor gebruik.

Mag ik vragen hoe je dat voor elkaar gekregen hebt? Want hoeveel ik ook probeer, is er altijd wel een staat van de file/change terug te vinden

Enige wat ik me kan indenken is dat je voor de lol een force-push doet over een [x behind] heen ... waardoor je indd oude changes gewoon weg kan gooien. Probleem daarmee is alleen dat een standaard git setup gewoon een warning gooit als je dat doet. (Buiten het feit dat je zelfs dan nog via je working copy terug kan maar dat is een andere discussie).

Zoals ik het nu namelijk lees probeer je een VCS te gebruiken als backup van je code... het is een mooie extra functie maar niet het hoofddoel

Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.

"Generally", nogal een sleutelwoord hier... als je het dus niet zo inricht dat het mogelijk is ben je inderdaad alsnog je files kwijt (moet je wel wat moeite voor doen ...)

Edit: Hoeft niet specifiek HEAD te zijn

[Hydra]

GrooV schreef op dinsdag 14 februari 2017 @ 10:55:
Het lijkt me beter dat je de tijd die je gebruikte om te reageren in dit topic had kunnen besteden om Git te leren ipv in een Git client topic te reageren dat je Git niet snapt en vervolgens er niks mee wil doen

[Brainstorm]

Heel eerlijk: ik herken de reactie van incaz wel. Ik denk ook dat het behoorlijk afhangt van de omgeving waarin je werkt, welke tools je gebruikt en wat de bedrijfscultuur is.

Zelf werk ik bij een bedrijf wat in enkele jaren veranderd is van volledig monolith .NET + workflow op basis van TFS, naar een omgeving die veel variatie bevat (verschillende programmeertalen, verschillende soort data storage, micro-services, cloud, etc) gecombineerd met een workflow op basis van Git. Destijds was een van de eerste stappen om van TFS over te gaan naar Git en dit leidde tot exact dezelfde discussies. Er waren binnen alle teams wel mensen die niet zomaar uit zichzelf Git aanleerden en ook gemotiveerd moesten worden om over te stappen. Naarmate meer collegas git leerden verspreidde de kennis en het git gebruik zich als een olievlek. En ja, dan gebeurde dus ook deze dingen:
* "Ik ben mijn code kwijt"
* "Ik zie mijn code niet in het centrale repository"
* "Ik deed force push en nu is xyz kapot"
* "Hoe maak ik een branch?"
* "Ik doe een checkout en alle files zijn gewijzigd" (cross-platform en LF vs CRLF)
Ja, met Git kun je dingen kapot maken en er is een bepaalde leercurve.

Tegenwoordig zie binnen het bedrijf echt helemaal niemand problemen hebben met Git. 99.5% van de tijd zijn het ook alleen simpele operaties (pull, branch, commit, push, checkout master), deels omdat de workflow er om heen complexiteit vermijd. Alle teams gebruiken pull requests om code te reviewen (ook van mensen buiten het team), merges vinden binnen BitBucket/GitHub plaats. CI/CD is geautomatiseerd (typisch Gitflow of golden master aanpak). Op onze GitHub repositories doen we squash & merge, op BitBucket staan we toe dat de commit history 'lelijk' is omdat de onvoldoende mensen snappen wat een rebase nu eigenlijk is. Laat staan het kunnen uitvoeren. We hebben meer dan 700 repos. Ik heb de CVs van de laatste 10 sollicitanten bekeken: 9 van de 10 hebben al met Git gewerkt. Geen ervaring met Git is geen breekpunt, maar we maken wel duidelijk dat dit onze standaard is.

Het leren van Git kost inderdaad een aantal uur per persoon, plus effort voor de conversie, aanpassingen in tooling, etc. Tegelijk krijg je de mogelijkheid (niet gratis, kost ook tijd) om de workflow dusdanig te stroomlijnen. Niet zozeer de flow van het daadwerkelijke committen, maar juist de flow van code reviews, het wegnemen van de constante verbinding met TFS/SVN, de uitgebreidere scripting/integratie mogelijkheden. Daarom denk ik juist dat de omgeving heel belangrijk is: als je in een relatief kleine omgeving werkt, met slechts enkele vaste repos, met een bestaande workflow, de TFS server onder je bureau, geen reden om deel te nemen in bijv. open source... ja, ik kan me dan best wel voorstellen dat het veranderen van deze zaken geen prioriteit heeft en het gebruik van Git juist een complexere manier van werken is. Ik kan me ook voorstellen dat dit naar anderen toe over kan komen als 'vastgeroest zitten'. Misschien wel, misschien niet.

Fun fact: ik heb een collega die nog steeds bij iedere story eerst in BitBucket een branch maakt, vervolgens lokaal het repo ophaalt en naar die branch wisselt. Ach ja, als het voor hem werkt...

Wat betreft het oorspronkelijke topic: command line voor alles, behalve commit/merge/diff. Die doe ik met TortoiseGit, omdat ik juist die tool (net zoals SubversionGit) een hele goede conflict resolution vind hebben. Ik weet niet precies waarom, maar waar andere tooling bij sommige zaken een merge conflict geven, kan TortoiseGit deze juist zonder problemen mergen. Heeft me tot nu toe veel tijd bespaard

[Rushleader]

Brainstorm schreef op dinsdag 14 februari 2017 @ 12:35:
... snip ...
En ja, dan gebeurde dus ook deze dingen:
* "Ik ben mijn code kwijt"
* "Ik zie mijn code niet in het centrale repository"
* "Ik deed force push en nu is xyz kapot"
* "Hoe maak ik een branch?"
* "Ik doe een checkout en alle files zijn gewijzigd" (cross-platform en LF vs CRLF)
Ja, met Git kun je dingen kapot maken en er is een bepaalde leercurve.

Klopt, er is een leer curve. Dat is met alles zo. Tevens is alleen het laatste punt een algemene irritatie vwb cross platform programming Denk dat we daar nooit vanaf komen tot iedereen dezelfde code standaard hanteert

Maar kan je dat eerste punt is uitlichten, Bij mij op kantoor hebben we dat eigenlijk nooit gehad (na transfer van SVN --> Git). De rest is wel te begrijpen, hoort bij de leercurve

Brainstorm schreef op dinsdag 14 februari 2017 @ 12:35:
Wat betreft het oorspronkelijke topic: command line voor alles, behalve commit/merge/diff. Die doe ik met TortoiseGit, omdat ik juist die tool (net zoals SubversionGit) een hele goede conflict resolution vind hebben. Ik weet niet precies waarom, maar waar andere tooling bij sommige zaken een merge conflict geven, kan TortoiseGit deze juist zonder problemen mergen. Heeft me tot nu toe veel tijd bespaard

Voor CLI kan je is kijken naar OhMyZsh, heeft een mooie lijst aan aliases voor makkelijk gebruik van Git.
En ik vind persoonlijk de diff tools eigenlijk allemaal ontoereikend, kan via CLI het sneller doorlezen dan via GUI

[ Voor 0% gewijzigd door Rushleader op 14-02-2017 13:11 . Reden: Typos =.= ]

[Hydra]

Brainstorm schreef op dinsdag 14 februari 2017 @ 12:35:
Het leren van Git kost inderdaad een aantal uur per persoon

Ik licht dit er even uit omdat dit nu precies het punt is; het kost je ff een paar uur. Dit itt tot een hoop andere zaken in ons vak. Ik ben afgelopen week bijvoorbeeld twee dagen bezig geweest om m'n blog volledig in docker te laten draaien (inclusief automatisch getriggerde Jenkins container build en deploy) puur om te leren. En dan is Git wat bij betreft wel een enorm stuk belangrijker dan Docker.

Ik snap best dat er een learning curve is, maar daar heb je je als dev gewoon maar even doorheen te werken. In plaats daarvan allerhande domme redenaties aanhalen waarom Git niet 'goed' is, is gewoon je eigen falen goedpraten wat mij betreft.

[Brainstorm]

Rushleader schreef op dinsdag 14 februari 2017 @ 13:01:
Maar kan je dat eerste punt is uitlichten, Bij mij op kantoor hebben we dat eigenlijk nooit gehad (na transfer van SVN --> Git). De rest is wel te begrijpen, hoort bij de leercurve

Code kwijt, bedoel je? Dat waren altijd fouten van de user zelf, meestal een combinatie van gebrek aan kennis en dan het verkeerde commando geven. Bijvoorbeeld een branch -D deleten. Ik kan me niet herinneren dat de code ooit ook echt verloren is gegaan, het is dan inderdaad even puzzelen om de juiste commando's te achterhalen.

De LR/CRLF fout werd trouwens gedeeltelijk veroorzaakt doordat de migratie TFS -> Git eerst gedeeltelijk via Windows nodes verliep, maar later via Linux nodes (het complete verhaal: TFS werd enkele maanden naar Git repos gesynchroniseerd om de nieuwe CI/CD stack op te bouwen. Synchronisatie ging per commit. Aan het einde van de rit TFS uitgezet en waren we over). Na de migratie hebben we met de juiste settings en gitattribute files het wel opgelost in de getroffen repos.

Rushleader schreef op dinsdag 14 februari 2017 @ 13:01:
Voor CLI kan je is kijken naar OhMyZsh, heeft een mooie lijst aan aliases voor makkelijk gebruik van Git.
En ik vind persoonlijk de diff tools eigenlijk allemaal ontoereikend, kan via CLI het sneller doorlezen dan via GUI

Thx, zal er eens naar kijken

[Sardaukar]

Ik herken de reactie van Incaz ook wel.

Op mijn werk geef ik eens in de zoveel tijd collega's een training Git om gewoon eens de voor- en nadelen te benoemen. En ja, dan geef ik ook aan dat de terminologie van Git inconsistent is, de manpage's wel door robots geschreven te lijken zijn (serieus, als mensen zoiets als dit https://git-man-page-generator.lokaltog.net/ maken zegt het wel het een en ander) en de commandline syntax met alle parameters nogal eens voor verwarring kan zorgen.

Zie bijvoorbeeld de termen 'index' en 'staging area' die door elkaar heen gebruikt worden maar precies hetzelfde betekenen.

Of de syntax om met git checkout totaal verschillende dingen te doen: het wisselen van een branch, het aanmaken van een branch, het uitchecken van een oudere commit en tenslotte een oudere versie van een bestand (of pathspec) ophalen.

Dat gezegd hebbende vind ik het achterliggende datamodel van Git (de DAG) zo sterk dat je een enorme flexibele tool in handen hebt. Ik zou persoonlijk niet terug willen naar een tool als Subversion. Dan maar wat extra tijd besteden aan de nukken van Git.

[Lethalis]

Geweldig die hele discussie over git

Ik werk in een bedrijf dat vrijwel helemaal bouwt op Microsoft .NET en wij gebruiken nog steeds *trommelgeroffel* SourceSafe

Zelf heb ik al meerdere malen uitgezocht hoe we over kunnen naar git en thuis gebruik ik git (en github) sowieso.

De redenen dat we nog niet zover zijn:
- Mensen zijn gewend aan het checkout en locken systeem. Mergen vinden ze eng.
- Mergen werkt ook voor geen meter met de huidige projecten (Visual Studio projectfiles mergen niet lekker, zeker niet bij gigantische Windows Forms applicaties met tig dependencies). Dit zou in Visual Studio 2017 beter moeten worden, als we eindelijk met wildcards kunnen werken voor bestanden.
- Mensen zijn gewend aan een centrale repository. Waar ze nu gewoon iets uitchecken, editen en weer inchecken... zullen ze bij git het eerst lokaal moeten committen en daarna - na eventueel te mergen - het moeten pushen naar een bare repository. Dit vergt meer kennis. Ook van collega's die 60+ zijn, maar nog wel belangrijk werk doen.
- Last but not least: we werken veel met project references, zodat we code snel kunnen aanpassen in verschillende lagen van onze pakketten. Onze code is daardoor niet netjes volgens een boomstructuur ingericht, wat het moeilijk maakt om duidelijke "projecten voor git" in te richten. Dit is wel op te lossen door gedeelde libraries in aparte git repositories te plaatsen, en NuGet te gaan gebruiken om deze te referencen (dus stoppen met project references voor cross solution libraries), en vervolgens de specifieke projecten voor bepaalde solutions wel netjes onder te brengen in dezelfde tree.

Dit laatste zou grote voordelen voor ons kunnen bieden (eindelijk duidelijke changesets per solution), maar is ook tering veel werk.

Onze workflow is vooral erg ad hoc overigens.

Om dan toch weer on topic te gaan, welke git clients gebruik ik het liefste?

Ik heb voldoende kennis van git om gewoon de command line te gebruiken. Daarnaast gebruik ik gewoon de geïntegreerde clients van Visual Studio en VS Code.

PS:
Zelf ben ik ook fan van de GO Git Service (gogs.io). Die gebruik ik om thuis mijn eigen github achtige server te hebben Super handig voor projecten die je niet met de wereld wil delen.

[Sardaukar]

Lethalis schreef op dinsdag 14 februari 2017 @ 14:13:
Geweldig die hele discussie over git

Ik werk in een bedrijf dat vrijwel helemaal bouwt op Microsoft .NET en wij gebruiken nog steeds *trommelgeroffel* SourceSafe

SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd

Het engste vond ik altijd dat er bij grote databases werd aangeraden om regelmatig een 'ss analyze' te draaien om problemen te detecteren/op te lossen. We deden dit tijdens een nachtelijke batch en elke ochtend zag ik in de log wel enge meldingen voorbij komen. Ik had nooit het vertrouwen dat ik altijd terug kon gaan naar elke voorgaande commit.

[Lethalis]

Sardaukar schreef op dinsdag 14 februari 2017 @ 14:18:
[...]


SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd

Het engste vond ik altijd dat er bij grote databases werd aangeraden om regelmatig een 'ss analyze' te draaien om problemen te detecteren/op te lossen. We deden dit tijdens een nachtelijke batch en elke ochtend zag ik in de log wel enge meldingen voorbij komen. Ik had nooit het vertrouwen dat ik altijd terug kon gaan naar elke voorgaande commit.

Tsja, dit is typisch een voorbeeld van iets dat zo gegroeid is en wat gewoon een enorme hoeveelheid werk zou kosten om vanaf te komen. En die energie kunnen we beter aan onze producten besteden.

Wel maken we elke nacht back-ups van SourceSafe. En ja, we maken ons ook zorgen om de betrouwbaarheid.

Ik ben wel begonnen met een eerste opzet om NuGet intern te gaan gebruiken om projecten los te koppelen van elkaar. Zodra we zover zijn, zouden we langzamerhand wat projecten kunnen verhuizen naar git.

Maar ik ben wel bang dat we dan vrij lang in zo'n situatie blijven hangen waarbij niet alle code bij elkaar staat en dat is ook vervelend.

Overigens hebben we ook nog een groot VB6 project draaien bij klanten

[Hydra]

Lethalis schreef op dinsdag 14 februari 2017 @ 14:13:
Super handig voor projecten die je niet met de wereld wil delen.

Ik gebruik gewoon Bitbucket. Hoef ik zelf de hosting niet te regelen en met webhooks/pipelines kun je ook builds op je serveer triggeren bijvoorbeeld.

Sardaukar schreef op dinsdag 14 februari 2017 @ 14:18:
SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd

Idem. We hadden ook de regel ingesteld dat je als je vergat een file te unlocken chocolade mee moest nemen

Fink aangekomen toen

Lethalis schreef op dinsdag 14 februari 2017 @ 14:24:
Tsja, dit is typisch een voorbeeld van iets dat zo gegroeid is en wat gewoon een enorme hoeveelheid werk zou kosten om vanaf te komen. En die energie kunnen we beter aan onze producten besteden.

Tja. Ik vind dat gewoon een slap excuus. Als je met de developers vindt dat je over moet, moet het gewoon gebeuren. Kun je het beter eerder dan later doen, dan heb je er sneller profijt van. Daarnaast kost het maken van een git-repo gewoon geen tijd. Het importeren van SS history is misschien lastiger maar dan kun je ook gewoon die SS repo laten bestaan in een read-only mode. Iets minder handig misschien, maar een git repo maken is een paar minuten werk,

[ Voor 36% gewijzigd door Hydra op 14-02-2017 14:52 ]

[Sardaukar]

Hydra schreef op dinsdag 14 februari 2017 @ 14:51:
[...]
Idem. We hadden ook de regel ingesteld dat je als je vergat een file te unlocken chocolade mee moest nemen

Ja, mensen die op vakantie gingen en nog ergens een lock hadden staan. Altijd leuk!

Gelukkig had ik ook het wachtwoord om die lock weer genadeloos te verwijderen.

[Hydra]

Sardaukar schreef op dinsdag 14 februari 2017 @ 14:52:
Gelukkig had ik ook het wachtwoord om die lock weer genadeloos te verwijderen.

Had iedere developer bij ons idd. Wat een dramasysteem was dat zeg.

[Sardaukar]

Hydra schreef op dinsdag 14 februari 2017 @ 14:51:
[...]
Tja. Ik vind dat gewoon een slap excuus.

Redelijk kort door de bocht. Een organisatie met een monolitische applicatie waarbij alles in 1 versiebeheer systeem zit is niet in een ochtend overgezet naar een git workflow waarbij netjes dat hele project is omgezet in losse dependencies.