Configuraties synchroniseren tussen meerdere pc's met behulp van Git.

Gelijktijdig werken met meerdere computers Het is volkomen normaal geworden: een krachtige desktopcomputer thuis, een laptop voor onderweg, misschien zelfs een derde computer op kantoor. Het probleem ontstaat wanneer je dezelfde configuratie, dezelfde projecten en dezelfde codeversie op al deze apparaten wilt behouden zonder gek te worden van het kopiëren van mappen met een USB-stick of het mailen van zipbestanden naar jezelf.

Als deze situatie u bekend voorkomt Een desktop-pc hebben waarop je naar eigen wens kunt programmeren.Als je een nieuwe laptop wilt kopen om aan dezelfde projecten te blijven werken en niet weet hoe je alles moet synchroniseren, dan zijn Git en GitHub (of andere platforms voor werken op afstand) precies wat je nodig hebt. Het idee is simpel: een centrale repository in de cloud waar al je teams verbinding mee kunnen maken om wijzigingen te uploaden en downloaden, zodat zowel de code als bepaalde configuraties op elkaar afgestemd blijven.

Wat houdt het in om configuraties en code tussen meerdere pc's te synchroniseren met Git?

Wanneer we het hebben over "het synchroniseren van configuratie en code" tussen uw desktopcomputer en uw laptop (of tussen Windows en macOS), hebben we het eigenlijk over twee verschillende, maar verwante dingen: enerzijds je projectbestanden (code, resources, documentatie) en anderzijds de configuratie die je gebruikt om te werken (editorinstellingen, templates, scripts, dotfiles, enz.).

Git is voornamelijk bedoeld voor versiebeheer en het delen van de broncodeMaar met een beetje organisatie kun je het ook gebruiken om bepaalde configuraties tussen machines te repliceren, zolang het maar bestanden zijn binnen een projectmap of specifieke configuratieopslagplaatsen (bijvoorbeeld een dotfiles-repository met je instellingen). terminal, alias, enz.).

In een typisch scenario heb je thuis een desktop-pc met je IDE, projecten en repositories al ingesteld, en wil je dat je werklaptop over dezelfde functionaliteit beschikt. exact dezelfde repositoriesmet dezelfde hoofdbranch en dezelfde wijzigingen. Op deze manier kun je code in beide repositories bewerken, committen en synchroniseren via GitHub of een andere remote repository.

Het is ook gebruikelijk om je af te vragen of je het wel moet gebruiken. dezelfde gebruiker en e-mailadres Git is op alle machines geconfigureerd. Om ervoor te zorgen dat GitHub je commits correct aan je account koppelt, moet het e-mailadres dat je op elke machine configureert, overeenkomen met het e-mailadres dat in je GitHub-profiel is geregistreerd. De naam kan variëren, maar het e-mailadres is essentieel om alles aan jou te koppelen.

Kortom, het doel is dat u uw project op uw desktop kunt openen, sluiten, verder kunt programmeren op uw laptop, en dat uw hoofdcomputer bij terugkomst de wijzigingen zonder conflicten overneemt, waarbij altijd de wijzigingen behouden blijven. een enkele “bron van waarheid” van de code op afstand.

Configureer Git correct op elk apparaat.

Voordat je begint met het klonen van repositories en het maken van commitsHet is essentieel dat Git correct is geconfigureerd op alle machines waarop u gaat werken. Dit omvat het installeren van Git, het instellen van uw gebruikersnaam en e-mailadres en, als u GitHub gebruikt, ervoor zorgen dat uw identiteit consistent is en uw inloggegevens probleemloos werken.

Het eerste is Installeer Git op elk besturingssysteem.Na de installatie opent u de console (Terminal op macOS of Linux, PowerShell of Git Bash op Windows) en configureer je gebruikersgegevens met deze commando's:

git config –global user.name “Uw naam”
git config –global user.email “your-email@example.com”

