Git - Wordt het ook echt gebruikt?

[Anoniem: 555367]

Beste,

Ik heb eens een vraag. Ik ben namelijk al een tijd bezig met CSS ,HTML en een klein eetje SQL en PHP.
Maar wil echter een stapje verder gaan.

Namelijk het leren van Git voor onder andere github. Maar ik vraag mij iets af aan git. Word het in de benelux eigenlijk louter gebruikt op bedrijven.

Aangezien ik dingen wil leren die ik namelijk later zou willen toepassen als Front-end.

Voor de mod:
Sorry dat ik het vaag uitleg. Maar weet het niet goed te verwoorden.

[InZane]

Zo, dat is een behoorlijk onsamenhangend verhaal. Git wordt in ieder geval niet alleen maar door bedrijven gebruikt. Ik gebruik het privé ook.

Dit heeft trouwens niet echt wat met 'programming' te maken.

[ Voor 18% gewijzigd door InZane op 21-01-2014 09:06 ]

[Anoniem: 555367]

InZane schreef op dinsdag 21 januari 2014 @ 09:06:
Zo, dat is een behoorlijk onsamenhangend verhaal. Git wordt in ieder geval niet alleen maar door bedrijven gebruikt. Ik gebruik het privé ook.

Dit heeft trouwens niet echt wat met 'programming' te maken.

Mijn excuses daarvoor. Maar trek git gewoon een beetje in twijfel...

[dutchmartin]

InZane schreef op dinsdag 21 januari 2014 @ 09:06:
Dit heeft trouwens niet echt wat met 'programming' te maken.

Daar ben ik het mee eens.

Wat je kan doen is http://www.collab.net/giteyeapp proberen, dat is een prima gui git client voor als je niet van de commandline houdt, ik heb het wel eens gebruikt met openshift.

[Creepy]

Nergens voor nodig. Git is een volwassen VCS dat prima bruikbaar is, en ook gebruikt wordt door bedrijven. Git heeft zichzelf al bewezen door gebruik in de development van de Linux kernel.

Waarom trek je Git precies in twijfel?

[Anoniem: 555367]

dutchmartin schreef op dinsdag 21 januari 2014 @ 09:15:
[...]

Daar ben ik het mee eens.

Wat je kan doen is http://www.collab.net/giteyeapp proberen, dat is een prima gui git client voor als je niet van de commandline houdt, ik heb het wel eens gebruikt met openshift.

Ik ben een command line mensje....

[Anoniem: 555367]

Creepy schreef op dinsdag 21 januari 2014 @ 09:16:
Nergens voor nodig. Git is een volwassen VCS dat prima bruikbaar is, en ook gebruikt wordt door bedrijven. Git heeft zichzelf al bewezen door gebruik in de development van de Linux kernel.

Waarom trek je Git precies in twijfel?

Waarom. Ik heb gewoon het gevoel. Dat het voor vele verwarrend is. En niet echt gebruikt werd buiten doeleinden zoals Github en Bitbucket.

En ook de twijfel. Stel later ik kom als Front-end of systeembeheerder in een bedrijf. Zou ik het dan moeten toepassen. Ik dacht hiervoor van niet. Maar blijkbaar gaat het in tegen al mijn gedachtes

[Pin0]

WIj hebben op dit moment al onze code (webaplicaties) in svn staan. Voor nieuwe projecten gaan we steeds meer over op git. En heel moeilijk is het niet met enkele git commando's kan je je code pushen en pullen uit een git repository.
Ik gebruik git ook voor mijn persoonlijke website en dat bevalt prima.

[Afvalzak]

Ach elk bedrijf heeft zijn eigen systeem, SVN, TFS en Git zie ik ook regelmatig voorkomen (wel iets minder, maar dat kan gewoon aan de bedrijven waar ik kom liggen).

Maar stél je leert iets wat je later niet nodig blijkt te hebben maar je hebt daardoor wel de basis van versiecontrole in je vingers, wat maakt het dan uit welke tool ze gebruiken?

[steffex]

Git is echt wel volwassen. Heb je toevallig gezien welke bedrijven GitHub gebruiken?

https://enterprise.github.com

onderaan staan bedrijven als Blizzard, Rackspace en Etsy. Dat zijn toch geen kleintjes.
Wij gebruiken op de zaak ook Github Enterprise, zou toch echt niet meer terugwillen naar SVN.

onze frontend developers maken ook gewoon gebruik van Git en GitHub.
Als je nu nog bij bedrijven gaat werken die geen gebruik maken van VCS, moet je je misschien afvragen of je er wel wilt werken

[Anoniem: 555367]

steffex schreef op dinsdag 21 januari 2014 @ 09:23:
Git is echt wel volwassen. Heb je toevallig gezien welke bedrijven GitHub gebruiken?

https://enterprise.github.com

onderaan staan bedrijven als Blizzard, Rackspace en Etsy. Dat zijn toch geen kleintjes.
Wij gebruiken op de zaak ook Github Enterprise, zou toch echt niet meer terugwillen naar SVN.

onze frontend developers maken ook gewoon gebruik van Git en GitHub.
Als je nu nog bij bedrijven gaat werken die geen gebruik maken van VCS, moet je je misschien afvragen of je er wel wilt werken

Srry voor mijn noo vraag. Maar is er een verschil tussen de gewone git en de git enterprise?

[Creepy]

Dat kan je prima zelf even uiitzoeken op GitHub. En let op: GitHub is niet hetzelfde als Git. Git is een opzichzelf staand VCS, GitHub heeft er tooling omheen gemaakt.

[steffex]

Github is niet hetzelfde als Git! Github maakt gebruik van Git, het is namelijk een webclient voor je git server.

Verschil tussen Github en Github Enterprise is dat de laatste zelf binnen een bedrijf gehost kan worden. Je hebt dan dus een private github.com

[eagle00789]

Na een hele moeilijke integratieperiode heben wij hier in het bedrijf zowel git als svn ter beschikking, zodat iedereen de tool kan gebruiken wat hij/zij wil. Nu is het zo dat de meeste mensen juist git gebruiken omdat ze bij svn (net zoals ik) wel eens tegen rare dingen zijn opgelopen (denk hierbij bijvoorbeeld aan een commit die volgens alles goed was gegaan, waarna je de repo checked en je commit is niet te vinden). Een enkeling is een verstokte SVN gebruiker en zal dit ook blijven doen.
De setup die wij hebben is zeer complex doordat git en svn met elkaar babbelen zodat er slechts 1 centrale opslag locatie is voor de repositories en bereikbaar vanaf zowel svn als git alle commits in 1 centrale (git) repository gooien.

[Anoniem: 555367]

eagle00789 schreef op dinsdag 21 januari 2014 @ 09:26:
Na een hele moeilijke integratieperiode heben wij hier in het bedrijf zowel git als svn ter beschikking, zodat iedereen de tool kan gebruiken wat hij/zij wil. Nu is het zo dat de meeste mensen juist git gebruiken omdat ze bij svn (net zoals ik) wel eens tegen rare dingen zijn opgelopen (denk hierbij bijvoorbeeld aan een commit die volgens alles goed was gegaan, waarna je de repo checked en je commit is niet te vinden). Een enkeling is een verstokte SVN gebruiker en zal dit ook blijven doen.
De setup die wij hebben is zeer complex doordat git en svn met elkaar babbelen zodat er slechts 1 centrale opslag locatie is voor de repositories en bereikbaar vanaf zowel svn als git alle commits in 1 centrale (git) repository gooien.

Hmm vrij vintressant. Soit ik ga mij is de Github markdown en een goede Git tut opzoeken.

[steffex]

probeer deze eens, weet je meteen hoe het werkt: https://www.codeschool.com/courses/try-git

[kwaakvaak_v2]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 09:04:


Namelijk het leren van Git voor onder andere github. Maar ik vraag mij iets af aan git. Word het in de benelux eigenlijk louter gebruikt op bedrijven.

ja... en best veel ook.

[ymoona]

nee, GIT word zeker niet alleen door bedrijven gebruikt. Ook prive en voor opensource projecten word vaak git gebruikt. Als GIT client zou je http://www.sourcetreeapp.com/ kunnen gebruiken. Gebruik ik zelf onder windows en mac is de fijnste client die ik gezien heb.

