Hvordan overfører jeg et eksisterende projekt til GitHub?
Her diskuterer vi de vigtige overvejelser i forbindelse med overførsel af et projekt til GitHub fra et ældre versionskontrolsystem.
Hvorfor migrere til GitHub?
Der er mængder litteratur, der fortæller om GitHubs dyder. Det ligger uden for dette moduls område for at overbevise dig om at flytte. Men vi kan opsummere nogle af de vigtigste fordele i forbindelse med emner, du skal overveje, når du planlægger din migrering.
Versionsstyring
GitHub bruger udelukkende Git, som nok er det bedste versionskontrolsystem. Git er dog utroligt sofistikeret og kan præsentere nogle komplekse scenarier til at arbejde med kode, som dit team muligvis ikke oplever. Branches og pullanmodninger er en grundlæggende del af det daglige liv for udviklere, der bruger Git, så det er nødvendigt at forstå, hvornår og hvordan de kan bruges effektivt, for at få succes på GitHub. Det er værd for dit team først at blive fortrolig med GitHub-flowet, så du kan komme i gang.
Hold din kode i cloudmiljøet
En stor mængde projektkode gemmes stadig i ældre versionsstyringssystemer bag virksomhedens firewalls. Når du migrerer til GitHub, flytter du din kode til GitHubs cloudplatform, hvor teammedlemmer nemt kan få adgang til den overalt. Denne migrering giver dig en god mulighed for at gennemse dit teams politik for de typer filer og data, du bevarer i versionsstyringen. Som bedste praksis bør du antage, at alt, hvad du forpligter dig til GitHub, er kompromitteret. Sørg for ikke at inkludere følsomme data, f.eks. API-nøgler, adgangskoder eller andre filer, der indeholder sammenlignelige oplysninger.
Seddel
GitHub tilbyder både offentlige og private lagre samt detaljeret adgangskontrol for forskellige dele af et lager. Dette giver dig mulighed for at styre, hvem dine projekter er synlige for, samt hvilke handlinger en given bruger kan udføre.
Samarbejde
GitHub tilbyder fremragende support til teamsamarbejde via funktioner som problemer, pullanmodninger og kodeanmeldelser. GitHub-flowet kan dog afvige fra de fremgangsmåder, som dit team i øjeblikket er vant til. Det er en god idé at overveje, om teamet planlægger at tilpasse sig GitHub, bevare den givne proces eller mødes et sted i midten, før du fuldfører migreringen.
Hvis dit projekt er et projekt med åben kildekode, der tillader eksterne bidragydere, er der ingen bedre mulighed end GitHub for at maksimere fordelene.
Migrering til GitHub
Overvejelser i forbindelse med planlægning
Den vigtigste overvejelse, før du udfører din migrering til GitHub, er, om du skal bevare noget ud over din kildes aktuelle tilstand. Hvis du er tilfreds med at starte et nyt projekt med kun din aktuelle kilde as-is, er din bedste mulighed at behandle det som et nyt projekt og uploade kilden til dit lager.
Men hvis du vil bevare versionskontrolhistorikken, skal du importere ved hjælp af værktøjet GitHub Migrator. Du kan få flere oplysninger om importunderstøttelse af forskellige versionsstyringsplatforme i Importér data fra tredjepartsversionskontrolsystemer.
Ud over Git-data kan det også være en god idé at bevare problemer, pullanmodninger eller andre data. Support til disse elementer varierer efter platform og er generelt tilgængelig fra communityprojekter. Dette modul dækker ikke overførsel af ikke-Git-data.
Håndtering af binære filer, der i øjeblikket er gemt i projektet
Som bedste praksis bør GitHub-lagre begrænses til de filer, der er nødvendige for at bygge projekter. Undgå at oprette store binære filer, f.eks. buildartefakter. Binære filer som regneark og præsentationer er bedre egnet til at blive sporet på portaler, der forstår, hvordan de skal betjenes og versioneres korrekt. Hvis du har brug for at versionere store binære filer, kan du overveje at bruge git-udvidelsen Git LFS (Large File Storage).
Oprettelse af vigtige Git-filer som .gitignore
Git understøtter .gitignore filer for at gennemtvinge filpolitikker for versionsstyring. Disse filer definerer de søgemønstre, der bruges til at udelade filer og mapper fra sporing af kildekontrol. Følgende enkle eksempel udelukker rekursivt mapper, der kaldes Bin eller bin, og deres indhold, fra sporing af kildekontrol:
[Bb]in/
Du kan få mere at vide om Ignorere filer. Du kan også tjekke samlingen af starter .gitignore filer, der tilbydes til forskellige platforme i gitignore lager.
Der er flere andre filer, der ofte bruges i GitHub-projekter til at forklare forskellige politikker for lagerforbrugere og bidragydere. Selvom dit projekt er privat og begrænset til en begrænset målgruppe, kan det stadig være nyttigt at formulere disse politikker eksplicit. Selvom ingen af disse filer er påkrævet, har vi angivet nogle af de almindelige her.
| Fil | Formål |
|---|---|
README.md |
Landingssiden for mappen. Denne side gengives, når dens mappe vises på GitHub. |
LICENSE.md |
Den licens, som koden er angivet under. |
CONTRIBUTING.md |
Forklarer, hvordan brugerne skal bidrage til projektet, f.eks. forventninger til pullanmodninger. |
SECURITY.md |
Forklarer projektets sikkerhedspolitik. Indeholder en vejledning til brugere, der ønsker at indsende følsom sikkerhedsrelateret kode eller feedback, som ikke bør offentliggøres, før de bliver behandlet. |
Få mere at vide om Konfiguration af dit projekt til sunde bidrag.
Importerer dit projekt til GitHub
Når du har forberedt dit lager til migrering, skal du gå til fanen Code i dit GitHub-lager. Brug indstillingen Importkode til at angive kildelageret.
Værktøjet GitHub Migrator tager sig af resten.