Wat echt belangrijk is, is dat Het e-mailadres moet hetzelfde zijn als het adres dat je op GitHub gebruikt.Omdat GitHub die naam gebruikt om je commits aan je account te koppelen. De naam is flexibeler: je zou zelfs verschillende namen voor elk team kunnen kiezen, hoewel dat in de praktijk niet veel zin heeft als je de enige bent die aan het project werkt. Het is verstandiger om altijd dezelfde naam te gebruiken, zodat de geschiedenis er overzichtelijk en consistent uitziet.

Mocht u ooit twijfels hebben over uw configuratie, dan kunt u het volgende uitvoeren:

git config –lijst

Met dit commando krijg je een lijst te zien met je gebruikersnaam, e-mailadres en andere globale en lokale opties. Als je iets onjuist ziet (bijvoorbeeld een e-mailadres met een typefout), kun je dat aangeven. Herhaal de voorgaande opdrachten. om het te corrigeren. Het is een goed idee om dit op al je apparaten te controleren, vooral wanneer je een nieuwe laptop krijgt.

Daarnaast is er de Git-console. Het werkt vrijwel hetzelfde op Windows, macOS en Linux.Dit betekent dat de commando's die je op je Windows-desktop leert, ook werken als je macOS of een Linux-distributie op je laptop hebt. Het belangrijkste is dat je vertrouwd raakt met de basisworkflow (toevoegen, committen, pushen, pullen) en je configuratie consistent houdt.

Hoe deel ik dezelfde repository tussen een desktop en een laptop?

Als je het project al op je desktop-pc hebt aangemaakt En je hebt het geüpload naar GitHub; het enige wat je nu nog moet doen, is je laptop aansluiten zodat die met dezelfde repository kan werken. Veel mensen lopen vast na de eerste push naar de externe repository, omdat ze niet begrijpen hoe ze vanaf een andere machine verder moeten.

Het idee is heel simpel: op de laptop ga je geen nieuwe repository aanmaken, maar in plaats daarvan ga je... kloon de versie die al op GitHub bestaatHierdoor wordt een volledige kopie van de geschiedenis en bestanden op uw tweede computer gemaakt, waarbij de externe verbinding al is geconfigureerd.

Ga op je laptop naar de map waar je het project wilt opslaan en voer het volgende commando uit:

git clone https://github.com/tu-usuario/tu-repo.git

Na dat commando heb je een map. jouw-repo met de code en de volledige geschiedenis. Vanaf daar zal de workflow voor beide teams hetzelfde zijn: jij brengt wijzigingen aan, jij gebruikt git add om bestanden te selecteren, Git commit om de wijzigingen vast te leggen en git push om ze naar de externe server te sturen. Op de andere computer voert u het volgende commando uit: git pull om die nieuwe commits binnen te halen.

Als je nieuw bent met Git, is het normaal dat je in het begin in de war raakt over het verschil tussen klonen, ophalen en pushen. Houd er rekening mee dat `git clone` wordt slechts één keer per machine uitgevoerd.Wanneer je de repository voor het eerst wilt ophalen, gebruik je `pull` om wijzigingen te downloaden en `push` om je eigen wijzigingen te uploaden. Vanaf dat moment gebruik je, elke keer dat je wilt synchroniseren, `pull` om wijzigingen te downloaden en `push` om je eigen wijzigingen te uploaden.

Werk samen met meerdere teams zonder je eigen werk te verwaarlozen.

Een van de meest voorkomende angsten bij het gebruik van meerdere pc's Het gaat om de mogelijkheid dat je per ongeluk je werk overschrijft. Het goede nieuws is dat Git specifiek is ontworpen om dit soort rampen te voorkomen, mits je een paar basisregels volgt en er een gewoonte van maakt om duidelijke commits te maken.

