[Github] Beginnende vraag over Github/Git

[BramCoding]

Hey,

voor het eerst wil ik graag Github gaan gebruiken en de software Git om het samenwerken tussen verschillende personen in een project goed te laten verlopen. Dit is een schoolopdracht waarin we een dynamisch dashboard moeten maken om zo de werking van databases, html, css en php onder de knie te krijgen.

Echter snap ik nog niet zo goed hoe Github precies tot een voordeel kan werken als we met 3 ter zelfde tijd werken aan het project en hoe ik Github en Git ten opzichte van elkaar moet zien. Waarom heb ik deze allebei nodig?

Op dit moment heb ik via Youtube reeds geleerd hoe je aanpassingen aan een project maakt, en de volgende commando's gebruik ik daarvoor;

git clone 'link naar project'
--dan maak ik mijn veranderingen in de files die ik wil veranderen
git add 'naam van bestand' OF git add * (om alle bestanden te adden)
git commit -m "hier de message"
git push origin master

Nu, ik vraag me enkele dingen af..

1) Waarom moet je eerst een bestand "adden", het daarna committen en het daarna pushen. Dit zijn 3 commando's om 1 bestand waaraan je gewerkt hebt terug up te loaden naar Github. Wat is het verschil dan net tussen de 3 commando's.

2) Wat als ik en mijn partner elk lokaal de git clonen, en dan veranderingen maken (elk andere veranderingen). Stel dat ik dan eerst mijn veranderingen push, en mijn partner 5 minuten later zijn veranderingen. Wie zijn verandering worden dan uiteindelijk onthouden door Github?
Met andere woorden; hoe lost Github het probleem op dat 2 personen ter zelfder tijd werken aan een project en toch beide hun werk correct in de files zal staan?

Ik hoop dat iemand begrijpt wat ik bedoel, en dat ik het goed verwoord. Geraak er moeilijk aan uit..

Alvast bedankt!

[Radiant]

https://try.github.io/

[CyBeR]

BramVanha schreef op zondag 22 april 2018 @ 22:19:

1) Waarom moet je eerst een bestand "adden", het daarna committen en het daarna pushen. Dit zijn 3 commando's om 1 bestand waaraan je gewerkt hebt terug up te loaden naar Github. Wat is het verschil dan net tussen de 3 commando's.

Git add zegt alleen, 'hey git, dit bestand moet je iets mee doen'. Git commit zegt 'hey git, ik heb veranderingen gemaakt die ik wil onthouden', en git push zegt 'stuur mijn veranderingen naar github'.

2) Wat als ik en mijn partner elk lokaal de git clonen, en dan veranderingen maken (elk andere veranderingen). Stel dat ik dan eerst mijn veranderingen push, en mijn partner 5 minuten later zijn veranderingen. Wie zijn verandering worden dan uiteindelijk onthouden door Github?

De tweede persoon krijgt dan een error en moet eerst de wijzigingen van de 1e persoon meenemen.

[418O2]

1. Git is een stuk software dat github aanbiedt.
2. Je moet niet alle files by default committen. Sommige files (IDE config, gecompileerde bestanden, tijdelijke bestanden) wil je niet in git.
3. Als je commit en het bestand dat je commit is Al gewijzigd, moet je de wijzigingen eerst ophalen en eventuele conflicten oplossen.

Ik wil je adviseren om even goed uit te zoeken hoe je git hoort te gebruiken. En als beginner is het verstandig om een GUI te gebruiken (sourcetree bijvoorbeeld)

[BramCoding]

CyBeR schreef op zondag 22 april 2018 @ 22:21:
[...]


Git add zegt alleen, 'hey git, dit bestand moet je iets mee doen'. Git commit zegt 'hey git, ik heb veranderingen gemaakt die ik wil onthouden', en git push zegt 'stuur mijn veranderingen naar github'.


[...]


De tweede persoon krijgt dan een error en moet eerst de wijzigingen van de 1e persoon meenemen.

Dan moet die tweede persoon terug git clone 'link' doen, maar dan worden de files die de tweede persoon net aangepast heeft overwritten door de "nieuwe files" van persoon 1, en is al zijn werk verloren toch? Of moet je dan clonen naar een ander project?

