Opțiuni de găzduire a codului dincolo de GitHub

URMĂREȘTE-NE
16,065FaniÎmi place
1,142CititoriConectați-vă

Unele fundal

Oglindirea codului

Oglindire versus migrare

Termenul „oglindire” este folosit aici și în întreaga documentație oficială git, pentru a implica o duplicare a codului, în general din locații locale în locații îndepărtate. „Migrarea” implică mutarea codului dintr-o locație într-o locație nouă. Migrația nu este nici necesară, nici încurajată aici, totuși unele site-uri folosesc totuși acest termen, probabil ca o încurajare implicită de a face exact asta. Oriunde este folosită „migrarea” mai jos, vă rugăm să vă gândiți doar la un proces de „oglindire” în care codul dvs. va rămâne întotdeauna intact și în locația originală.

Actualizarea oglinzilor de cod

Oglinzile de cod sunt actualizate doar prin intermediul git push evenimente din versiuni locale sau din altele git evenimente de pe oglinda primară de la distanță. Evenimentele de modificare care provin de pe telecomanda principală sunt în general încorporate într-o versiune locală prin git pullși apoi împins la toate versiunile în oglindă. O git pull comanda ar trebui să fie aplicată numai la versiunea principală la distanță și niciodată la orice versiune alternativă în oglindă. În această diagramă, săgeata galbenă mare dintre telecomandă primară și locală reprezintă singura conexiune unde sunt ambele push şi pull evenimentele sunt permise. Toate celelalte săgeți sunt push numai evenimente, iar codul nu este niciodată pulled din oglinzi non-primare.

Direcții de interacțiune Git între depozitele locale și la distanță.

Direcții de interacțiune Git între depozitele locale și la distanță.

Oglindirea în Codeberg sau GitLab

Codeberg folosește termenul „migrare” mai degrabă decât oglindire. Folosim același termen în această secțiune, dar rețineți că este într-adevăr doar un proces de „oglindire” și totul poate și ar trebui să rămână intact în locația originală din care „migrați”. Pentru a începe procesul, faceți clic pe butonul mare „+” din partea dreaptă sus a barei de meniu principal și selectați „Migrare nouă”.

Butonul de migrare a noului depozit Codeberg.Butonul de migrare a noului depozit Codeberg.

Butonul de migrare a noului depozit Codeberg.

Aceasta va deschide apoi o grilă de opțiuni de unde doriți să migrați depozitul.

Opțiunile de migrare a depozitului Codeberg afișate ca pictograme, inclusiv Git, GitHub, GitLab, Forgejo, Gitea, Gogs, OneDev și GitBucketOpțiunile de migrare a depozitului Codeberg afișate ca pictograme, inclusiv Git, GitHub, GitLab, Forgejo, Gitea, Gogs, OneDev și GitBucket

Opțiuni de migrare a depozitului Codeberg.

Pe GitLab, butonul echivalent „+” este în stânga sus, unde „Proiect/repozitiv nou” ar trebui făcut clic.

Butonul nou depozit GitLab.Butonul nou depozit GitLab.

Butonul nou depozit GitLab.

Acest lucru va duce la o serie de opțiuni, în care ar trebui să faceți clic pe „Importați proiect”.

Opțiuni de import pentru depozitul GitLab: Creați un proiect gol; Creați din șablon; Proiect de import; Rulați CI/CD pentru depozitul extern.Opțiuni de import pentru depozitul GitLab: Creați un proiect gol; Creați din șablon; Proiect de import; Rulați CI/CD pentru depozitul extern.

Opțiuni de import pentru depozitul GitLab.

O notă despre problemele de transfer

Emigrează în altă parte

Nicio altă platformă nu oferă în prezent funcționalitatea de migrare cu un singur clic a Codeberg sau GitLab. Pentru a migra în toate celelalte cazuri, va trebui să:

  1. Creați un nou depozit pe platforma dorită.
  2. Setați a git remote URL către noua destinație.
  3. git push la noua telecomandă.