Over het algemeen is het verstandig om, voordat je begint met programmeren op je computer, eerst een test uit te voeren. git pull in de branch waaraan je gaat werken. Dit zorgt ervoor dat je de nieuwste versie van de remote repository hebt en minimaliseert conflicten. Programmeer vervolgens zoals gebruikelijk, voeg de gewijzigde bestanden toe en commit met een beschrijvend bericht.

Het wordt ten zeerste aanbevolen dat Je commitberichten moeten duidelijk uitleggen wat je hebt gewijzigd.Stel je voor dat je over twee weken probeert te begrijpen waarom je iets hebt gedaan. Berichten zoals "diverse wijzigingen" of "kleine dingen" helpen niemand. Voeg informatie toe zoals "verhelpt een bug bij het compileren op Windows" of "voegt automatische synchronisatie tussen computers toe".

Als je thuis klaar bent met werken, doe je dat... git push om de commits te uploaden. Als je op je werk aankomt, zet je je laptop aan en doe je dat. git pull En vanaf dat punt ga je gewoon verder. Het omgekeerde proces is precies hetzelfde: je werkt op je laptop, je voert de push-bewerking uit, en thuis voer je de pull-bewerking uit voordat je verdergaat.

Wat betreft conflicten: die ontstaan ​​wanneer je dezelfde regels in een bestand op twee verschillende plaatsen wijzigt zonder tussendoor te synchroniseren. Git zal je waarschuwen en je vragen het conflict handmatig op te lossen. Het is geen groot probleem, maar hoe beter je eraan gewend raakt, hoe beter. Synchroniseer vóór het starten en na afloop.Het zal je minder vaak overkomen.

Sommige mensen overwegen om op elk apparaat een andere gebruikersnaam te gebruiken om te "weten welke pc elke commit heeft gedaan". Technisch gezien kan dit, maar in de praktijk is het meestal meer een belemmering dan een hulp. Als je alles zelf doet, gebruik je normaal gesproken... overal dezelfde naam en dat de details van het apparaat niet echt van belang zijn voor het project.

Bijna realtime synchronisatie: is het mogelijk om zoveel handmatig push/pull-verkeer te vermijden?

Wanneer je gewend raakt aan het werken in twee heel verschillende systemen.bijvoorbeeld het ontwikkelen van code in een Mac Maar bij het compileren en testen van het spel op een Windows-pc kan het vervelend worden om constant handmatig aan de ene kant te moeten duwen en aan de andere kant te moeten trekken.

Git zelf is ontworpen voor een expliciete synchronisatieDat wil zeggen, je moet de commando's zelf aanroepen. Het werkt niet zoals een Dropbox-map die automatisch wordt bijgewerkt wanneer je een wijziging opslaat. Er zijn echter wel Tricks en tools die je dichter bij iets vergelijkbaars als live synchronisatie kunnen brengen.

Een optie die veel ontwikkelaars overwegen, is het gebruik van diensten van opslagruimte in de cloud (Drive, Dropbox, OneDrive) om de map waarin de repository zich bevindt direct te synchroniseren. Dit kan werken, maar Het is niet de meest aan te radenomdat die services de interne logica van Git niet begrijpen en in bepaalde gevallen de repository kunnen beschadigen als er gelijktijdig wijzigingen of bestanden in gebruik zijn.

Als je van plan bent om op een Mac te programmeren terwijl de game alleen op Windows draait, kun je de hoofdrepository op je pc hebben en Git gebruiken als een soort "brug" tussen de machines. Je commit op de Mac, pusht naar een externe repository (bijvoorbeeld GitHub of een privérepository op je lokale netwerk) en op de pc automatiseer je het pullen op een of andere manier, bijvoorbeeld met een script die periodiek wordt uitgevoerd of met een geplande taak die controleert op nieuwe wijzigingen.

Je kunt bijvoorbeeld in Windows een script maken dat elke paar minuten het volgende uitvoert:

git ophalen oorsprong
git pull origin main