[SteveWoz]

Werk het volgende online boek door. Dat was voor mij het meest leerzame en wellicht voor jou/anderen ook.
https://git-scm.com/book/...ted-About-Version-Control
Is ook volledig in het Nederlands beschikbaar, maar ik vond die vertaling op bepaalde punten niet zo goed.

[BramCoding]

Radiant schreef op zondag 22 april 2018 @ 22:21:
https://try.github.io/

Die tutorial volg ik straks eventjes. Dankuwel!

[418O2]

https://hackernoon.com/understanding-git-fcffd87c15a3

Lees dat ook eens.

[BramCoding]

418O2 schreef op zondag 22 april 2018 @ 22:21:
1. Git is een stuk software dat github aanbiedt.
2. Je moet niet alle files by default committen. Sommige files (IDE config, gecompileerde bestanden, tijdelijke bestanden) wil je niet in git.
3. Als je commit en het bestand dat je commit is Al gewijzigd, moet je de wijzigingen eerst ophalen en eventuele conflicten oplossen.

Ik wil je adviseren om even goed uit te zoeken hoe je git hoort te gebruiken. En als beginner is het verstandig om een GUI te gebruiken (sourcetree bijvoorbeeld)

Met "je moet niet alle files by default committen, dan bedoel je dat ik niet: git add * moet doen, maar enkel de afzonderlijke veranderde bestanden moet adden?

[418O2]

BramVanha schreef op zondag 22 april 2018 @ 22:28:
[...]


Met "je moet niet alle files by default committen, dan bedoel je dat ik niet: git add * moet doen, maar enkel de afzonderlijke veranderde bestanden moet adden?

Ja. Maak ook even een standaard gitignore file voor je project, scheelt een hoop

https://www.gitignore.io

[BramCoding]

418O2 schreef op zondag 22 april 2018 @ 22:31:
[...]

Ja. Maak ook even een standaard gitignore file voor je project, scheelt een hoop

https://www.gitignore.io

Ik ga na de tutorial(s) even opzoeken wat een gitignore file mag wezen.
Waarom wil ik die IDE config files bijvoorbeeld niet in mijn git. En kan ik mijn git dan zien als een soort tijdelijke project, en door het te committen maak ik het van tijdelijk naar definitief en dan via push zet ik dit definitieve terug op de Github servers?

[Tsunami]

BramVanha schreef op zondag 22 april 2018 @ 22:24:
[...]


Dan moet die tweede persoon terug git clone 'link' doen, maar dan worden de files die de tweede persoon net aangepast heeft overwritten door de "nieuwe files" van persoon 1, en is al zijn werk verloren toch? Of moet je dan clonen naar een ander project?

De tweede persoon zal zijn wijzigingen niet kunnen pushen, omdat zijn lokale branch niet gelijk loopt met die op GitHub. Persoon 2 doet dus eerst git fetch, gevolgd door git merge origin/master. Als er merge conflicten zijn moeten die eerst opgelost worden, en daarna kan persoon 2 pushen.

Vervolgens doet persoon 1 ook git fetch gevolgd door git merge origin/master, en dan hebben beide personen dezelfde code.

[418O2]

BramVanha schreef op zondag 22 april 2018 @ 22:36:
[...]


Ik ga na de tutorial(s) even opzoeken wat een gitignore file mag wezen.
Waarom wil ik die IDE config files bijvoorbeeld niet in mijn git. En kan ik mijn git dan zien als een soort tijdelijke project, en door het te committen maak ik het van tijdelijk naar definitief en dan via push zet ik dit definitieve terug op de Github servers?

Git is heel krachtig, maar levert je veel kopzorgen op als je maar wat doet.

Jouw ide setting e.d. zijn persoonlijk. Anderen willen die niet hebben, dus dat moet niet in git.

Je laatste opmerking snap ik geen hout van, lees de tutorials maar, dan snap je het wel.

[BramCoding]

Bedankt voor de snelle reacties, ik lees/kijk de tutorials eens door en geraak er dan hopelijk wel aan uit.

[Donderpoes]