[Anoniem: 555367]

ymoona schreef op dinsdag 21 januari 2014 @ 10:03:
nee, GIT word zeker niet alleen door bedrijven gebruikt. Ook prive en voor opensource projecten word vaak git gebruikt. Als GIT client zou je http://www.sourcetreeapp.com/ kunnen gebruiken. Gebruik ik zelf onder windows en mac is de fijnste client die ik gezien heb.

Jha ik zit met een ubuntu 13.10

[sdevos13]

Ja, Git wordt heel veel gebruikt. En niet alleen op GitHub en Bitbucket, maar ook daarbuiten.

Voor een systeembeheerder lijkt het me niet echt handig, maar als je iets ontwikkeld dan in het een onmisbare tool.
Kijk ook eens naar Git Flow, wanneer je Git onder de knie hebt.

Alle backenders maar ook frontenders gebruiken bij ons Git.

[bwerg]

En niet echt gebruikt werd buiten doeleinden zoals Github en Bitbucket.

Github en Bitbucket zijn geen doeleinden, ze maken alleen het gebruiken van git gemakkelijker en hebben geen enkel ander doel dan dat.

En ja, het is wel degelijk nuttig en veelgebruikt. Ik gebruik het zelf voor studie, alles waar enige vorm programmeren in samenwerking bij zit gaat op git. Dat gedoe met mailtjes met attachments naar groepsgenoten sturen moet je zo snel mogelijk achter je laten. Ook samenwerken aan documenten doe ik met git, al kan ik me voorstellen dat dit afhankelijk is van het gebruikte documenttype (of is er een goede manier om office-achtige-bestanden te delen? V.z.i.w. is dat een hel zonder automatische merges).

[ Voor 19% gewijzigd door bwerg op 21-01-2014 10:11 ]

[Anoniem: 555367]

bwerg schreef op dinsdag 21 januari 2014 @ 10:10:
[...]

Github en Bitbucket zijn geen doeleinden, ze maken alleen het gebruiken van git gemakkelijker en hebben geen enkel ander doel dan dat.

En ja, het is wel degelijk nuttig en veelgebruikt. Ik gebruik het zelf voor studie, alles waar enige vorm programmeren in samenwerking bij zit gaat op git. Dat gedoe met mailtjes met attachments naar groepsgenoten sturen moet je zo snel mogelijk achter je laten. Ook samenwerken aan documenten doe ik met git, al kan ik me voorstellen dat dit afhankelijk is van het gebruikte documenttype (of is er een goede manier om office-achtige-bestanden te delen? V.z.i.w. is dat een hel zonder automatische merges).

Hahaha awesome uit die hoek heb ik het niet bekeken. Dus jullie heben een gezamelijke repo?

[bwerg]

Meerdere, voor verschillende vakken en dus verschillende groepjes. Je bent natuurlijk wel afhankelijk van je groepsgenoten want die moeten ook een beetje git willen snappen, dat wilde in het begin nog wel eens mis gaan. Maar bij WO informatica is het wel goed dat iedereen zoiets vroeg of laat toch een keer leert. Bij andere studies kan ik me voorstellen dat sommigen het te veel gedoe vinden (voor een enkel bijvak programmeren ga je niet speciaal git leren).

[ Voor 7% gewijzigd door bwerg op 21-01-2014 10:20 ]

[Anoniem: 555367]

bwerg schreef op dinsdag 21 januari 2014 @ 10:20:
Meerdere, voor verschillende vakken en dus verschillende groepjes. Je bent natuurlijk wel afhankelijk van je groepsgenoten want die moeten ook een beetje git willen snappen, dat wilde in het begin nog wel eens mis gaan. Maar bij WO informatica is het wel goed dat iedereen zoiets vroeg of laat toch een keer leert. Bij andere studies kan ik me voorstellen dat sommigen het te veel gedoe vinden (voor een enkel bijvak programmeren ga je niet speciaal git leren).

Jha ik volg systeembbeher/netwerkbeheer. en als bijscholing web technologie

[Hydra]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 09:08:
Mijn excuses daarvoor. Maar trek git gewoon een beetje in twijfel...

Je doet je naam eer aan

Distributed VCS's zijn de 'toekomst'. Git en Mercurial worden bij erg veel bedrijven gebruikt.

bwerg schreef op dinsdag 21 januari 2014 @ 10:20:
Meerdere, voor verschillende vakken en dus verschillende groepjes. Je bent natuurlijk wel afhankelijk van je groepsgenoten want die moeten ook een beetje git willen snappen, dat wilde in het begin nog wel eens mis gaan. Maar bij WO informatica is het wel goed dat iedereen zoiets vroeg of laat toch een keer leert. Bij andere studies kan ik me voorstellen dat sommigen het te veel gedoe vinden (voor een enkel bijvak programmeren ga je niet speciaal git leren).

De basis van git is compleet triviaal. En branchen / mergen kan ook iedereen met GIT omdat het in GIT/mercurial gewoon goed werkt. SVN is moeilijker; merge conflicten zijn daar over het algemeen lastiger te resolven dan in Git/Hg.

bwerg schreef op dinsdag 21 januari 2014 @ 10:10:
En ja, het is wel degelijk nuttig en veelgebruikt. Ik gebruik het zelf voor studie, alles waar enige vorm programmeren in samenwerking bij zit gaat op git.

Ik zet vrijwel alles dat niet een triviale test is in git. Ook voor dingen waar je niet aan samenwerkt is het gewoon erg handig. Al is het alleen al om terug te zien welke wijzigingen je wanneer gemaakt hebt.

[ Voor 73% gewijzigd door Hydra op 21-01-2014 10:35 ]

[Voutloos]

Zelfs als je niet met iemand samenwerkt moet je een CVS gebruiken, alle historie functies werken net zo goed als je zelf kijkt. En wie komt er later nog iemand bij etc. etc.

steffex schreef op dinsdag 21 januari 2014 @ 09:23:
Als je nu nog bij bedrijven gaat werken die geen gebruik maken van VCS, moet je je misschien afvragen of je er wel wilt werken

Afvragen? Ik zou de deur al uit zijn voordat ze klaar zijn met 'nee, maar...' zeggen. Geldige excuses zijn er niet, dus die zou ik alleen in een sadistische bui aanhoren.

Enige uitzondering: Als het van tevoren duidelijk zou zijn dat het (oa) jouw taak is om een jong bedrijfje met groeistuipen professioneler te maken.

[Hydra]

steffex schreef op dinsdag 21 januari 2014 @ 09:23:
Als je nu nog bij bedrijven gaat werken die geen gebruik maken van VCS, moet je je misschien afvragen of je er wel wilt werken

Ik heb hetzelfde bij bedrijven die niet gemigreerd zijn / bezig zijn te migreren naar een distributed VCS, en dan zijn de opties v.z.i.w. Git of Mercurial. Voor persoonlijk gebruik, gebruik ik Git. Op werk gebruiken we Hg. We zijn nu met een migratie naar Git Flow bezig wat betreft workflow.

[Pizzalucht]

eagle00789 schreef op dinsdag 21 januari 2014 @ 09:26:
Na een hele moeilijke integratieperiode heben wij hier in het bedrijf zowel git als svn ter beschikking, zodat iedereen de tool kan gebruiken wat hij/zij wil. Nu is het zo dat de meeste mensen juist git gebruiken omdat ze bij svn (net zoals ik) wel eens tegen rare dingen zijn opgelopen (denk hierbij bijvoorbeeld aan een commit die volgens alles goed was gegaan, waarna je de repo checked en je commit is niet te vinden). Een enkeling is een verstokte SVN gebruiker en zal dit ook blijven doen.
De setup die wij hebben is zeer complex doordat git en svn met elkaar babbelen zodat er slechts 1 centrale opslag locatie is voor de repositories en bereikbaar vanaf zowel svn als git alle commits in 1 centrale (git) repository gooien.

Wij zijn ongeveer een jaar geleden van SVN over gegaan op GIT.
Het heeft wel een paar dagen gekost voordat iedereen de basis door had, maar daarna was het voor iedereen fijner werken. Als je mensen de keuze geeft bij een bepaald systeem te blijven hangen lijkt het me dat je alleen maar minder kennisoverdracht krijgt.