Op die manier wordt elke keer dat je je wijzigingen op de Mac opslaat, vastlegt en pusht, de bewerking op de pc voltooid. De nieuwste versie wordt automatisch gedownload. Na een korte pauze. Het is niet zo direct als een magische map die zichzelf bijwerkt, maar het komt aardig in de buurt en voorkomt de "herhaalde hoofdpijn" van het constant openen van de pc-console om de branch op te halen.

Onthoud in ieder geval dat Git heeft nog steeds consistente commits nodig.Zelfs als je een deel van het synchronisatieproces automatiseert, is het verstandig om de discipline te behouden om logische wijzigingen in elke commit te groeperen en de geschiedenis van tijd tot tijd te controleren om er zeker van te zijn dat alles klopt.

Alleen het werkteam synchroniseren versus organisaties en teams synchroniseren op GitHub.

Tot nu toe hebben we ons gericht op het individuele gebruik van Git.Dat wil zeggen, jij met je computers en je persoonlijke projecten. Maar GitHub biedt een andere vorm van "synchronisatie" die, hoewel de naam vergelijkbaar is, is ontworpen voor grotere organisaties, bedrijven en teams: teamsynchronisatie met groepen van een identiteitsprovider (IdP).

Wanneer teamsynchronisatie is ingeschakeld in een GitHub-organisatie, is het mogelijk om een ​​GitHub-team te koppelen aan een gebruikersgroep gedefinieerd in uw IdP (bijvoorbeeld Azure AD, Okta, enz.). Zodra die verbinding tot stand is gebracht, wordt elke wijziging in het lidmaatschap van die IdP-groep automatisch doorgevoerd in GitHub: als een gebruiker zich bij de groep in de IdP aansluit of deze verlaat, wordt deze toegevoegd aan of verwijderd uit het corresponderende team in GitHub.

Dit vermindert de noodzaak om de teamledenlijst op GitHub handmatig bij te werken of aangepaste scripts te onderhouden om die taak te automatiseren. Je kunt zelfs Dezelfde IdP-groep toewijzen aan meerdere GitHub-teamsDit is erg handig als je dezelfde ontwikkelaars deelt over verschillende repositories of onderdelen van een project.

Zodra je een GitHub-team koppelt aan een identiteitsprovidergroep, moet het toevoegen en verwijderen van teamleden uitsluitend via de identiteitsprovider gebeuren. Dit betekent dat je teamlidmaatschappen niet langer handmatig rechtstreeks in GitHub kunt beheren; alle wijzigingen moeten via het centrale identiteitssysteem verlopen.

Er moet echter rekening worden gehouden met een aantal beperkingen. Bijvoorbeeld: Ouderteams kunnen niet rechtstreeks synchroniseren met IdP-groepen.Als het team waarin je geïnteresseerd bent is ingesteld als een ouderteam binnen de GitHub-hiërarchie, moet je ofwel een nieuw team aanmaken zonder geneste relaties, ofwel die hiërarchie reorganiseren om de ouderstatus te verwijderen voordat je het aan de IdP kunt koppelen.

Een ander belangrijk punt is dat deze teamsynchronisatie niet automatisch teams in GitHub aanmaakt wanneer groepen in de IdP worden aangemaakt, zelfs niet als SCIM-provisioning is geconfigureerd. Om de verbinding te laten werken, moet het team... bestaan ​​in eerste instantie binnen de GitHub-organisatieVervolgens koppel je het aan de groep. Hoewel het toevoegen en verwijderen van leden wordt beheerd door de identiteitsprovider, wordt de toegang van die teams tot elke repository (lezen, schrijven, beheerdersrechten, enz.) nog steeds geconfigureerd via GitHub.

Kortom: deze synchronisatiefunctie is fantastisch voor middelgrote of grote organisaties Met veel gebruikers wil je niet voor elke gebruiker afzonderlijk bijhouden wie bij welk team hoort. Maar het is heel anders dan het synchroniseren van code en configuratie tussen je eigen pc's; het zijn complementaire synchronisatielagen, maar gericht op verschillende behoeften.