Je cloned eerst je project. Je voert je wijzigingen uit op bestaande of nieuwe bestanden. Je commit je wijzigingen en pusht deze naar de repository. Als er meerdere mensen aan werken kan je met git pull je branch bijwerken. Commit wel eerst je eigen wijzigingen.
Als de andere persoon ook wijzigingen gedaan heeft die niet botsen met jouw wijzigingen zullen jullie wijzigingen automatisch samengevoegd worden. Als ze wel botsen zul je ze handmatig moeten mergen.

Niet telkens de repository opnieuw clonen. Maar gebruik pull.

Je kan ook nieuwe branches aanmaken voor bijvoorbeeld nieuwe features of bugfixes. Dan merge de nieuwe branch in master als je klaar bent met de feature of bugfix.

[Creepy]

Overigens is het maar net hoe je "Git is een stuk software dat github aanbiedt" interpreteert want Git wordt niet aangeboden door Github. Zie https://git-scm.com/. Github biedt je de mogelijkheid om Git repositories te hosten, maar dat kan ook zonder Github.

[Hydra]

418O2 schreef op zondag 22 april 2018 @ 22:21:
1. Git is een stuk software dat github aanbiedt.

Err wat?

Github is gewoon hosting voor git met een social component.

[Hydra]

BramVanha schreef op zondag 22 april 2018 @ 22:28:
Met "je moet niet alle files by default committen, dan bedoel je dat ik niet: git add * moet doen, maar enkel de afzonderlijke veranderde bestanden moet adden?

Hoe je normaal werkt is dat je de bestanden die niet in git terecht moeten komen aan je .gitignore toevoegt. De rest kun je dan gewoon met git add . toevoegen aan je staged set en dan met git commit committen. De drie belangrijkste stappen zijn dus add (toevoegen aan staged set), commit (committen van staged set) en push (jouw changes doorduwen naar de remote server).

Hoewel je met git screw-ups kan maken is het overigens extreem moeilijk permanent dingen kwijt te raken. Als iets ooit gecommit is, is het hoe dan ook onderdeel van je history. Kijk dus uit met passwords enzo

[whoami]

Ik vind dat hier toch wel wat basis-informatie ontbreekt, dus hierbij mijn poging

Git is een source-control systeem waarbij je jouw code in een repository plaatst. Die repository staat lokaal op jouw computer, maar het is natuurlijk de bedoeling dat je die repository ook ergens remote plaatst, zodanig dat andere teamleden daar ook toegang tot hebben.
Github, Bitbucket, etc... zijn providers die je toelaten om jouw repository remote te 'publiceren'.

Een ander teamlid kan dus de code die gepublished is clonen naar een eigen lokale repository.

Wijzigingen die je aanbrengt, commit je naar de lokale repository en push je nadien naar de remote.
Iemand anders kan zijn eigen lokale repository synchroniseren met de remote door een pull te gaan doen.

De kracht van Git schuilt er voor mij in dat je verschillende branches kunt maken. Je werkt dus niet rechtstreeks op de master branch, maar je maakt een branch per feature die je gaat implementeren (zo doe ik het toch). Als de wijzigingen klaar zijn kan je die feature-branch mergen met de master branch dmv een pull-request. Je kan een aantal policies opstellen zodanig dat je afdwingt dat iemand anders de code moet gereviewed hebben en de build + unittests moeten slagen bv voordat de pull-request kan gemerged worden met master.
Hetzelfde geldt ook voor bugfixen; stel je hebt al een versie gereleased die je in Git gelabeled hebt. Als er een bug-report binnenkomt kan je een nieuwe branch maken op basis van dat label en de fix gaan implementeren op die versie.

Je wilt natuurlijk niet alle bestanden in je git - repository hebben: build outputs, personal setting files, etc... wil je niet in de repository. Hiervoor heb je de .gitignore file. Per IDE zijn er wel wat standaard templates te vinden die de ongewenste files buiten de repo houden.

Ik denk dat bovenstaande een summiere samenvatting is van Git die je kan helpen om de links / artikels die hier reeds aangehaald zijn beter te begrijpen