Sinds kort zijn we over op onze eigen (aangepaste) Gitlab install (na Rhodecode, wat best wel bagger was vergeleken met Gitlab ), hierdoor hebben we integratie met al onze andere interne middelen en hebben we ook pull requests, wat voor interne projecten enorm handig is.

Inmiddels 350+ repo's.

[Anoniem: 555367]

Dus als ik het goed begrijp moet je alleen de basis kennen?

[elhopo]

Ik gebruik in het ene project Git, en in het andere svn. Voor Git gebruik ik als client Sourcetree, wat redelijk goed werkt. Als verstokte svn gebruiker vallen mij wel wat zaken tegen bij Git. Als ik iets aanpas zonder dat ik eerst alles lokaal vernieuwd heb, maakt 'ie meteen al een nieuwe branch aan in Git. Best wel onhandig. Daarnaast als ik iets wil committen dan staat het standaard eerst in een staging situatie waarna je het moet doorzetten naar de centrale repo. Allemaal dingen die net wat onhandig zijn voor mij.

Wellicht is het een kwestie van wennen, misschien wat standaard settings. Wie zal het zeggen. Uiteindelijk werken ze beide, en doen waar ze voor gemaakt zijn: het leven van een ontwikkelaar wat makkelijker maken. Zo zie ik het ook, het is een tool voor versiebeheer en niet anders.

Dus: Ja, het wordt veel gebruikt.

[eekhoorn12]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 11:27:
Dus als ik het goed begrijp moet je alleen de basis kennen?

Wat je denk goed uit elkaar moet houden in dit topic is git zelf, wat dus echt het programma zelf is, en alle tooling eromheen. Dat zijn de dingen die hier veel genoemd worden. Denk hierbij aan:

• Github
• Gitlab
• Sourcetree
• Git flow

Dit zijn allemaal dingen om het werken met git makkelijker, prettiger en een stuk krachtiger nog te maken of om samenwerking te bevorderen. Wil je weten hoe git werkt, kan het sterk aanraden wij gebruiken het hier ook, raad ik je aan om hier te beginnen met hoe het precies werkt http://git-scm.com/book. Daarna kan ik je zeker aanraden om je in de andere tools te gaan verdiepen die hier genoemd zijn en hoe deze je workflow nog verder kunnen verbeteren.

Zelf gebruiken we hier ondertussen Git, Gitlab en git-flow, en een paar van mijn collega's gebruiken Sourcetree.

[ Voor 5% gewijzigd door eekhoorn12 op 21-01-2014 11:37 ]

[Anoniem: 555367]

Zolang het maar command line blijft of iemabd suggesties heeft voor een krachtige GUI voor linux

[0x2665]

sdevos13 schreef op dinsdag 21 januari 2014 @ 10:07:
Kijk ook eens naar Git Flow, wanneer je Git onder de knie hebt.

Dit. Intressant artikel die hierop aansluit.

http://nvie.com/posts/a-successful-git-branching-model/

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 11:37:
Zolang het maar command line blijft of iemabd suggesties heeft voor een krachtige GUI voor linux

Officiele git website heeft een lijstje met GUI clients

http://git-scm.com/downloads/guis

[ Voor 33% gewijzigd door 0x2665 op 21-01-2014 11:40 ]

[eekhoorn12]

Ik werk op linux en voor het grootste deel gebruik ik de command line, alleen mijn commits doe ik gewoon met de simpele git-gui zodat ik het goed kan splitsen af en toe in meerdere commits.

[Pizzalucht]

elhopo schreef op dinsdag 21 januari 2014 @ 11:28:
Ik gebruik in het ene project Git, en in het andere svn. Voor Git gebruik ik als client Sourcetree, wat redelijk goed werkt. Als verstokte svn gebruiker vallen mij wel wat zaken tegen bij Git. Als ik iets aanpas zonder dat ik eerst alles lokaal vernieuwd heb, maakt 'ie meteen al een nieuwe branch aan in Git. Best wel onhandig. Daarnaast als ik iets wil committen dan staat het standaard eerst in een staging situatie waarna je het moet doorzetten naar de centrale repo. Allemaal dingen die net wat onhandig zijn voor mij.

Wellicht is het een kwestie van wennen, misschien wat standaard settings. Wie zal het zeggen. Uiteindelijk werken ze beide, en doen waar ze voor gemaakt zijn: het leven van een ontwikkelaar wat makkelijker maken. Zo zie ik het ook, het is een tool voor versiebeheer en niet anders.

Dus: Ja, het wordt veel gebruikt.

Je eerste punt lijkt me iets van Sourcetree, en je tweede punt is gewoon de definitie van een DCVS.

[BoomSmurf]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 09:04:
Aangezien ik dingen wil leren die ik namelijk later zou willen toepassen als Front-end.

Source control moet je toch leren. Aangezien Git een van de meest uitgebreide (en meest gebruikte) source control paketten is, leer je sowieso de principes achter source control. Mocht het bedrijf waar je gaat werken uiteindelijk een ander pakket gebruiken, dan snap je in ieder geval de basis. Lijkt me sterk dat je ooit spijt gaat krijgen van Git geleerd te hebben.

[ Voor 48% gewijzigd door BoomSmurf op 21-01-2014 11:42 ]

[Anoniem: 555367]

BoomSmurf schreef op dinsdag 21 januari 2014 @ 11:40:
[...]


Source control moet je toch leren. Aangezien Git een van de meest uitgebreide (en meest gebruikte) source control paketten is, leer je sowieso de principes achter source control. Mocht het bedrijf waar je gaat werken uiteindelijk een ander pakket gebruiken, dan snap je in ieder geval de basis. Lijkt me sterk dat je ooit spijt gaat krijgen van Git geleerd te hebben.

het is maar ik hou er persoonlijk niey van om dingen aan te leren die ik niet ga gebruiken

[Anoniem: 14124]

Ik vraag me overigens echt af of je particulier Git in de vingers gaat krijgen. Het hele idee is juist dat je een workflow hebt met offline repositories en een actual state kunt delen. Ik vermoed dat je alleen in teamverband/praktijk echt de vingers erachter gaat krijgen omdat je in je eentje niet de situaties tegenkomt waar Git juist in faciliteert.

Overigens kun je eenzelfde ook prima bereiken door een goede werkwijze met SVN (trunk, branch, tags) en duidelijke afspraken in je development team. We hebben meerdere flinke codebases ondergebracht in SVN en draaien ook parallel lopende projecten die vervolgens samenkomen.

Overigens kijken we wel naar een overgang naar Git, maar dit is puur omdat ik alle tooling aan het onderbrengen ben bij Atlassian. Atlassian heeft sinds kort een Git oplossing beschikbaar waardoor we naadloos kunnen integreren met onze Jira en Confluence implementaties en dat is dan wel erg netjes.

[DXaroth]

@ziekhoof: Versiebeheer is iets wat je tegen gaat komen zodra je buiten de 'hobby programmeur' schoenen stapt.. elk zelfrespecterend open source project gebruikt het (in welke vorm dan ook), en verwacht ook dat als je bij een bedrijf wilt programmeren, dat je dan aan versiebeheer gaat doen (zo niet, dan ben je waarschijnlijk de enige programmeur).
Het is niet moeilijk om te leren; het is 80% workflow snappen, en 20% het VCS systeem dat gebruikt wordt.. en zodra je er een paar kent, zullen andere systemen zo opgepakt kunnen worden (het concept is nl grootendeels hetzelfde bij de verschillende VCS systemen).

@Github Enterprise vermelding: Mocht het trouwens 'te duur' zijn.. kijk dan naar Gitlab.. dat is een open-source versie die je zelf kan gebruiken... en die komt zelf ook met een CI tool om al je testjes te runnen.

[Hydra]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 11:43:
het is maar ik hou er persoonlijk niey van om dingen aan te leren die ik niet ga gebruiken

Als je ooit professioneel aan de slag gaat, ga je versiebeheer gebruiken, en hoogstwaarschijnlijk een distributed VCS als Git of Hg. Nog nooit met een VCS gewerkt hebben is een enorme red flag bij elk sollicitatiegesprek, beide kanten op.

