Cum migrez un proiect existent la GitHub?
Aici, vom discuta aspectele importante pentru migrarea unui proiect la GitHub de la un sistem de control al versiunii moștenite.
De ce migrați la GitHub?
Există volume de literatură care extolează virtuțile GitHub. Este dincolo de domeniul acestui modul pentru a vă convinge să mutați. Dar putem recapitula unele dintre avantajele cheie în contextul subiectelor pe care trebuie să le luați în considerare atunci când planificați migrarea.
Controlul versiunii
GitHub utilizează exclusiv Git, probabil cel mai bun sistem de control al versiunilor din jurul său. Totuși, Git este incredibil de sofisticat și poate prezenta unele scenarii complexe pentru lucrul cu cod cu care este posibil ca echipa dvs. să nu fie experimentată. Ramurile și solicitările de tragere sunt o parte fundamentală a vieții de zi cu zi pentru dezvoltatorii care utilizează Git, prin urmare, înțelegerea când și cum să le utilizați eficient este necesară pentru a avea succes pe GitHub. Este util ca echipa dvs. să se familiarizeze mai întâi cu fluxul GitHub, astfel încât să puteți ajunge la rularea terenului.
Păstrați codul în cloud
Un volum mare de cod de proiect este stocat încă în sistemele de control al versiunilor moștenite din spatele firewallurilor de corporație. Atunci când migrați la GitHub, mutați codul pe platforma cloud GitHub, unde membrii echipei îl pot accesa cu ușurință de oriunde. Această migrare oferă o oportunitate bună de a revizui politica echipei dvs. pentru tipurile de fișiere și date pe care le păstrați în controlul versiunilor. Ca exemplu de bună practică, ar trebui să presupuneți că tot ce comiteți la GitHub este compromis. Nu uitați să includeți date sensibile, cum ar fi chei API, parole sau alte fișiere care conțin informații comparabile.
Notă
GitHub oferă atât depozite publice, cât și private, precum și controale granulare de acces pentru diferite părți ale unui depozit. Acest lucru vă permite să controlați cui sunt vizibile proiectele dvs., precum și ce acțiuni poate efectua un anumit utilizator.
Colaborare
GitHub oferă asistență excelentă pentru colaborarea în echipă prin caracteristici precum probleme, solicitări de tragere și recenzii de cod. Cu toate acestea, fluxul GitHub poate diferi de practicile la care este obișnuit în prezent echipa dvs. Este o idee bună să luați în considerare dacă echipa intenționează să se adapteze la GitHub, să își păstreze procesul dat sau să se întâlnească undeva în mijloc înainte de a finaliza migrarea.
Dacă proiectul dvs. este un proiect open-source care permite colaboratori externi, nu există nicio opțiune mai bună decât GitHub pentru maximizarea beneficiilor.
Migrarea la GitHub
Considerații de planificare
Cel mai important aspect înainte de a executa migrarea la GitHub este dacă trebuie să păstrați orice dincolo de starea curentă a sursei. Dacă sunteți mulțumit de începerea unui proiect nou doar cu sursa curentă as-is, cea mai bună opțiune este să o tratați ca pe un proiect nou și să încărcați sursa în depozit.
Totuși, dacă doriți să păstrați istoricul de control al versiunilor, trebuie să importați utilizând instrumentul de migrare GitHub GitHub. Pentru mai multe informații despre suportul de import pentru diferite platforme de control al versiunilor, consultați Importul datelor din sisteme de control ale versiunilor terțe.
Dincolo de datele Git, se recomandă, de asemenea, să păstrați problemele, solicitările de extragere sau alte date. Asistența pentru aceste elemente variază în funcție de platformă și este disponibilă în general de la proiectele de comunitate. Acest modul nu acoperă migrarea datelor non-Git.
Gestionarea fișierelor binare stocate în prezent în proiect
Ca un exemplu de bună practică, depozitele de GitHub ar trebui să fie limitate la fișierele necesare pentru construirea proiectelor. Evitați comiterea fișierelor binare mari, cum ar fi artefactele de compilare. Fișierele binare, cum ar fi foile de calcul și prezentările, sunt mai potrivite pentru a fi urmărite pe portaluri care înțeleg cum să le servească și să le versiuniz corect. Dacă trebuie să versiunile de fișiere binare mari, luați în considerare utilizarea extensiei Git LFS (Stocare fișiere mari) Git.
Crearea fișierelor Git importante, cum ar fi .gitignore
Git acceptă fișiere .gitignore pentru a impune politici de fișier de control al versiunilor. Aceste fișiere definesc modelele de căutare utilizate pentru a exclude fișierele și folderele din urmărirea controlului sursă. Următorul exemplu simplu exclude recursiv orice foldere denumite Bin sau bin și conținutul lor din urmărirea controlului sursă:
[Bb]in/
Puteți afla mai multe despre Ignorarea fișierelor. De asemenea, puteți consulta colecția de fișiere starter .gitignore oferite pentru diverse platforme în depozitul gitignore.
Există mai multe alte fișiere utilizate frecvent în proiectele GitHub pentru a explica politici diferite consumatorilor și colaboratorilor depozitului. Chiar dacă proiectul dvs. este privat și restricționat la un public limitat, poate fi util să rostiți în mod explicit aceste politici. Deși niciunul dintre aceste fișiere nu este necesar, am listat câteva dintre cele comune aici.
| Fișier | Scop |
|---|---|
README.md |
Pagina de destinație pentru director. Această pagină este redată atunci când directorul său este vizualizat pe GitHub. |
LICENSE.md |
Licența furnizată de cod. |
CONTRIBUTING.md |
Explică modul în care utilizatorii ar trebui să contribuie la proiect, cum ar fi așteptările la solicitări de extragere. |
SECURITY.md |
Explică politica de securitate pentru proiect. Oferă instrucțiuni utilizatorilor care doresc să trimită cod de securitate sensibil sau feedback care nu ar trebui dezvăluit public înainte de a fi adresat. |
Aflați mai multe despre Configurarea proiectului pentru contribuții sănătoase.
Importul proiectului în GitHub
După ce vă pregătiți depozitul pentru migrare, navigați la fila cod a depozitului GitHub. Utilizați opțiunea Import cod pentru a specifica depozitul sursă.
Instrumentul de migrare GitHub se ocupă de restul.