BramVanha schreef op zondag 22 april 2018 @ 22:19:
1) Waarom moet je eerst een bestand "adden", het daarna committen en het daarna pushen. Dit zijn 3 commando's om 1 bestand waaraan je gewerkt hebt terug up te loaden naar Github. Wat is het verschil dan net tussen de 3 commando's.

Met gid add ga je bestanden gaan stagen. Als je commit ga je de gestagede bestanden gaan commiten. Hiermee kan je dus gaan beslissen welke bestanden je samen in één commit wil hebben, en welke je in een andere commit wil hebben.
Als je commit, dan commit je eerst naar je lokale repository. Met git push ga je de lokale wijzigingen gaan overbrengen naar de [i]remote[/.]

2) Wat als ik en mijn partner elk lokaal de git clonen, en dan veranderingen maken (elk andere veranderingen). Stel dat ik dan eerst mijn veranderingen push, en mijn partner 5 minuten later zijn veranderingen. Wie zijn verandering worden dan uiteindelijk onthouden door Github?
Met andere woorden; hoe lost Github het probleem op dat 2 personen ter zelfder tijd werken aan een project en toch beide hun werk correct in de files zal staan?

Beiden. Git is slim genoeg om de wijzigingen automatisch te mergen, en als hij daar niet in slaagt, dan heb je merge conflicts die je zelf (manueel) zal moeten oplossen.

[ Voor 25% gewijzigd door whoami op 25-04-2018 11:32 ]

[Stoelpoot]

Naast de uitleg die iedereen hier geeft: Je zit op een opleiding, dus vraag advies en hulp bij je docenten. Daar zijn ze voor, Git is een veelgebruikt product in de industrie, Github ook, dus zij zullen je daar bij kunnen helpen. Face-to-face hulp is vaak vele malen nuttiger voor dit soort algemene vragen.

[Nila]

Creepy schreef op zondag 22 april 2018 @ 22:45:
Overigens is het maar net hoe je "Git is een stuk software dat github aanbiedt" interpreteert want Git wordt niet aangeboden door Github. Zie https://git-scm.com/. Github biedt je de mogelijkheid om Git repositories te hosten, maar dat kan ook zonder Github.

Heeft Github nu wel gratis privé repositories? Laatste keer dat ik checkte moest je hiervoor betalen. Daarom heb ik voor een klein project gekeken naar Gitlab waarbij ik wel een privé repositorie kon maken.

Je wilt je project namelijk niet open en bloot hebben staan als je dit niet wilt delen met de rest van de wereld.

[Marc3l]

^{Kleine tip, willen jullie de repository privé houden gebruik dan bitbucket.org deze is gratis voor privé projecten.}

[Stoelpoot]

Nila schreef op maandag 23 april 2018 @ 10:02:
[...]


Heeft Github nu wel gratis privé repositories? Laatste keer dat ik checkte moest je hiervoor betalen. Daarom heb ik voor een klein project gekeken naar Gitlab waarbij ik wel een privé repositorie kon maken.

Je wilt je project namelijk niet open en bloot hebben staan als je dit niet wilt delen met de rest van de wereld.

Marc3l schreef op maandag 23 april 2018 @ 10:03:
^{Kleine tip, willen jullie de repository privé houden gebruik dan bitbucket.org deze is gratis voor privé projecten.}

Geen gratis prive repo's, nee. Zoals gezegd kunnen Bitbucket en Gitlab dit wel. Vraag me wel af of het nodig is om een schoolopdracht prive te houden.

[whoami]

Nila schreef op maandag 23 april 2018 @ 10:02:
[...]


Heeft Github nu wel gratis privé repositories? Laatste keer dat ik checkte moest je hiervoor betalen. Daarom heb ik voor een klein project gekeken naar Gitlab waarbij ik wel een privé repositorie kon maken.

Je wilt je project namelijk niet open en bloot hebben staan als je dit niet wilt delen met de rest van de wereld.

Nee, Bitbucket heeft die wel, net zoals VSTS

[hoi1234]

Je kunt ook private repositories aanmaken met github. Je moet dan alleen premium hebben, maar als je het github studentpack activeert, is dit gedurende je opleiding gratis. (En je krijgt nog meer leuke voordelen)