elhopo schreef op dinsdag 21 januari 2014 @ 11:28:
Ik gebruik in het ene project Git, en in het andere svn. Voor Git gebruik ik als client Sourcetree, wat redelijk goed werkt. Als verstokte svn gebruiker vallen mij wel wat zaken tegen bij Git. Als ik iets aanpas zonder dat ik eerst alles lokaal vernieuwd heb, maakt 'ie meteen al een nieuwe branch aan in Git.

Doe je een update of een pull?

Best wel onhandig. Daarnaast als ik iets wil committen dan staat het standaard eerst in een staging situatie waarna je het moet doorzetten naar de centrale repo. Allemaal dingen die net wat onhandig zijn voor mij.

Dat is het idee achter een DVCS; je kunt naar hartelust in je eigen repo rondfrutten zonder dat anderen daar last van hebben. Daarnaast wordt het aangemoedigd om in aparte branches te werken en deze later te mergen, dit i.t.t. de standaard SVN workflow waarin iedereen in de master aan het pushen is en de code steeds breekt.

Een DVCS is zowel een 'beter' VCS als een andere mindset.

[BtM909]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 09:16:
[...]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 09:18:
[...]

Let even op dat je binnen 24 uur je laatste reactie (als het de laatste reactie is) wijzigt ipv een nieuwe reply eronder te plakken

[Anoniem: 555367]

BtM909 schreef op dinsdag 21 januari 2014 @ 12:32:
[...]


[...]

[mbr]Let even op dat je binnen 24 uur je laatste reactie (als het de laatste reactie is) wijzigt ipv een nieuwe reply eronder te plakken ;)[/]

Mijn excuses

[Barryvdh]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 11:43:
[...]
het is maar ik hou er persoonlijk niey van om dingen aan te leren die ik niet ga gebruiken

Sowieso gebruikt het grootste deel van de Open Source community Git (met Github), dus het is altijd wel handig als je ooit daar iets mee wil doen. En volgens mij gaan er alleen maar mensen mensen Git gebruiken, ik hoor zelden dat mensen van Git naar <X> gaan, in tegenstelling van <X> naar Git.

[Rutix]

TFS 2013 heeft nu ook Git support dus nu gaan al onze nieuwe projecten over naar Git + TFS . De basis dingen van Git heb je ook in een dagje geleerd en de uitzonderingsgevallen leer je vaak nieteens uit je hoofd omdat dat zo weinig voorkomt dat het nutteloos is van je tijd .

[M0N0]

Anoniem: 14124 schreef op dinsdag 21 januari 2014 @ 11:47:
Ik vraag me overigens echt af of je particulier Git in de vingers gaat krijgen. Het hele idee is juist dat je een workflow hebt met offline repositories en een actual state kunt delen. Ik vermoed dat je alleen in teamverband/praktijk echt de vingers erachter gaat krijgen omdat je in je eentje niet de situaties tegenkomt waar Git juist in faciliteert.

Ook bij projectjes waar ik als enige aan werk gebruik ik Git, voor drie redenen:

1. Een versiegeschiedenis hebben van je software: als je het over 5 dagen beklaagt dat je in een refactoring honderd lijnen code aangepast hebt; kan je eenvoudigweg (de relevante delen van) de oude versie terughalen.
2. Eén developer betekent niet altijd één machine: bv. develop-machine en benchmark-machine of server. Door via Git te gaan i.p.v. gewoon te kopiëren kan je op de test-machine hotfixes uitvoeren die je nadien naar de develop-machine kan trekken zonder met de tussentijdse wijzigingen te moeten knoeien.
3. Als middel om een concreet commit/"code check-in" punt te creëren: schrijf je code, en wanneer je enkele uren later commit, lees je je wijzigingen na. De meeste GUI-programma's voor Git leveren een handig diff-tooltje mee of maken gebruik van de grafische diff-tools die je platform bieden, waardoor het effectief heel eenvoudig is om je wijzigingen te overzien, zelfs als die verspreid zijn over meerdere bestanden. Een beetje zelfdiscipline is hier wel noodzakelijk: maak er een punt van één onderwerp per commit te hebben, en schrijf een kort maar duidelijke commit-message die aangeeft wat er verandert in de commit. Zo forceer je jezelf om te valideren dat je commit 'klopt': propere code, met duidelijk doel (zodat ten minste jij al verstaat waarom die code bestaat), geen 'verloren gelopen' println-debug toestanden, etc.

[Rafe]

steffex schreef op dinsdag 21 januari 2014 @ 09:29:
probeer deze eens, weet je meteen hoe het werkt: https://www.codeschool.com/courses/try-git

En daar op aansluitend: https://www.codeschool.com/courses/git-real

0x2665 schreef op dinsdag 21 januari 2014 @ 11:38:
[...]


Dit. Intressant artikel die hierop aansluit.

http://nvie.com/posts/a-successful-git-branching-model/

Ik zie dit vaak voorbij komen als tip in topics geopend door git-beginners en vraag me dan steeds af... waarom iemand meteen aan zo'n complexe workflow helpen als hij/zij pas net git (of een ander (D)VCS) gaat gebruiken? Alsof je een vlieg wil platslaan met een bazooka, KISS

Persoonlijk vind ik een feature branch flow/GitHubs flow al meer dan voldoende, en moest ik in het begin de discpline er in houden een nieuwe branch te maken en elke set gerelateerde wijzigingen te committen, ipv een grote 'work in progress' aan het eind van de dag. Zodra je eenmaal vertrouwd bent met de command line (of je andere client) en tegen problemen op begint te lopen die GitFlow belooft op te lossen, kan je altijd nog overstappen.

[ Voor 10% gewijzigd door Rafe op 21-01-2014 14:45 ]

[Hydra]

Rafe schreef op dinsdag 21 januari 2014 @ 14:43:
Ik zie dit vaak voorbij komen als tip in topics geopend door git-beginners en vraag me dan steeds af... waarom iemand meteen aan zo'n complexe workflow helpen als hij/zij pas net git (of een ander (D)VCS) gaat gebruiken? Alsof je een vlieg wil platslaan met een bazooka, KISS

Hij zei letterlijk "kijk ook eens naar git-flow als je git onder de knie hebt". Dat is nogal wat anders dan iemand "meteen" een een complexe workflow te helpen.

[CH4OS]

Hydra schreef op dinsdag 21 januari 2014 @ 15:01:
[...]


Hij zei letterlijk "kijk ook eens naar git-flow als je git onder de knie hebt". Dat is nogal wat anders dan iemand "meteen" een een complexe workflow te helpen.

Ik denk dat jullie nu naar elk een andere post refereren als ik het topic zo lees.

[Hydra]

CptChaos schreef op dinsdag 21 januari 2014 @ 15:05:
[...]
Ik denk dat jullie nu naar elk een andere post refereren als ik het topic zo lees.

Check ff waar 0x2665 op reageert:

sdevos13 schreef op dinsdag 21 januari 2014 @ 10:07:
Ja, Git wordt heel veel gebruikt. En niet alleen op GitHub en Bitbucket, maar ook daarbuiten.

Voor een systeembeheerder lijkt het me niet echt handig, maar als je iets ontwikkeld dan in het een onmisbare tool.
Kijk ook eens naar Git Flow, wanneer je Git onder de knie hebt.

Alle backenders maar ook frontenders gebruiken bij ons Git.

[Anoniem: 555367]

Ik snap nu de basis van git maar ik snap niet goed hoe men een issue opent en sluit via terminal en hoe men milestones openzet

[Kettrick]

Hydra schreef op dinsdag 21 januari 2014 @ 15:01:
[...]


Hij zei letterlijk "kijk ook eens naar git-flow als je git onder de knie hebt". Dat is nogal wat anders dan iemand "meteen" een een complexe workflow te helpen.

Dat soort "tips" maken zaken onbedoeld alleen maar ingewikkelder voor TS. Als je git wil leren ga dan eerst lekker in een klein team op master aanklooien, wat push/pullen etc. Je krijgt dan vanzelf zaken als merges and conflicts onder de knie. Ga dan eens voorzichtig wat branches heen en weer sturen en mergen, je vind dan vanzelf uit wat werkt voor jouw team, en jouw organisatie.

