Git en visual studio

[ieperlingetje]

Even de situatie schetsen.

Op het werk werken we met verschillende personen aan projecten in Visual studio 2010. Er is geen versiebeheer dus het wordt soms een ingewikkeld kluwen om de ontwikkeling te volgen. Iedere persoon werkt aan een project in verschillende visual studio instanties (de development pc's zijn virtuele machines, en er zijn minder vm's dan developers). Nu had ik graag gebruik gemaakt van git. Momenteel heb ik het als volgt ingericht: in visual studio heb ik het project geplaatst op een netwerk share en dan een repo aangemaakt in die netwerk share en leest dus elke visual studio omgeving die repo.


Nu had ik graag geweten of dat dit een ideale situatie of dat dit in de toekomst problemen kan opleveren? Naar mijn idee rammelt het van alle kanten, maar grote wijzigingen zijn nu helaas ook niet mogelijk (netwerk wordt extern gemanaged)

[Grijze Vos]

git is juist distributed. zet een zinnige git server op, trek lokaal een kopie binnen (git clone, heet het geloof ik) en als je klaar bent met je lokaal werk dan push je het naar de server.

[Hydra]

Wat is het nut van een repo als iedereen 'perongeluk' die hele repo (je enige!) weg kan gooien? Sure, het is net wat beter dan helemaal geen version control maar het levert je netto weinig op.

Je wil een centrale repo waar iedere developer een omgeving van cloned in z'n eigen omgeving. Ik neem niet aan dat je helemaal geen eigen plek hebt om code neer te zetten?

Ennuh, een andere werkgever zoeken een optie?

[ieperlingetje]

Bedankt voor de reacties. Dan ga ik er toch maar op hameren dat we een remote branch nodig hebben om naartoe te kunnen pushen .

[Hydra]

Je bedoelt een remote repository. Een branch is een aftakking van je code.

[Bigs]

Ik zou zeggen begin met lezen: http://git-scm.com/book

Jullie hebben absoluut Git nodig (of een ander modern gedistribueerd versiesysteem). De juiste manier om een centraal Git repository op te zetten op een Windows share vind je hier: http://elegantcode.com/20...hared-central-repository/. Alle ontwikkelaars maken dan een lokale clone van dit repository waarin ze hun wijzigingen committen (bij voorkeur in een feature branch). Deze wijzigingen pushen ze daarna naar het centrale repository zodat andere ontwikkelaars ze op kunnen halen.

[ Voor 47% gewijzigd door Bigs op 20-11-2013 09:19 ]

[Caelorum]

Bigs schreef op woensdag 20 november 2013 @ 09:17:
[...] (bij voorkeur in een feature branch). Deze wijzigingen pushen ze daarna naar het centrale repository zodat andere ontwikkelaars ze op kunnen halen.

Zie daarvoor https://www.atlassian.com/git/workflows#!workflow-overview. Persoonlijk vind ik dat echt een verademing, kost alleen even wennen in het begin. Wat overigens ook helpt is om Atlassian SourceTree te gebruiken daarvoor. Dan kan je gewoon op een knopje "new feature" en "finish feature" drukken. Daarnaast ook makkelijk is een knopje "initialize gitflow" dat een aantal van de branches voor je opzet enz. ^^

[ Voor 15% gewijzigd door Caelorum op 20-11-2013 11:14 ]

[Bigs]

Caelorum schreef op woensdag 20 november 2013 @ 11:12:
[...]

Zie daarvoor https://www.atlassian.com/git/workflows#!workflow-overview. Persoonlijk vind ik dat echt een verademing, kost alleen even wennen in het begin. Wat overigens ook helpt is om Atlassian SourceTree te gebruiken daarvoor. Dan kan je gewoon op een knopje "new feature" en "finish feature" drukken. Daarnaast ook makkelijk is een knopje "initialize gitflow" dat een aantal van de branches voor je opzet enz. ^^

Welke workflow gebruik je van die pagina? Wij gebruiken wat ze daar de feature branch workflow noemen, inclusief rebasen van features op master voordat ze gemerged worden. Werkt echt super. Gitflow hebben we naar gekeken, maar ik vind dat dat een beetje afdoet aan de eenvoud van git (maar van de andere kant moet je wel een ervaren Git gebruiker zijn om die eenvoud te begrijpen). Het heeft overigens wel onze eigen workflow geïnspireerd.