[Lye]

Stoelpoot schreef op maandag 23 april 2018 @ 10:14:Vraag me wel af of het nodig is om een schoolopdracht prive te houden.

Het is zeker wel nodig om schoolopdrachten privé te houden. Immers kun je met openbare opdrachten onbedoeld meewerken aan fraude wat ook voor de originele schrijver nare gevolgen kan hebben. Het zou niet de eerste keer zijn dat studenten letterlijk een uitwerking van internet trekken, als dan blijkt dat beide partijen bijvoorbeeld op dezelfde school zitten kan een examencommissie nog wel eens zijn bedenkingen hebben of het wel zo zeer "onbedoeld" was.

Gouden tip: hou je schoolopdrachten gewoon voor jezelf. Voor groepsopdrachten geldt dan natuurlijk dat je het binnen de groep houdt.

[418O2]

Hydra schreef op maandag 23 april 2018 @ 07:41:
[...]


Err wat?

Github is gewoon hosting voor git met een social component.

Ik wou het even simpel houden in deze fase

[Hydra]

418O2 schreef op dinsdag 24 april 2018 @ 19:52:
Ik wou het even simpel houden in deze fase

Sure, maar het klopt gewoon niet. En dat soort fouten blijven makkelijk hangen bij beginners.

[Creepy]

Als er bij ons iemand komt solliciteren vraag ik altijd of ze het verschil tussen git en github kunnen uitleggen. Ik heb er nu genoeg gezien die ervaring met git en github benoemen op hun CV maar het verschil gewoon niet weten......

[BramCoding]

hoi1234 schreef op maandag 23 april 2018 @ 10:46:
Je kunt ook private repositories aanmaken met github. Je moet dan alleen premium hebben, maar als je het github studentpack activeert, is dit gedurende je opleiding gratis. (En je krijgt nog meer leuke voordelen)

Dit kijk ik zeker even in of mijn universiteit dit ondersteunt. Bedankt voor de tip!

[BramCoding]

Creepy schreef op woensdag 25 april 2018 @ 09:55:
Als er bij ons iemand komt solliciteren vraag ik altijd of ze het verschil tussen git en github kunnen uitleggen. Ik heb er nu genoeg gezien die ervaring met git en github benoemen op hun CV maar het verschil gewoon niet weten......

En het verschil is dat Git software is om bestanden van en naar een server te sturen (die van Github in dit geval) en dat Github gewoon een cloud is waar je projecten worden bijgehouden?

[Mercatres]

BramVanha schreef op vrijdag 27 april 2018 @ 18:37:
[...]


En het verschil is dat Git software is om bestanden van en naar een server te sturen (die van Github in dit geval) en dat Github gewoon een cloud is waar je projecten worden bijgehouden?

Exact!
Git is software, en als je die ergens online wilt hebben zal je - net zoals andere software - ergens moeten hosten. Je kan dit zelf hosten doen (met Gitlab bvb.) of een cloud oplossing nemen (zoals Bitbucket, Visual Studio Team Services, GitHub).

[Ramon]

BramVanha schreef op vrijdag 27 april 2018 @ 18:37:
[...]


En het verschil is dat Git software is om bestanden van en naar een server te sturen (die van Github in dit geval) en dat Github gewoon een cloud is waar je projecten worden bijgehouden?

Stuitend dat na 30 posts nog zo'n basale vraag gesteld moet worden. Nee, git is geen software om bestanden van en naar een server te sturen. Git is een versiebeheersysteem. Kort gezegd stelt git je in staat om wijzigingen aan bestanden te beheren. Daardoor kan je bijvoorbeeld zien door wie welke wijzigingen wanneer zijn gedaan aan een bepaald bestand, en ook waarom (als de commit messages goed worden geschreven).

Github is één van de vele aanbieders van repositories, je hoeft het dus niet te gebruiken, er zijn ook andere alternatieven zoals bitbucket en je kan ook zonder een cloudhosted partij git gebruiken (als je alleen met eigen projecten bezig bent bijvoorbeeld).

En om antwoord te geven op je puntjes:

1) Waarom moet je eerst een bestand "adden", het daarna committen en het daarna pushen. Dit zijn 3 commando's om 1 bestand waaraan je gewerkt hebt terug up te loaden naar Github. Wat is het verschil dan net tussen de 3 commando's.

Wat je met git doet is: je voegt een bestand toe (add) aan een lijst met wijzigingen (commit) maar dit staat pas echt vast als het in de remote repository is (push)

Het kan namelijk voorkomen dat je niet alle bestanden die je hebt gewijzigd in dezelfde commit wilt hebben , bijvoorbeeld om het voor anderen duidelijker te maken of om het makkelijker te maken om bepaalde dingen te kunnen terug draaien.

Daarnaast stelt de scheiding tussen commit en push je ook in staat om offline te werken.

2) Wat als ik en mijn partner elk lokaal de git clonen, en dan veranderingen maken (elk andere veranderingen). Stel dat ik dan eerst mijn veranderingen push, en mijn partner 5 minuten later zijn veranderingen. Wie zijn verandering worden dan uiteindelijk onthouden door Github?
Met andere woorden; hoe lost Github het probleem op dat 2 personen ter zelfder tijd werken aan een project en toch beide hun werk correct in de files zal staan?

Als jij en je partner niet in dezelfde bestanden hebben gewerkt dan zal dat gewoon goed gaan. Hebben jullie dat wel gedaan en kan git er geen kaas van maken, dan krijg je een merge conflict. Git zegt dan "Woop, jullie hebben beide in dit bestand op dezelfde regel iets aangepast, welke regel moet ik bewaren??" Waarna jij (eventueel samen met je partner) door de code kan lopen en zien wat er bewaard moet worden en wat niet.

[BramCoding]

Ramon schreef op vrijdag 27 april 2018 @ 19:28:
[...]

Stuitend dat na 30 posts nog zo'n basale vraag gesteld moet worden. Nee, git is geen software om bestanden van en naar een server te sturen. Git is een versiebeheersysteem. Kort gezegd stelt git je in staat om wijzigingen aan bestanden te beheren. Daardoor kan je bijvoorbeeld zien door wie welke wijzigingen wanneer zijn gedaan aan een bepaald bestand, en ook waarom (als de commit messages goed worden geschreven).

Github is één van de vele aanbieders van repositories, je hoeft het dus niet te gebruiken, er zijn ook andere alternatieven zoals bitbucket en je kan ook zonder een cloudhosted partij git gebruiken (als je alleen met eigen projecten bezig bent bijvoorbeeld).

En om antwoord te geven op je puntjes:

[...]


Wat je met git doet is: je voegt een bestand toe (add) aan een lijst met wijzigingen (commit) maar dit staat pas echt vast als het in de remote repository is (push)

Het kan namelijk voorkomen dat je niet alle bestanden die je hebt gewijzigd in dezelfde commit wilt hebben , bijvoorbeeld om het voor anderen duidelijker te maken of om het makkelijker te maken om bepaalde dingen te kunnen terug draaien.

Daarnaast stelt de scheiding tussen commit en push je ook in staat om offline te werken.


[...]


Als jij en je partner niet in dezelfde bestanden hebben gewerkt dan zal dat gewoon goed gaan. Hebben jullie dat wel gedaan en kan git er geen kaas van maken, dan krijg je een merge conflict. Git zegt dan "Woop, jullie hebben beide in dit bestand op dezelfde regel iets aangepast, welke regel moet ik bewaren??" Waarna jij (eventueel samen met je partner) door de code kan lopen en zien wat er bewaard moet worden en wat niet.

Dit was een zeer duidelijk antwoord (buiten 1 dingetje), waarvoor dank!
Waarom precies is een versiebeheersysteem dan geen software? Hoort dit hier dan niet onder?

[Gropah]

BramVanha schreef op vrijdag 27 april 2018 @ 23:21:
[...]


Dit was een zeer duidelijk antwoord (buiten 1 dingetje), waarvoor dank!
Waarom precies is een versiebeheersysteem dan geen software? Hoort dit hier dan niet onder?