Ik ben persoonlijk helemaal niet gecharmeerd van git-flow, wij werken hier met zo'n 100 man aan ongeveer 20 repo's zonder git-flow of andere afgedwongen structuur. Kleine changes gaan direct in master, grotere changes in een feature branch en middels een pull-request richting master.

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 15:20:
Ik snap nu de basis van git maar ik snap niet goed hoe men een issue opent en sluit via terminal en hoe men milestones openzet

Issues en milestones zijn github specifieke zaken en hebben weinig met git te maken, ik zou me daar nog niet druk over maken

svennd schreef op dinsdag 21 januari 2014 @ 15:24:
De vraag is of één beginnende programmeur zoveel heeft aan GIT. Ik persoonlijk gebruik al jaren SVN, en ben daar meer dan gelukkig mee. Ik kan begrijpen dat voor teams (vaak bedrijven dus) GIT wel iets handiger is, maar opzich is het toch ook een beetje smaak denk ik.

In welk opzicht is svn handiger of eenvoudiger voor een single user repo ?. Ik heb svn al een tijdje niet meer gebruikt, maar het opzetten van een svn server was altijd een redelijke klus, zeker vergeleken met het 'git init'.

[ Voor 34% gewijzigd door Kettrick op 21-01-2014 15:27 ]

[Kevinp]

Hier gebruiken we git (extentions) binnen het bedrijf. Hierbij gebruiken we een afgesproken "flow" branches. (eerste afbeelding bij git flow in google).

Voordelen voor ons als ontwikkelteam (tov svn en sourcesafe)
1. Snel switchen tussen brances
2. Goed kunnen zien wat de veranderingen zijn qua code.

Nadelen is dat je wel goed moet opletten omdat je het wel om zeep kan helpen (niet zozeer de code, maar meer het process wat je afspreekt).

[svennd]

De vraag is of één beginnende programmeur zoveel heeft aan GIT. Ik persoonlijk gebruik al jaren SVN, en ben daar meer dan gelukkig mee. Ik kan begrijpen dat voor teams (vaak bedrijven dus) GIT wel iets handiger is, maar opzich is het toch ook een beetje smaak denk ik.

[Kevinp]

svennd schreef op dinsdag 21 januari 2014 @ 15:24:
De vraag is of één beginnende programmeur zoveel heeft aan GIT. Ik persoonlijk gebruik al jaren SVN, en ben daar meer dan gelukkig mee. Ik kan begrijpen dat voor teams (vaak bedrijven dus) GIT wel iets handiger is, maar opzich is het toch ook een beetje smaak denk ik.

Voor een gebruiker voor jezelf niet zozeer. Maar het zit ook niet in de weg. Git wordt ook online steeds meer gebruikt. Dus wat dat betreft is dat wel het afwegen waard.

[NMe]

Kevinp schreef op dinsdag 21 januari 2014 @ 15:25:
[...]

Voor een gebruiker voor jezelf niet zozeer. Maar het zit ook niet in de weg. Git wordt ook online steeds meer gebruikt. Dus wat dat betreft is dat wel het afwegen waard.

Git wordt online vooral veel gebruikt voor grote projecten met veel samenwerkingen, waarschijnlijk door de fijne manier waarop je changes kan pushen naar een repository zonder dat ze meteen in de trunk terecht komen. Het is dus ideaal voor open source op een manier die SVN nooit zou kunnen bereiken. Voor iemand die in zijn eentje iets met versiebeheer doet voldoet SVN eigenlijk ook wel (tot je wil gaan branchen), maar in samenwerkingsverband is Git gewoon sterker. Met andere versiebeheersystemen heb ik geen ervaring dus daar laat ik me niet over uit.

[redjex]

Ik heb hier veel aangehad: http://www.ericsink.com/vcbe/

[Hydra]

Kettrick schreef op dinsdag 21 januari 2014 @ 15:20:
Dat soort "tips" maken zaken onbedoeld alleen maar ingewikkelder voor TS. Als je git wil leren ga dan eerst lekker in een klein team op master aanklooien, wat push/pullen etc.

Nogmaals: het was slechts een tip voor de TS nadat (!!!) hij git "onder de knie" zou hebben. Lezen is een vak kennelijk

NMe schreef op dinsdag 21 januari 2014 @ 15:31:
Met andere versiebeheersystemen heb ik geen ervaring dus daar laat ik me niet over uit.

Wij werken op kantoor met Mercurial. Da's eigen Git-met-svn-termen. De manier van werken is vrijwel identiek, alleen zijn er wat suffe verschillen in termen die hetzelfde zijn maar net iets anders werken (git pull = hg pull -u, dat soort dingen).

Vrij aardige uitleg: http://importantshock.wor...8/08/07/git-vs-mercurial/

[ Voor 39% gewijzigd door Hydra op 21-01-2014 16:04 ]

[HMS]

Git is echt heerlijk om mee te werken. Ik wil niet meer anders... nou ja, misschien dat ik nog wel kan wennen aan Mercurial omdat het er zo veel op lijkt . Van SVN heb ik soms nog steeds nachtmerries, die beginnen altijd met een branch die ik wil mergen in de trunk

[Morrar]

M0N0 schreef op dinsdag 21 januari 2014 @ 14:39:
[...]

Ook bij projectjes waar ik als enige aan werk gebruik ik Git, voor drie redenen:

1. Een versiegeschiedenis hebben van je software: als je het over 5 dagen beklaagt dat je in een refactoring honderd lijnen code aangepast hebt; kan je eenvoudigweg (de relevante delen van) de oude versie terughalen.
2. Eén developer betekent niet altijd één machine: bv. develop-machine en benchmark-machine of server. Door via Git te gaan i.p.v. gewoon te kopiëren kan je op de test-machine hotfixes uitvoeren die je nadien naar de develop-machine kan trekken zonder met de tussentijdse wijzigingen te moeten knoeien.
3. Als middel om een concreet commit/"code check-in" punt te creëren: schrijf je code, en wanneer je enkele uren later commit, lees je je wijzigingen na. De meeste GUI-programma's voor Git leveren een handig diff-tooltje mee of maken gebruik van de grafische diff-tools die je platform bieden, waardoor het effectief heel eenvoudig is om je wijzigingen te overzien, zelfs als die verspreid zijn over meerdere bestanden. Een beetje zelfdiscipline is hier wel noodzakelijk: maak er een punt van één onderwerp per commit te hebben, en schrijf een kort maar duidelijke commit-message die aangeeft wat er verandert in de commit. Zo forceer je jezelf om te valideren dat je commit 'klopt': propere code, met duidelijk doel (zodat ten minste jij al verstaat waarom die code bestaat), geen 'verloren gelopen' println-debug toestanden, etc.

Dit vind ik wel een goede post. Heb zelf ook wel met VCS gespeeld, maar als je alleen aan een project werkt is de meerwaarde kleiner. Niet helemaal afwezig zoals hierboven gezegd, maar wel minder. Daarnaast is het natuurlijk ook meer werk. VCS houden een project wel overzichtelijk ook als de code groeit.

Overigens ook goed om in het achterhoofd te houden dat VCS weliswaar tekstmatige conflicten opspoort, maar dat de code natuurlijk nog steeds compleet 'kaput' kan gaan. Als iemand bijvoorbeeld de database-klasse voor een website besluit te herschrijven heeft dat waarschijnlijk gevolgen voor vanalles en nog wat.

Maar goed, dat kun je natuurlijk alleen oplossen door goed de ontwikkeling van je software te plannen. Git kan wellicht wel ondersteunen door logische branches en deze goed te beschrijven / taggen.

[TheNephilim]

Ook hier sinds een klein poosje aan de slag. Gewoon een account op Bitbucket, we zijn maar met z'n tweeën dus dat werkt prima.

In eerste instantie is het hier vooral, commit en push. We hebben niet echt te maken met braches of iets dergelijks. Gewoon een checkout/pull/..? van de standaard basis en daarmee verder in een nieuwe repo. Dat samen met PhpStorm en dat vormt samen met Git wel een leuk geheel.

Nu nog een deploy-via-ftp manier vinden en we zijn klaar!

[steffex]

geen branches? whut?

leer het aan! Ik branch constant. Als ik een deel van de code wil herschrijven, ga ik branchen.
Mocht het niks zijn, kan ik gewoon de branch weggooien en opnieuw beginnen. Wil ik het houden, dan merge ik het in de hoofd branch.