Praktische stappen om aan hetzelfde project te kunnen werken op zowel desktop als laptop.

Als je helemaal nieuw bent met Git En als je net een tutorial hebt gevolgd waarbij je de repository op je desktopcomputer hebt aangemaakt, je eerste commit hebt gedaan en deze naar GitHub hebt geüpload, is het normaal dat je niet weet wat je vervolgens moet doen om hetzelfde project op je laptop te hebben.

De algemene volgorde die je moet volgen is ongeveer als volgt: op je desktop-pc maak je het project aan (of converteer je het naar een repository met git init), voer je je eerste wijzigingen door, voeg je ze toe, commit je de wijzigingen en maak je vervolgens verbinding met GitHub (met git remote add origin) en je pusht naar de hoofdbranch. Dit is meestal het punt waar veel tutorials voor beginners eindigen.

Zoals we eerder hebben gezien, kunt u op uw laptop eenvoudigweg Kloon de repository van GitHub. Met behulp van `git clone`. Vanaf dat moment delen zowel de desktop-pc als de laptop dezelfde remote repository en dezelfde main branch. De rest is een kwestie van discipline: vóór het werken doe je een pull, na het werken een push.

Als je al andere alternatieven hebt geprobeerd (zonder echt te weten welk systeem je moest kiezen) en je een mix hebt van mappen, handmatige back-ups en cloudservices, ben je misschien in de problemen gekomen. De beste strategie is meestal om... kies één centrale oplossing (bijvoorbeeld GitHub met Git) en ruim de rest van de geïmproviseerde methoden op om te voorkomen dat verschillende versies van hetzelfde project op verschillende plaatsen door elkaar raken.

Als individuele ontwikkelaar kun je perfect op meerdere computers werken met behulp van Git en een gratis externe provider. Gratis abonnementen Voor zowel privé- als openbare repositories zijn diverse diensten beschikbaar, die meer dan voldoende bieden voor een individuele ontwikkelaar. Wat ze onderscheidt, is het gemak waarmee ze met je tools kunnen worden geïntegreerd, de webinterface van je voorkeur en eventuele extra functies (issues, CI/CD, enz.), maar ze vervullen allemaal de rol van een externe repository voor het synchroniseren van je teams.

Houd er ook rekening mee dat je geen grafische interface hoeft te gebruiken als je de console verkiest, hoewel veel moderne IDE's (zoals Visual Studio, VS Code, IntelliJ, enz.) ingebouwde ondersteuning voor Git hebben. In het geval van Visual Studio 2022 op Windows kun je bijvoorbeeld... Voer commits, pushes en pulls rechtstreeks vanuit de IDE uit.Dit maakt het proces minder omslachtig als je niet steeds naar de terminal wilt overschakelen.

Uiteindelijk komt het erop neer dat je het concept begrijpt: De afstandsbediening fungeert als centraal punt. waar de wijzigingen die je op je verschillende computers aanbrengt, samenkomen. Zolang je die workflow respecteert (pullen voordat je begint, pushen wanneer je klaar bent, commitberichten duidelijk weergeven), kun je met een gerust hart van de ene naar de andere machine overstappen, wetende dat je altijd de nieuwste versie gebruikt.

Met dit alles wordt het synchroniseren van configuraties en code tussen meerdere pc's met behulp van Git een stuk eenvoudiger: Je configureert je gebruiker correct op elke machine.Je gebruikt een vertrouwde remote als de kern van je werk, je beslist of je een handmatige of geautomatiseerde workflow wilt voor het ophalen van gegevens, en als je in een organisatie werkt, vertrouw je op teamsynchronisatie met de IdP om de toegang centraal te beheren. Zodra je deze pijlers hebt geïnternaliseerd, is overschakelen van desktop naar laptop of van Windows naar Mac geen probleem meer, maar een kwestie van committen, pushen en verder werken waar je gebleven was.