Het is een stuk software geschreven om het systeem mogelijk te maken. Het punt wat hij probeert te maken is dat het een versiebeheersysteem is, en dus niet software om bestanden over en weer te sturen. Het doel van de software is om bij iedereen de code dezelfde staat te laten hebben op dezelfde momenten en op de verschillende werkplekken/branches. Om dat te doen stuurt het bestanden heen en weer, maar doet het nog veel meer zoals het vinden van wijzigingen in bestanden en die toepassen wanneer ze gevonden worden bij een update.

[ Voor 24% gewijzigd door Gropah op 27-04-2018 23:27 ]

[farlane]

BramVanha schreef op vrijdag 27 april 2018 @ 23:21:
[...]
Dit was een zeer duidelijk antwoord (buiten 1 dingetje), waarvoor dank!
Waarom precies is een versiebeheersysteem dan geen software? Hoort dit hier dan niet onder?

Een VCS is wel software (in het algemeen), maar niet perse om "bestanden te delen". Het doet dat wel, maar met de insteek om bij te houden wie welke veranderingen heeft aangebracht in bestanden, en in welke volgorde.

[BramCoding]

Gropah schreef op vrijdag 27 april 2018 @ 23:25:
[...]


Het is een stuk software geschreven om het systeem mogelijk te maken. Het punt wat hij probeert te maken is dat het een versiebeheersysteem is, en dus niet software om bestanden over en weer te sturen. Het doel van de software is om bij iedereen de code dezelfde staat te laten hebben op dezelfde momenten en op de verschillende werkplekken/branches. Om dat te doen stuurt het bestanden heen en weer, maar doet het nog veel meer zoals het vinden van wijzigingen in bestanden en die toepassen wanneer ze gevonden worden bij een update.

Het er weer te vlug over gelezen en mis geïnterpreteerd inderdaad.
Ik ben wat aan het prutsen en krijg het al wat meer in de vingers

[base_]

Als je een gesloten (niet publiek) project wilt delen met anderen zal je je repository (de git database) op een gesloten omgeving moeten zetten, dit kan via:
- een fileshare (smb/nfs/ssh)
- github premium (betaald)
- bitbucket (gratis tot 5 users)
- een self hosted oplossing (gitlab, gogs etc)

[Gropah]

base_ schreef op vrijdag 27 april 2018 @ 23:35:
Als je een gesloten (niet publiek) project wilt delen met anderen zal je je repository (de git database) op een gesloten omgeving moeten zetten, dit kan via:
- een fileshare (smb/nfs/ssh)
- github premium (betaald)
- bitbucket (gratis tot 5 users)
- een self hosted oplossing (gitlab, gogs etc)

Ik zou een private repo nooit zo maar via fileshare delen en dat is voor samenwerken ook gewoon niet een goed idee. Bitbucket is zeker een goede. Als je instelling word erkent door Github kun je het mailadres van je instelling ook toevoegen aan je github account, dan krijg je onbeperkt private repo's, bij bitbucket hetzelfde maar dan voor aantal users. Je kunt ook kijken naar GitLab, wat volgens mij een gratis hosted plan heeft waar je oneindig aantal users private repo kunt hebben, maar dan mis je wat andere dingen voor er naast (dacht ik).

[BramCoding]

Ik ben nog student aan een universiteit en heb mijn student versie van Github kunnen activeren, gratis private repo's dus tot ik afgestudeerd ben

[base_]

Gropah schreef op vrijdag 27 april 2018 @ 23:41:
[...]
Ik zou een private repo nooit zo maar via fileshare delen en dat is voor samenwerken ook gewoon niet een goed idee

Een secure fileshare.... Een publieke fileshare is NOOIT een goed idee Als de werkgroep op hetzelfde netwerk zit (al dan niet met vpn) werkt het prima hoor. Daarbuiten werkt git ook uitstekend icm met ssh, een stuk veiliger en handiger als ftp Je wilt niet weten hoeveel bedrijven nog steeds aanklooien met ftp op live servers

[Gropah]

base_ schreef op vrijdag 27 april 2018 @ 23:48:
[...]