Op die manier hou je je hoofd branch schoon en hoef je niet dingen ongedaan te maken als het blijft dat het niet werkt.

Verder gebruik ik git overal voor, zelfs al push ik het niet naar github/bitbucket/etc. Als je jezelf deze werkwijze aanleert is het maken van een lokaal scriptje zelfs onder versiebeheer.

[ Voor 20% gewijzigd door steffex op 21-01-2014 16:25 ]

[Hydra]

Morrar schreef op dinsdag 21 januari 2014 @ 16:08:
Dit vind ik wel een goede post. Heb zelf ook wel met VCS gespeeld, maar als je alleen aan een project werkt is de meerwaarde kleiner. Niet helemaal afwezig zoals hierboven gezegd, maar wel minder. Daarnaast is het natuurlijk ook meer werk. VCS houden een project wel overzichtelijk ook als de code groeit.

Ook als je alleen werkt, werk je vaak op verschillende systemen. Stel dat je om een of andere reden je meest recente changes niet over kunt halen en toch verder wil werken: dan kun je gewoon je wijzigingen in een aparte branch doen, die afgeleid is van een oudere revisie. Het later mergen van die wijzigingen gaat met Git/Mercurial echt veel makkelijker dan met SVN. Git (en Hg) weten 90% zelf wel op te lossen.

Overigens ook goed om in het achterhoofd te houden dat VCS weliswaar tekstmatige conflicten opspoort, maar dat de code natuurlijk nog steeds compleet 'kaput' kan gaan. Als iemand bijvoorbeeld de database-klasse voor een website besluit te herschrijven heeft dat waarschijnlijk gevolgen voor vanalles en nog wat.

Als je zonder VCS iets dergelijks deed, was de code (tenzij je een backup had) gewoon weg. Nu kun je precies zien wie de wijzigingen gedaan heeft. Daarbij gebruik je een aparte branch voor dit soort wijzigingen en zal ongeteste code nooit in de development branch terecht komen als het goed is, laat staan in de master.

Maar goed, dat kun je natuurlijk alleen oplossen door goed de ontwikkeling van je software te plannen. Git kan wellicht wel ondersteunen door logische branches en deze goed te beschrijven / taggen.

Je moet altijd goeie afspraken maken met je collega's. Maar zelfs als je hap-snap alles in de default branch doet is Git/Hg daar altijd nog een stuk beter in dan SVN.

Wat wij doen is dat binnen project alle developers in feature / bug branches werken. Als hij klaar is pushed hij de changes. Een andere developer doet dan een peer review van de code. Als dat ook okay is komt het bij de projectleider, die merged en test de changes, en dan kan het naar acceptatie.

steffex schreef op dinsdag 21 januari 2014 @ 16:21:
geen branches? whut?

Heb dat er hier ook een beetje uit moeten slaan. Met 3 man in 1 branch werken

[ Voor 4% gewijzigd door Hydra op 21-01-2014 16:27 ]

[blackphantom25]

TheNephilim schreef op dinsdag 21 januari 2014 @ 16:13:
Ook hier sinds een klein poosje aan de slag. Gewoon een account op Bitbucket, we zijn maar met z'n tweeën dus dat werkt prima.

In eerste instantie is het hier vooral, commit en push. We hebben niet echt te maken met braches of iets dergelijks. Gewoon een checkout/pull/..? van de standaard basis en daarmee verder in een nieuwe repo. Dat samen met PhpStorm en dat vormt samen met Git wel een leuk geheel.

Nu nog een deploy-via-ftp manier vinden en we zijn klaar!

Wij werken met SVN hier, ben wel bekend met Git.
Ik zeg elke serieuze programmeur zou ermee moeten werken, heb zelf ook wat projecten lopen en vindt het toch fijn me code in versie beheer te hebben.

Voor deploy-via-ftp zijn er meer mogelijkheden.
phpStorm kan dit al (zie tools: deployment)

Wij gebruiken ook beanstalkapp.com dit is Subversion/Git/Mercurial etc. + deployment.
Deployment kan via FTP, SSH en vele andere manier.
Ben er wel van te spreken en de kosten zijn maandelijks ook laag.

[eekhoorn12]

Anoniem: 555367 schreef op dinsdag 21 januari 2014 @ 15:20:
Ik snap nu de basis van git maar ik snap niet goed hoe men een issue opent en sluit via terminal en hoe men milestones openzet

Wat je hier doet is twee verschillende dingen door elkaar halen. Git en de tooling die er door andere er om heen is gemaakt.
Git is puur en alleen een applicatie om je software code mee bij te houden, alle wijzigingen in op te slaan.

De issues en milestones die jij noemt zijn onderdelen van software ontwikkeling management software die gebruik maken van git om de code ook te tonen en een centrale plek te geven waar meerdere ontwikkelaars samen kunnen werken. Dit zijn dingen specifiek in bijvoorbeeld Github en Gitlab en deze staan los van git zelf.

[Hydra]

Idd. Wij gebruiken JIRA als ticketing systeem. Wij gebruiken de codes van de JIRA tickets als branchnamen voor features.

Edit: iets meer uitleg.

Een klant of projectleider maakt een ticket aan dat of een fix of een nieuwe feature. Dat wordt allemaal bijgehouden in een ticketing systeem. Een developer gaat met dit ticket bezig en maakt een nieuwe branch aan met als naam de ticketcode. Dat is eigenlijk de enige 'link' tussen die twee dingen (afgezien van wat tooling eromheen).

[ Voor 62% gewijzigd door Hydra op 21-01-2014 16:43 ]

[Kettrick]

Hydra schreef op dinsdag 21 januari 2014 @ 16:26:
Heb dat er hier ook een beetje uit moeten slaan. Met 3 man in 1 branch werken

Dat hoeft opzicht geen probleem te zijn, maar het hangt van je werkwijze af. Als je meedere malen per dag kleine correcte ( unit-tested! ) commits doet in verschillende onderdelen is daar niets mis mee. Met 3 man een maand lang iedereen in een eigen branch werken?, succes met de merge!

Git is flexibel, staar je niet blind op allerlei vastgelegde processen.

[Hydra]

Kettrick schreef op dinsdag 21 januari 2014 @ 16:39:
Dat hoeft opzicht geen probleem te zijn, maar het hangt van je werkwijze af. Als je meedere malen per dag kleine correcte ( unit-tested! ) commits doet in verschillende onderdelen is daar niets mis mee. Met 3 man een maand lang iedereen in een eigen branch werken?, succes met de merge!

Je krijgt iedere keer gedoe omdat ze wel moeten pushen (want, je wil die code in een centrale repo hebben en niet alleen op die machine) maar dan krijg je dus iedere keer conflicten die gemerged moeten worden. En aangezien dat niet door hen gedaan wordt (in princiepe) moet de projectleider dat doen. En omdat je die niet wil storen willen de devs niet dat er gemerged moet worden en gaan ze dus minder vaak pushen.

Daarnaast is het gewoon handig om wijzigingen netjes in een eigen branch te hebben zitten. Maakt codereviews ook makkelijker, anders is het iedere keer zo van "oh, maar die code is niet van mij, die is van Pietje".

[Kettrick]

Hydra schreef op dinsdag 21 januari 2014 @ 16:45:
[...]


Je krijgt iedere keer gedoe omdat ze wel moeten pushen (want, je wil die code in een centrale repo hebben en niet alleen op die machine) maar dan krijg je dus iedere keer conflicten die gemerged moeten worden. En aangezien dat niet door hen gedaan wordt (in princiepe) moet de projectleider dat doen. En omdat je die niet wil storen willen de devs niet dat er gemerged moet worden en gaan ze dus minder vaak pushen.

Dat klinkt meer als een process wat bij jullie is opgezet, alle kleine wijzigingen worden hier gewoon op master gedaan. Als ik een merge conflict heb los ik dat zelf op en push dat ook weer richting master. Ik zou niet weten waarom je niet je eigen merge conflicts op zou kunnen lossen

[Creepy]

Same here. Lokaal ontwikkel je in je eigen feature branche/branche per ticket en zodra je klaar bent pull je alle wijzigingen op de development branch, rebase je je feature branche met development, merged je feature branche de development branch weer in en push je dat weer door. Zo lost iedereen z'n eigen conflicten op