[Caelorum]

Oh sorry, de gitflow workflow Het is echt bijzonder wennen, maar gebruik het nu dagelijks voor mijn eigen projecten.
Het is wellicht ook wat overkill voor een eenmansproject, maar het is af en toe wel handig dat je aan meerdere features kan werken zonder dat ze elkaar in de weg zitten. Ook laat ik automatisch builds maken en het hebben van een develop (daily) en een master (release) is dan ook wel handig.

[Hydra]

Moet zelf nogal wennen aan Mercurial (gebruiken we hier). Heb gister ongemerkt een stuk CSS weggegooid, TortoiseHg Workbench meldde dat er geen conflicten waren. Moet me er nog wat beter in verdiepen maar met Git is me dit nog niet gebeurd (terwijl Mercurial simpeler zou moeten zijn).

[Bigs]

Met een merge gaat er ook wel eens iets fout hier, maar dat ligt eerder aan onduidelijke merge tools dan aan Git. Maargoed, met Subversion was die hele merge niet eens mogelijk geweest (of 1000x ingewikkelder geweest) dus wat dat betreft is de situatie zo slecht nog niet

[Sjaaky]

@TS. Zijn je collega's uberhaupt bekend met versiebeheer? Zo nee, besteed daar voldoende aandacht aan. Zorg dat ze weten hoe werkt voor je over gaat.
Ik verwacht niet dat mensen die nieuw zijn met versiebeheer en git vanaf dag 1 lekker kunnen werken met de gitflow workflow. Ik zou gewoon met de centralized workflow beginnen. Als je nog nooit met versiebeheer gewerkt hebt, krijg je er al zo veel mogelijkheden bij. Als iedereen daar aan gewend is, kun je een stapje verder.

Overigens een zeer goede video over hoe git werkt van binnen en van buiten: YouTube: \[Linux.conf.au 2013] - Git For Ages 4 And Up

[DJMaze]

Ik zou als ik jou was voor Mercurial kiezen met TortoiseHG.
Niet omdat dit beter/slechter is dan GIT (zijn ongeveer gelijk), maar de tools onder Windows OS werken gewoon beter dan die van GIT.
Scheelt je team een hoop terminal commando's leerwerk.

P.S. tenzij iemand ondertussen goede GIT GUI tools heeft gevonden die werken op Windows OS natuurlijk.

[ Voor 22% gewijzigd door DJMaze op 22-11-2013 16:40 ]

[Megamind]

Sjaaky schreef op vrijdag 22 november 2013 @ 12:51:
@TS. Zijn je collega's uberhaupt bekend met versiebeheer? Zo nee, besteed daar voldoende aandacht aan. Zorg dat ze weten hoe werkt voor je over gaat.
Ik verwacht niet dat mensen die nieuw zijn met versiebeheer en git vanaf dag 1 lekker kunnen werken met de gitflow workflow. Ik zou gewoon met de centralized workflow beginnen. Als je nog nooit met versiebeheer gewerkt hebt, krijg je er al zo veel mogelijkheden bij. Als iedereen daar aan gewend is, kun je een stapje verder.

http://www.joelonsoftware.com/articles/fog0000000043.html voor de TS

[RobIII]

DJMaze schreef op vrijdag 22 november 2013 @ 16:37:
P.S. tenzij iemand ondertussen goede GIT GUI tools heeft gevonden die werken op Windows OS natuurlijk.

VS2013 werkt prima met git AFAIK en van anderen hoor (heb er maar een klein beetje hands-on ervaring mee, onvoldoende om echt een waardeoordeel te kunnen geven)

[DXaroth]

DJMaze schreef op vrijdag 22 november 2013 @ 16:37:
Ik zou als ik jou was voor Mercurial kiezen met TortoiseHG.
Niet omdat dit beter/slechter is dan GIT (zijn ongeveer gelijk), maar de tools onder Windows OS werken gewoon beter dan die van GIT.
Scheelt je team een hoop terminal commando's leerwerk.

P.S. tenzij iemand ondertussen goede GIT GUI tools heeft gevonden die werken op Windows OS natuurlijk.

