Ik zou graag willen dat iemand me meer details kan geven over het werken met git en externe repositories. Ik heb nog niet met externe opslagplaatsen gewerkt.
Naar de lokale repository voert u kleinere wijzigingen door die misschien niet al te wereldschokkend zijn. Wat wordt naar de externe repository gepusht? Elke lokale inzet? Of het totale werk dat gedaan is, dat vervolgens wordt samengevoegd met het algehele werk van anderen? Ik denk dat het logboek van de externe repository verwarrend moet zijn, als iedereen elke commit pusht.
Antwoord 1, autoriteit 100%
Pushen en pullen vanuit de externe repository is niet zo belangrijk als je lokale commits. Meestal is een paar keer per dag duwen en trekken voldoende. Zoals @earlonrails al zei, betekent vaker pushen minder kans op tegenstrijdige wijzigingen, maar meestal is het niet zo’n groot probleem.
Zie het op deze manier, door je te committeren aan je lokale repository, zeg je in feite “Ik vertrouw deze code. Het is compleet. Het werkt. Ik heb het getest. Ik ben klaar voor andere mensen om het te zien.” Als je na elke commit naar de externe repository wilt pushen, is dat prima, maar zolang je het regelmatig doet, maakt het niet echt uit.
Lokale opslagplaatsen gaan over het bijhouden van uw wijzigingen om het werk dat u doet te beschermen. Externe opslagplaatsen zijn bedoeld om het werk naar al uw teamgenoten te distribueren en om ieders wijzigingen bij te houden. Je teamgenoten hebben toegang tot je code nodig, maar meestal is dit niet urgent en kan het wachten tot het einde van de dag of wanneer je maar wilt.
Antwoord 2, autoriteit 33%
U kunt op uw gemak naar de afstandsbediening pushen. Het enige probleem met het pushen van een heleboel commits tegelijk is dat je misschien meer conflicten moet samenvoegen met meer aangetaste bestanden. Als git nieuw voor je is, raad ik git readyaan.
Afstandsbedieningen werken net als de lokale repo, maar je moet aardig met anderen spelen. Als andere mensen naar de afstandsbediening duwen voordat u drukt. Dan zullen hun wijzigingen door jou moeten worden getrokken voordat je kunt pushen. Als u allebei hetzelfde bestand aanraakt, moet u de twee wijzigingen samenvoegen, aangezien hun wijziging als eerste werd ingevoerd.
Antwoord 3, autoriteit 14%
Ik probeer elke lokale commit zo mogelijk te pushen (ik gebruik Git). Zelden heb ik 2 of meer commits lokaal. Anders bestaat er een risico op conflicten die niet zo prettig zijn om op te lossen.
Ik gebruik liever rebase dan samenvoegen, om de geschiedenis meer lineair te houden. Als ik 2 commits A en B (B is ouder) lokaal heb, en B conflicteert met aanstaande wijzigingen, moet ik na het oplossen van conflicten op rebase B uitchecken, compilatie controleren, misschien tests uitvoeren en pas dan overschakelen naar A en dat allemaal pushen .
Daarom geef ik er de voorkeur aan om alles wat ik heb zo snel mogelijk te pushen. Merk op dat deze problemen zich meestal voordoen bij het omgaan met grote codebases met verschillende andere mensen.
Antwoord 4, autoriteit 5%
Ik ben het over het algemeen niet eens met het beste antwoord en enkele opmerkingen. Noch commits noch push hoeft verantwoordelijk te zijn voor de kwaliteit van de code.
In het svn-tijdperk werkt iedereen in dezelfde branche. Een fout in uw code verspreidt zich snel naar anderen. In dit geval moet je zeker de kwaliteit van de code garanderen, en dat is de reden waarom svn in veel bedrijven en organisaties wordt vervangen door git.
We moeten duidelijk maken wat een typische Git-workflow is. Stel dat je master branch een op de een of andere manier werkbare versie van de software heeft. Sommige mensen geven er de voorkeur aan om de master-branch als release-branch te gebruiken, terwijl anderen het als de development-branch gebruiken. Het geeft niet. Telkens wanneer u een functie moet toevoegen of een bug moet repareren, maakt u een vertakking van de hoofdvertakking (of een andere) vertakking. De functie moet klein genoeg zijn om te worden afgehandeld zonder uitgebreide wijziging van de codebase. Bij grote modificaties moeten er lagen takken worden gemaakt, zodat de laatste laag van de tak klein genoeg is.
Als elke vertakking een kleine functie moet toevoegen, is het niet erg waarschijnlijk dat er veel mensen in dezelfde vertakking werken. Als meer dan één persoon aan één functie werkt, moet die groep erg klein zijn en heel vaak communiceren, en daarom moeten conflicten gemakkelijk worden opgelost. Als een commit of een push een probleem heeft, zal alleen jij of je kleine team een probleem hebben.
Dan moeten we de kwaliteit van de code garanderen. Mijn antwoord is de pull-requests. In Github pas je de code aan en dien je een pull request in. Tegen de tijd dat u het pull-verzoek indient, moet u garanderen dat uw code kan compileren en de tests doorstaat. In Gitlab maak je een merge request aan voordat je de code aanpast, maar markeer je met WIP (work in progress). Dan pas je de code aan. Voordat u het WIP-teken verwijdert, moet u ervoor zorgen dat uw code van goede kwaliteit is. Ook zal de code reviewer een extra beschermingslaag zijn.
Conflicten zouden zelden voorkomen in je branch, maar het kan gebeuren als je je branch merget met de basis branch. Je moet het oplossen vlak voordat die samenvoeging plaatsvindt.
Het enige dat te maken heeft met rebase. Veel ontwikkelaars vinden het leuk om hun branch te rebasen voordat ze een merge conflict indienen om de git commit geschiedenis er beter uit te laten zien. Als je naar de afstandsbediening hebt gepusht en anderen je code hebben gebruikt, veroorzaakt rebase vervelende problemen om op te lossen. Als je echter altijd aan een branch werkt die slechts een kleine functie verhelpt, zou niemand je branch toch moeten willen gebruiken. Ook houd ik persoonlijk niet zo van rebasen omdat het de geschiedenis wijzigt.
Dus mijn conclusie is vergelijkbaar met die van anderen, leg je vaak vast en push vaak, maar om een andere reden.