[Kettrick]

Creepy schreef op dinsdag 21 januari 2014 @ 17:11:
Same here. Lokaal ontwikkel je in je eigen feature branche/branche per ticket en zodra je klaar bent pull je alle wijzigingen op de development branch, rebase je je feature branche met development, merged je feature branche de development branch weer in en push je dat weer door. Zo lost iedereen z'n eigen conflicten op

Omdat het nog niet ingewikkeld genoeg is voor TS, laten we de wel/niet rebase discussie er ook nog even bij halen

[Hydra]

Kettrick schreef op dinsdag 21 januari 2014 @ 16:55:
Dat klinkt meer als een process wat bij jullie is opgezet, alle kleine wijzigingen worden hier gewoon op master gedaan. Als ik een merge conflict heb los ik dat zelf op en push dat ook weer richting master. Ik zou niet weten waarom je niet je eigen merge conflicts op zou kunnen lossen

Mergen doen we pas als code gereviewed is. Bij ons komt niks in de master terecht wat niet gereviewed is door een andere developer en wat niet getest is door de projectleider.

[HMS]

Kettrick schreef op dinsdag 21 januari 2014 @ 17:15:
[...]


Omdat het nog niet ingewikkeld genoeg is voor TS, laten we de wel/niet rebase discussie er ook nog even bij halen

Ik vind rebasen anders iets wat elke gebruiker zou moeten weten. Als je kijkt hoe Git intern werkt is het in principe ook vrij logisch (op enkele zeer exotische rebase examples na). Vooral als je met meerdere mensen werkt zul je moeten gaan rebasen om de history clean te houden. Git heeft hier veel betere tools voor dan SVN (vooral interactive rebase / squash / fixup).

[Firesphere]

Hydra schreef op dinsdag 21 januari 2014 @ 17:17:
[...]


Mergen doen we pas als code gereviewed is. Bij ons komt niks in de master terecht wat niet gereviewed is door een andere developer en wat niet getest is door de projectleider.

Oftewel, controlled git-flow.
http://nvie.com/posts/a-successful-git-branching-model/

[Kettrick]

HMS schreef op dinsdag 21 januari 2014 @ 17:18:
[...]
Ik vind rebasen anders iets wat elke gebruiker zou moeten weten.

Er is geen noodzaak om te rebasen, om die reden zou het ook niet op mijn lijstje staan voor iemand die net twee dagen bezig is met git.

Als je kijkt hoe Git intern werkt is het in principe ook vrij logisch (op enkele zeer exotische rebase examples na). Vooral als je met meerdere mensen werkt zul je moeten gaan rebasen om de history clean te houden. Git heeft hier veel betere tools voor dan SVN (vooral interactive rebase / squash / fixup).

Niets moet, maar veel mensen hebben de voorkeur om te doen.

Ik doe het zelf niet, nadat ik een keer of twee een halve ochtend kwijt was met de meeste exotische git commando's om mijn changes uiteindelijk in een remote branch te krijgen. Uiteraard mijn eigen fout, maar 'with great power comes great responsibilities' gaat voor git zeker op. Als het, om wat voor reden dan ook, niet doet wat je wil is het een drama om het weer goed te krijgen.

[Hydra]

Firesphere schreef op dinsdag 21 januari 2014 @ 17:30:
Oftewel, controlled git-flow.
http://nvie.com/posts/a-successful-git-branching-model/

Hydra schreef op dinsdag 21 januari 2014 @ 10:49:
Ik heb hetzelfde bij bedrijven die niet gemigreerd zijn / bezig zijn te migreren naar een distributed VCS, en dan zijn de opties v.z.i.w. Git of Mercurial. Voor persoonlijk gebruik, gebruik ik Git. Op werk gebruiken we Hg. We zijn nu met een migratie naar Git Flow bezig wat betreft workflow.

Wat overigens niet wegneemt dat wat wij doen niet perse "git flow" hoeft te zijn. Er zijn waarschijnlijk oneindig veel variaties in worklow te bedenken. Zelf vind ik git flow wat overkill voor simpele projecten, gewoon feature-branches van/naar default werkt prima.

[Firesphere]

Hydra schreef op dinsdag 21 januari 2014 @ 17:35:
[...]


[...]


Wat overigens niet wegneemt dat wat wij doen niet perse "git flow" hoeft te zijn. Er zijn waarschijnlijk oneindig veel variaties in worklow te bedenken. Zelf vind ik git flow wat overkill voor simpele projecten, gewoon feature-branches van/naar default werkt prima.

Git-flow neemt je het "ingewikkelde" gedeelte daarvan grotendeels uit handen.
Het werkt, vooral als je bijvoorbeeld SourceTree gebruikt (daar zit het in geintegreerd) is het echt zo heerlijk makkelijk.
Zelfs voor simpele projecten. Even worse, m'n eigen website heb ik feature-branches, hotfixes en auto-deployments van m'n master-branch via FTPloy En ik kan m'n eigen site nou niet het juweeltje van het internet noemen ofzo

Trouwens, wie heeft jouw avatar stuk gemaakt?

[Hydra]

Firesphere schreef op dinsdag 21 januari 2014 @ 17:39:
Git-flow neemt je het "ingewikkelde" gedeelte daarvan grotendeels uit handen.
Het werkt, vooral als je bijvoorbeeld SourceTree gebruikt (daar zit het in geintegreerd) is het echt zo heerlijk makkelijk.

Ja, dat gebruiken we ook op werk. M'n eigen projectjes doe ik gewoon via de command-line, maar die zijn zo enorm niet-complex dat ik daar het extra overzicht niet mis.

Zelfs voor simpele projecten. Even worse, m'n eigen website heb ik feature-branches, hotfixes en auto-deployments van m'n master-branch via FTPloy En ik kan m'n eigen site nou niet het juweeltje van het internet noemen ofzo

Ik heb op dit moment nieteens echt een eigen site. Zou ik wel weer eens aan moeten beginnen maar ongeveer 90% van waar ik aan begin maak ik uberhaupt nooit af. Gebrek aan tijd vooral.

Trouwens, wie heeft jouw avatar stuk gemaakt?

Je bedoelt die chick met dat pistool? Vond het tijd voor iets anders

[hackerhater]

Op mijn werk gebruiken we git voor versie-control van alle sites en software pakketten die we onder beheer hebben. En ik gebruik het zelf voor mijn eigen framework (die mijn werk weer gebruikt:P)
Deze vind je alleen niet op sites als github omdat we het zelf hosten.

We hebben standaard ook per project minimaal 3 branches :
- master (live)
- testing
- development

Vooral voor afhankelijkheden van externe pakketten is git enorm handig. Als bijvoorbeeld een bugfix van mijn framework naar de rest moet kan ik in die andere pakketten dit doen :
git checkout -b merge_framework_[datum]
git pull framework master
git checkout development
git merge [naam van de branch]

Master hoort per default af gebleven te worden. Alleen hotfixes toegestaan. development is de "speeltuin" van de devs en testing zegt genoeg lijkt me.

[Wolf87]

Wij zijn binnen ons bedrijf na een uitgebreid onderzoek 2 jaar terug overgestapt van Visual SourceSafe en SVN naar Mercurial.

Vanwege ontwikkelingen e.d. aan de linux kernel ben ik recentelijk GIT gaan gebruiken, maar ik ben blij dat we destijds de keuze voor Mercurial hebben gemaakt.

Enkele belangrijke punten voor mij.
- Documentatie is strake en beknopt. Met hg help vind je al snel wat je zoekt
- In git is data niet zeker. Je kan history aanpassen en data verwijderen. In Mercurial kan je met een rollback alleen een laatste pull of commit ongedaan maken.
- Command line interface can git is niet consistent

[Hydra]

Het is een misvatting dat je data kunt verwijderen in git. Via reflog is in princiepe alles terug te halen.

Git is IMHO inderdaad minder gebruiksvriendelijk dan Mercurial. De git community is een beetje een circlejerk van nerds die dat verdedigen, maar daar schijnt langzaam verbetering in te komen. Maar dat neemt niet weg dat de basis van git relatief simpel te leren is.

[DXaroth]