De hele tortoise serie werkt goed voor sommigen, zo is er TortoiseGIT voor Git, TortoiseSVN voor Subversion en TortoiseHG voor mercurial.

Ideeal zou zijn om iets als Gitlab op te zetten, daarmee kan je op een later stadium iets als Gitlab-ci aan vast knopen om alle pushes automatisch te checken.
Gitlab doet niet alleen code-hosting voor je team, maar geeft je ook tools als merge requests, issue tracking en andere nuttige dingen.. naast een simpele interface zodat je project manager ook nog eens kan zien wie wat uitspookt.

[Rafe]

DJMaze schreef op vrijdag 22 november 2013 @ 16:37:
P.S. tenzij iemand ondertussen goede GIT GUI tools heeft gevonden die werken op Windows OS natuurlijk.

nieuws: Microsoft voegt Git-ondersteuning toe aan Visual Studio
http://www.sourcetreeapp.com/
http://windows.github.com/ (werkt voor alle Git repo's)

Ik weet niet wat je precies maakt en wat je eisen/wensen zijn. Gezien Visual Studio zou je Team Foundation Server kunnen overwegen - maar als de rest zo hoor lijkt me dat te duur/complex voor jullie situatie. Andere vraag is ook: kunnen jullie het zelf aan om te hosten/upgraden? Zo nee, kijk naar GitHub of hosted GitLab. Zo ja, gewoon opzetten (al dan niet met een kant-en-klare VM van Bitnami bijv.)

[kutagh]

Voor de Windows gebruikers is misschien Git Extensions een goede optie... Ik gebruik dit al een hele tijd en het integreert prima met Visual Studio (d.w.z. dat Git Extensions deels in de "Pending Changes" window in Visual Studio word geintegreerd). Geen ervaring met Atlassian's SourceTree, dus ik kan er geen vergelijking mee geven.

[barber]

En anders eens kijken naar Visual Studio Online (TFS in de cloud): http://www.visualstudio.c...al-studio-online-Basic-vs

Daar kan je tegenwoordig ook Git repos in aanmaken. En t/m 5 users is het gratis volgens mij.

[ZaZ]

RobIII schreef op vrijdag 22 november 2013 @ 16:57:
[...]

VS2013 werkt prima met git AFAIK en van anderen hoor (heb er maar een klein beetje hands-on ervaring mee, onvoldoende om echt een waardeoordeel te kunnen geven)

Zolang jouw git server (als je wilt pushen) maar niet achter SSH zit, want dat doet ie gewoon helemaal niet.
Verder hoef je niet veel meer te verwachten dan de boel 'wegcommitten' en heb je uiteindelijk een andere tool erbij nodig. Zelf vind ik SourceTree een van de betere, maar bij Git ontkom je er sowieso niet aan om de commandline ook te beheersen. Regelmatig moet je dingetjes 'oplossen' die niet in een GUI te vangen zijn.

Wat betreft TS. Mijn advies is ook gewoon eerst even bekend worden met source control.
Niet teveel aantrekken van de horrorverhalen van SVN als je die in overweging neemt want mensen die dat roepen hebben er nooit echt mee gewerkt denk ik. Ik heb de laatste 6 jaar elke dag met een SVN repo te maken en als je je aan de regels houdt (zoals je dat met elke SCM moet doen!) dan is er echt niet zoveel aan de hand.

Gewoon kijken wat het beste bij de workflow van het bedrijf past, want daar zit het grootste verschil.
En als je voor een SVN kiest dan zit je niet voor eeuwig vast. Je kan altijd repo's inclusief history omzetten naar Git,Mercurial,PlasticSCM,Perforce, whatever....

[Caelorum]

ZaZ schreef op zaterdag 23 november 2013 @ 02:11:
[...] Regelmatig moet je dingetjes 'oplossen' die niet in een GUI te vangen zijn. [...]

Zolang je alleen via een fatsoenlijke GUI werkt en je je houd aan de 'regeltjes' dan hoef je ook de commandline niet in te duiken met git hoor

[...] Niet teveel aantrekken van de horrorverhalen van SVN als je die in overweging neemt want mensen die dat roepen hebben er nooit echt mee gewerkt denk ik.