Pagina web git remote oferă mai multe detalii despre lucrul cu telecomenzi.

Oglindire: gestionarea unui singur depozit pe mai multe platforme

După cum este descris în prima figură de mai sus, ar trebui luate în considerare toate telecomenzile, altele decât codul dvs. principal „principal”. push doar oglinzi și niciodată pull. În cazul rar în care apar conflicte din alte surse, poate fi necesar git push --force la alte telecomenzi (sau versiunea mai sigură, git push --force-with-lease). N-ar trebui niciodată git push --force la ramura principală a sursei primare.

Adăugarea mai multor telecomenzi

Pentru fiecare sursă suplimentară la distanță, va trebui să adăugați o adresă URL la distanță cu git remote add. Există multe moduri de a face acest lucru.

Modul pur Git de a gestiona mai multe surse la distanță este de a profita git remote set-url --add pentru a adăuga adrese URL suplimentare la un singur identificator de la distanță. Postarea de blog a lui Jeff Kreeftmeijer detaliază cum să faci asta în siguranță, pentru a te asigura că o singură telecomandă principală este configurată pentru fetchîn timp ce permite push evenimente pentru toți ceilalți.

O opțiune alternativă ar fi să creați inițial o telecomandă suplimentară git remote add other https://codeberg.org/ropensci/my-package. Un singur git remote poate fi, de asemenea, atribuit mai multor adrese URL. Prima adresă URL trebuie setată cu git add (sau git set-url) pentru a adăuga sau actualiza adresa URL a unei telecomenzi existente. Ulterior, pot fi adăugate adrese URL suplimentare utilizând git set-url --add urmat de numele telecomenzii. De exemplu, git set-url --add other https://gitlab.com/ropensci/my-package ar specifica apoi atât adresele URL Codeberg, cât și GitLab cu unicul other telecomanda. Funcţionare git push other va împinge apoi acea ramură către ambele adrese URL de la distanță.

Sincronizarea mai multor telecomenzi

Reclamă codul principal de acasă

Indiferent de modul în care structura și modul în care vă distribuiți codul pe mai multe platforme, este în general util să mențineți o singură „acasă” principală. (Desigur, acest lucru nu este deloc necesar; dacă vă place să vă împărțiți atenția pe diferite platforme, vă rugăm să faceți acest lucru și să ignorați această secțiune.) Vă recomandăm să faceți publicitate locației codului dvs. principal în partea de sus a documentului README.md, ceva în sensul acestui exemplu, și să precizați clar dacă veți răspunde sau nu la „probleme” (sau orice alte interacțiuni specifice platformei ar putea fi numite).

Cuvinte de avertizare

    • Accesați depozitul „Setări” pentru a activa versiunile
    • Explicit git push --tags codeberg pentru a împinge toate etichetele Git, deoarece acestea nu sunt incluse implicit în procesul de oglindire Codeberg.
  • De asemenea, GitLab nu oglindește versiunile în mod implicit și nu (în prezent) urmărește automat etichetele așa cum face Codeberg. Pentru a oglindi versiunile pe GitLab, trebuie.

    • git push --tags gitlab la fel ca pe Codeberg, pentru a împinge în mod explicit toate etichetele Git.
    • Parcurgeți manual fiecare etichetă și lansați o nouă lansare, pentru care puteți seta retroactiv datele de lansare să fie aceeași dată istorică ca data originală de lansare GitHub.

Există multe alte moduri, mici și mari, prin care diferitele platforme și sisteme de găzduire a codului diferă unele de altele. Întreținerea continuă pe diferite platforme va prezenta întotdeauna provocări, dar sperăm să vă fi oferit suficiente informații aici pentru a începe.

rOpenSci repos pe Codeberg, GitLab sau în altă parte

Dominic Botezariu
Dominic Botezariuhttps://www.noobz.ro/
Creator de site și redactor-șef.

Cele mai noi știri

Pe același subiect

LĂSAȚI UN MESAJ

Vă rugăm să introduceți comentariul dvs.!
Introduceți aici numele dvs.