Wolf87 schreef op dinsdag 21 januari 2014 @ 20:09:
Enkele belangrijke punten voor mij.
- Documentatie is strake en beknopt. Met hg help vind je al snel wat je zoekt
- In git is data niet zeker. Je kan history aanpassen en data verwijderen. In Mercurial kan je met een rollback alleen een laatste pull of commit ongedaan maken.
- Command line interface can git is niet consistent

Git is ook gemaakt door kernel mensen, die denken aan de volgende dingen:
- Het moet stabiel zijn
- Het moet snel zijn
- Het moet doen wat er gevraagd wordt (sudo make me a sandwich)
- Het moet veilig zijn

Nu verschilt HG met Git op de middelste 2 punten; git is in veel grote handelingen sneller (al is hg best goed bezig met dat verschil te verminderen), zoals merges in omgevingen met duizenden aan bestanden (lees: de kernel).. HG heeft ook de illusie dat zij kunnen regeren in wat een gebruiker moet kunnen.. ja het is niet 'veilig' dat je geschiedenis kan aanpassen (al kan je dit wel doen in hg, zolang je het op de master repository doet), maar elke git client zal gaan zeuren als hij merkt dat zijn reflog niet klopt met die van de repository waar hij het vandaan haalt... als de gebruiker dan instrueerd dat de client stil moet zijn en moet luisteren, dan doet de client dat (maar niet na uitvoerig te hebben geschreeuwd).. het is het verschil tussen 'het systeem bepaalt' en 'het systeem adviseert wat de gebruiker het beste kan doen, maar zal hoe dan ook luisteren'

[Freeaqingme]

Hydra schreef op dinsdag 21 januari 2014 @ 20:26:
Het is een misvatting dat je data kunt verwijderen in git. Via reflog is in princiepe alles terug te halen.

Dat kan wel? Zorgen dat een commit niet gekoppeld is aan een branch, tag of andere commit, en daarna de garbage collector draaien?

[Firesphere]

Hoe wilde je precies een commit niet pushen?

[HMS]

Freeaqingme schreef op dinsdag 21 januari 2014 @ 22:06:
[...]


Dat kan wel? Zorgen dat een commit niet gekoppeld is aan een branch, tag of andere commit, en daarna de garbage collector draaien?

Volgens mij doelde Hydra er op dat je via de reflog veel kan terughalen, daarnaast is de garbage collector vrij ruim ingesteld zodat die niet al te vaak draait.

Uiteraard, als je de GC draait dan kan het via de reflog ook niet meer.

Firesphere schreef op dinsdag 21 januari 2014 @ 22:09:
Hoe wilde je precies een commit niet pushen?

Door bijvoorbeeld een interactive rebase te doen en daar een regel te verwijderen (aangenomen dat er geen gekke merge conflicts optreden). En dan de branch pushen, je kan je history rewriten.

Alhoewel, als het niet gepushed is, rewrite je dan history of pas je de toekomst aan? Het ligt eraan hoe je er naar kijkt . Zolang je niet pusht kan je het niet echt history noemen.

[Kettrick]

HMS schreef op dinsdag 21 januari 2014 @ 23:34:
Zolang je niet pusht kan je het niet echt history noemen.

Zodra je het commit is het history, dat is nu juist het leuke van een dvcs, als je het over svn hebben ben ik het met je eens .

Ik voel me overigens redelijk veilig zodra ik iets gecommit heb, maar die paar keer dat ik wel een WTF moment had was mijn eerste reactie het maken van een tarball. Maar dat geldt voor elk VCS, niet alleen Git.

[pedorus]

HMS schreef op dinsdag 21 januari 2014 @ 23:34:
Uiteraard, als je de GC draait dan kan het via de reflog ook niet meer.

Dat gebeurd bij mijn weten pas als het reflog gexpired is; het zijn dus 3 acties, die je niet per ongeluk kan doen. Al weet ik niet of bfg ook aan reflog doet, dan zouden het 2 acties zijn. Maar dat tooltje is dan ook specifiek bedoelt voor het verwijderen van verkeerd gecommitte files..

[drm]

Voor iedereen die iets meer wil weten over de internals van git is dit filmpje wel de moeite waard. Beetje rommelige (en vrij lange) presentatie, maar wel verhelderend en interessant: http://www.karsten-heyman...th-construction-toys.html

De belangrijkste basics komen aan de orde en voor mij maakte het in ieder geval een hoop duidelijk.

[HMS]

Kettrick schreef op woensdag 22 januari 2014 @ 00:25:
[...]

Zodra je het commit is het history, dat is nu juist het leuke van een dvcs, als je het over svn hebben ben ik het met je eens .

Als niemand je commit kan zien, is ie dan ook echt gebeurd? Voor jou misschien wel, maar voor de wereld niet. Dus je kan het nog aanpassen, maar zodra je het pusht is het public knowledge. Dan kan je opeens een stuk lastiger terug . Vandaar mijn onderscheid tussen history en future, alles wat niet gepusht is noem ik de future aanpassen, alles wat al gepusht is history.

Ik hoop dat nog nooit iemand hier meegemaakt heeft dat iemand de remote een 'git push -f' heeft gegeven.

offtopic:
Bij een vrouw brengt een 'push --force' je ook in de problemen

[Freeaqingme]

Nouja, het komt bij mij toch voor dat ik iets maak op m'n workstation op m'n werk, thuis ook een clone heb, en dan vanuit huis push naar m'n workstation over ssh. Hoewel er dan nog niets gepushed is vanaf m'n workstation, geldt ie wel weer als remote voor m'n bak thuis.

[Hydra]

Het verschil zit 'em een beetje in die -f optie

[hackerhater]

-f bij de commando's is evil. Je moet heel goed weten wat je doet voor je die optie gebruikt.

[Anoniem: 555367]

ik heb nu ook een gem gevonden op github genaamd ghi.

Geschikt voor opening en closing op github. Iemand hier enige ervaring mee?

[DXaroth]

Anoniem: 555367 schreef op woensdag 22 januari 2014 @ 09:04:
ik heb nu ook een gem gevonden op github genaamd ghi.

Geschikt voor opening en closing op github. Iemand hier enige ervaring mee?

wat wil je er precies mee? bedoel, het is een CLI voor wat je met je browser ook kan, dus qua ervaring zal het meerendeel aan github zitten, niet in een simpel script...

[BtM909]

Anoniem: 555367 schreef op woensdag 22 januari 2014 @ 09:04:
ik heb nu ook een gem gevonden op github genaamd ghi.

Geschikt voor opening en closing op github. Iemand hier enige ervaring mee?

Dit gaat toch niet een verzamelde help Ziekhoof verder met z'n zoektocht naar nieuwe technologie? Gelieve de one-liners met vragen weglaten en ontopic blijven

[Gomez12]

Wolf87 schreef op dinsdag 21 januari 2014 @ 20:09:
- In git is data niet zeker. Je kan history aanpassen en data verwijderen. In Mercurial kan je met een rollback alleen een laatste pull of commit ongedaan maken.

Ik mag toch hopen dat hg ook je history kan aanpassen en data verwijderen, anders valt het bij mij nog niet eens onder de term werkbare vcs.

Als de stagiaire toevallig per ongeluk een dvd-iso commit moet ik daar niet nog 10 jaar later last van hebben. In een beetje vcs is verwijderen heel erg moeilijk (omdat het indruist tegen het idee van een vcs) maar het moet niet onmogelijk zijn want dan sleep je elke menselijk fout tot in de eeuwigheid mee (en heb je een risico dat mensen bang worden iets fout te doen in het vcs en dat wil je niet)

Normaliter boeit het me niet dat iemand een binary file commit (op het totaal en de kostenbaat staat is het verschil nihil) maar ik heb wel meegemaakt dat mensen voor een project wat voorbeeldvideo's hadden en toen ging de repo dus in 1 dag van 200 MB naar 20+ GB, toen gingen er dus even een paar thuiswerkers over de jank
En dan ben je dus blij dat je data kan verwijderen, want de mensen die het deden kan je 1x goed toespreken maar je kan gelijk erbij vertellen dat het wel weer verwijderd is en dat het dus geen eeuwigdurende schande is, het kost heel wat productietijd (en dus geld) maar als er eens een keertje een binary van 5 MB invliegt, tja pech doen we niets aan.