Wow, just wow...

[...] Gewoon kijken wat het beste bij de workflow van het bedrijf past, want daar zit het grootste verschil. [...]

Dat lijkt me altijd het geval. Er is niet zoiets als 1 goede manier, nooit. Zelfs het verafschuwde watervalmodel is in sommige gevallen de beste keuze. Iemand die dus niet alle opties overweegt kan ik ook moeilijk serieus nemen ^^

[farlane]

ZaZ schreef op zaterdag 23 november 2013 @ 02:11:
Wat betreft TS. Mijn advies is ook gewoon eerst even bekend worden met source control.
Niet teveel aantrekken van de horrorverhalen van SVN als je die in overweging neemt want mensen die dat roepen hebben er nooit echt mee gewerkt denk ik.

SVN is sowieso beter dan geen versiebeheer, en is denk ik uitermate geschikt om aan een VCS te wennen.

[ieperlingetje]

Wow, een hoop reacties hier, bedankt voor de input. Op de pagina die hier ergens in het topic wordt aangehaald zouden we amper scoren . TFS had ik zelf al opgezocht, maar die bleek qua kostprijs niet echt haalbaar. Maar zoals ik het hier lees zijn er eerst andere problemen die we moeten oplossen. Iedere gebruiker zijn eigen development omgeving geven bijvoorbeeld zou ook al helpen met het deftig implementeren van versiebeheer Momenteel ben ik in overleg met mijn overste om dat te veranderen.

[ZaZ]

Caelorum schreef op zaterdag 23 november 2013 @ 08:30:
[...]

Zolang je alleen via een fatsoenlijke GUI werkt en je je houd aan de 'regeltjes' dan hoef je ook de commandline niet in te duiken met git hoor

SourceTree is denk ik wel een fatsoenlijke GUI, maar git werkt gewoon anders waardoor je soms toch echt naar de CLI moet. Omdat je bijv je history kan bewerken heb ik al meerdere malen zooi moeten oplossen bij mensen met reflog om maar iets te noemen omdat er dingen echt kwijt zijn. Met een hoop andere SCM kan dat gewoon niet. Eens in, altijd in.
Of iets wat veel vaker gebeurt zijn merges naar verkeerde branches waardoor er een hoop conflicten onstaan en mensen willen aborten om de boel te herstellen maar dat git dan niet verder wil wegens unresolved merge conflicts.
git reset --merge vanuit de GUI? Zo kom ik regelmatig dingen tegen.

Wow, just wow...

Sterk argument
Ik hoor altijd dezelfde dingen vanuit het git-kamp:
- Mergen levert altijd ellende op
Als je de documentatie een beetje goed leest kan je dat voorkomen. Als je bijv. in oude svn versies een long living feature branch maakt en die regelmatig update door de stable/trunk/master/whatever te mergen en je bent klaar en je wilt weer terugmergen maar je doet geen reintegrate, dan gaat ie klappen.
Dat staat gewoon in de docs.
Tegenwoordig hoef je je daar geen zorgen meer over te maken om dat dat nu automatisch gaat.
Ik werk dagelijks met git en met svn en ik heb bij beide ongeveer evenveel conflicts.
En dat zijn de conflicts die daar horen te zijn.

- DVCS is de bom en per definitie beter
Je kan geen code uitwisselen onderling zonder eerst naar de server te schoppen en dan nog 100 soortgelijke voorbeelden
Dat is iets wat je svn niet kwalijk kan nemen. Je kan niet iets als minpunt aanschrijven wat het in den beginne al niet is.
Net zoals je het een Ferrari niet kwalijk kan nemen dat ie vastloopt in de prut en een Land Rover niet kwalijk kan nemen dat ie nooit wint op Le-Mans.

Ze hebben beide hun eigen kwaliteiten en daarom geef ik een tegengeluid omdat ik hier op Tweakers steeds vaker ongefundeerd svn-bashen tegenkom.

Dat lijkt me altijd het geval. Er is niet zoiets als 1 goede manier, nooit. Zelfs het verafschuwde watervalmodel is in sommige gevallen de beste keuze. Iemand die dus niet alle opties overweegt kan ik ook moeilijk serieus nemen ^^

Oh dus daar zijn we het eens geloof ik