Een secure fileshare.... Een publieke fileshare is NOOIT een goed idee Als de werkgroep op hetzelfde netwerk zit (al dan niet met vpn) werkt het prima hoor. Daarbuiten werkt git ook uitstekend icm met ssh, een stuk veiliger en handiger als ftp Je wilt niet weten hoeveel bedrijven nog steeds aanklooien met ftp op live servers

Maar wat is het nut van git als je files vervolgens via shares gaat delen om samen te werken? Voor deployment kan ik het nog snappen, maar anders, nee.

BramVanha schreef op vrijdag 27 april 2018 @ 23:45:
Ik ben nog student aan een universiteit en heb mijn student versie van Github kunnen activeren, gratis private repo's dus tot ik afgestudeerd ben

[base_]

Gropah schreef op vrijdag 27 april 2018 @ 23:54:
[...]


Maar wat is het nut van git als je files vervolgens via shares gaat delen om samen te werken? Voor deployment kan ik het nog snappen, maar anders, nee.


[...]

ehm... GIT? je kan de centrale repo gewoon via een fileshare (hub) syncen (push/pull/fetch/merge <repo>?), ik heb het niet over de source/project files!

[ Voor 4% gewijzigd door base_ op 28-04-2018 00:00 ]

[Ramon]

@Gropah Je kan blijkbaar een file share gebruiken als remote in git, zie: https://stackoverflow.com...to-a-shared-network-drive

Nooit gedaan maar zal vast werken, als je dan maar niet als er even iets misgaat met git gewoon via de verkenner bestanden in de remote gaat plaatsen ofzo

[Creepy]

BramVanha schreef op vrijdag 27 april 2018 @ 23:21:
[...]


Dit was een zeer duidelijk antwoord (buiten 1 dingetje), waarvoor dank!
Waarom precies is een versiebeheersysteem dan geen software? Hoort dit hier dan niet onder?

Misschien goed om dat antwoord als beste te markeren? (dat kan alleen jij of een mod)

[base_]

Ramon schreef op zaterdag 28 april 2018 @ 08:36:
@Gropah Je kan blijkbaar een file share gebruiken als remote in git, zie: https://stackoverflow.com...to-a-shared-network-drive

Nooit gedaan maar zal vast werken, als je dan maar niet als er even iets misgaat met git gewoon via de verkenner bestanden in de remote gaat plaatsen ofzo

Als je samen wilt werken moet je je repository syncen, meestal doe je dat via een centrale (bare) repository.

Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols
verder kan je ook fileshares gebruiken als je OS dat ondersteunt, zolang git maar bij de .git map kan komen.

[bwerg]

Sommige universiteiten willen zelf ook nog wel eens gitlab hosten voor hun studenten/medewerkers. Als je voor elk vak weer een nieuwe repository aanmaakt wil je nog wel eens door de X gratis private repo's van github of bitbucket heen raken, dus voor huiswerk kan dat ook een optie zijn. Toegang daartoe ben je na je studie natuurlijk wel vaak kwijt, maar een huiswerk-repo doet daarna waarschijnlijk toch niks meer.

[MSalters]

Gropah schreef op vrijdag 27 april 2018 @ 23:25:
[...]
Het doel van [git] is om bij iedereen de code dezelfde staat te laten hebben op dezelfde momenten en op de verschillende werkplekken/branches. Om dat te doen stuurt het bestanden heen en weer, maar doet het nog veel meer zoals het vinden van wijzigingen in bestanden en die toepassen wanneer ze gevonden worden bij een update.

Stuurt Git bestanden op en neer? Volgens mij is de hele essentie van git dat je aleen maar "diffs" uitwisselt, de verschillen tussen files. Dat is namelijk hoe je met twee man in dezelfde file kunt werken. Als je maar gescheiden diffs hebt, bijvoorbeeld omdat je aan verschillende functies werkt, dan botsen die diffs niet.

Git heeft dan een rebase operatie. Je hebt jouw lokale wijziging klaarstaan, en je haalt de wijziging van de centrale repository op. Vervolgens update Git je lokale wijziging waar mogelijk. Als jij bijvoorbeeld regel 50 had geupdatet, maar iemand anders heeft tussen regel 20 en 21 nog 3 extra regels toegevoegd, dan past Git jouw wijziging automatisch aan om naar regel 53 te verwijzen.