Rebasarea ramurilor la distanță în Git (Programare, Git, Controlul Versiunilor, Ramură, Rebase, Ramură De Caracteristici)

kfb a intrebat.

Folosesc un depozit Git intermediar pentru a oglindi un depozit SVN la distanță, din care oamenii pot clona și lucra. Depozitul intermediar are ramura principală rebasată în fiecare noapte de la SVN-ul din amonte, iar noi lucrăm pe ramuri de caracteristici. De exemplu:

remote:
  master

local:
  master
  feature

Pot să împing cu succes ramura mea de funcționalitate înapoi la distanță și să obțin ceea ce mă aștept:

remote:
  master
  feature

local:
  master
  feature

Apoi, reamenajez ramura pentru a urmări la distanță:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

Și totul este în regulă. Ceea ce aș vrea să fac de aici este să repoziționez ramura de caracteristici în ramura principală de pe telecomandă, dar aș vrea să fac acest lucru de pe mașina mea locală. Aș vrea să pot face următoarele:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Să mențin ramura de caracteristici de la distanță la zi cu masterul de la distanță. Cu toate acestea, această metodă face ca Git să se plângă:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull face treaba, dar cauzează o confirmare de fuziune pe care aș vrea să o evit. Mă îngrijorează faptul că mesajul afirmă feature -> feature în loc de feature -> origin/feature dar s-ar putea să fie doar o problemă de prezentare.

Îmi scapă ceva sau mă ocup de acest lucru într-un mod complet greșit? Nu este esențial să evit să fac rebase pe serverul de la distanță, dar face ca repararea oricăror conflicte de fuziune din rebase să fie mult mai dificilă.

Comentarii

  • Am avut aceeași problemă. Am vrut să pornesc un model de rebase de ramură (de genul acesta). Apoi am observat că am făcut o greșeală: Dacă doriți să faceți rebase (nu ar trebui să vă împingeți modificările în funcția de la distanță înainte de a face rebase pe master) Așadar, trimiteți niște cod la caracteristica dvs. Și acum vrei să îl împingi în caracteristica ta la distanță. Înainte de a face acest lucru: -Ar trebui să faceți fetch și să trageți masterul dacă este necesar. -Ar trebui să faceți rebase pe master dacă au existat unele modificări pe master pe care nu le aveți în caracteristica dvs. Acum puteți împinge caracteristica și nu va exista nicio problemă. –  > Por Markus.
4 răspunsuri
Adam Dymitruk

Se reduce la faptul dacă caracteristica este utilizată de o singură persoană sau dacă alții lucrează pe baza ei.

Poți forța push-ul după rebase dacă ești doar tu:

git push origin feature -f

Cu toate acestea, dacă alții lucrează la ea, ar trebui să fuzionezi și nu să rebasezi de la master.

git merge master
git push origin feature

Astfel, vă veți asigura că aveți un istoric comun cu persoanele cu care colaborați.

La un alt nivel, nu ar trebui să faceți back-merges. Ceea ce faceți este să poluați istoricul ramurii de caracteristici cu alte contribuții care nu aparțin caracteristicii, ceea ce face ca munca ulterioară cu acea ramură să fie mai dificilă – cu sau fără rebasare.

Acesta este articolul meu pe această temă, intitulat ramura pentru fiecare caracteristică.

Sper că vă ajută.

Comentarii

    31

  • +1 pentru if others are working on it, you should merge and not rebase off of master, rebase ar fi bine să fie utilizat numai pe ramura privată. –  > Por O.O.
  • alternativ la git push origin feature -f ai putea, de asemenea, să ștergi funcția de la distanță și să împingi din nou funcția -f  > Por Markus.
  • Fuzionarea master în ramura dvs. va crea o confirmare de fuziune și va provoca conflicte cu orice altă ramură de caracteristică deschisă din master după ce modificările dvs. sunt împinse. –  > Por Steven.
  • +1 pentru git push origin feature -f. În anumite contexte, poate fi necesar să se efectueze un rebase chiar și cu ramuri la distanță. Esențial este să știi ce faci. Și ar trebui să ne asumăm faptul că este posibil să ștergeți comisioanele din repo-ul de la distanță. –  > Por enagra.
ralphtheninja

Frumos că ați adus acest subiect în discuție.

Acesta este un lucru/concept important în git pe care o mulțime de utilizatori git ar beneficia de cunoaștere. git rebase este un instrument foarte puternic și vă permite să striviți comenzi împreună, să eliminați comenzi etc. Dar, ca în cazul oricărui instrument puternic, în principiu trebuie să știi ce faci sau ceva ar putea merge foarte prost.

Atunci când lucrați la nivel local și vă jucați cu ramurile locale, puteți face orice doriți, atâta timp cât nu ați împins modificările în depozitul central. Acest lucru înseamnă că vă puteți rescrie propriul istoric, dar nu și istoricul altora. Dacă vă jucați doar cu lucrurile locale, nimic nu va avea impact asupra altor depozite.

De aceea, este important să rețineți că, odată ce ați împins comisioanele, nu ar trebui să le refaceți ulterior. Motivul pentru care acest lucru este important este acela că alte persoane ar putea prelua comenzile dvs. și să-și bazeze munca pe contribuțiile dvs. la baza de cod, iar dacă mai târziu decideți să mutați acel conținut dintr-un loc în altul (rebasează-l) și să împingeți acele modificări, atunci alte persoane vor avea probleme și vor trebui să-și rebaseze codul. Acum imaginați-vă că aveți 1000 de dezvoltatori 🙂 Pur și simplu cauzează o mulțime de reelaborări inutile.

Comentarii

  • Downvoted pentru limbajul nepotrivit: meta.stackexchange.com/questions/22232/… – -.  > Por Powers.
  • Mi-am actualizat limbajul. –  > Por ralphtheninja.
Tilman Vogel

Pentru că ai rebasat feature peste noul master, localul dvs. feature nu este o devansare rapidă a origin/feature nu mai este o schimbare. Așadar, cred că în acest caz, este perfect corect să suprascrieți verificarea fast-forward făcând git push origin +feature. De asemenea, puteți specifica acest lucru în configurația dvs.

git config remote.origin.push +refs/heads/feature:refs/heads/feature

În cazul în care alte persoane lucrează pe lângă origin/feature, vor fi deranjați de această actualizare forțată. Puteți evita acest lucru integrând în noul fișier master în feature în loc de rebasare. Rezultatul va fi, într-adevăr, o avansare rapidă.

Andrew Aylett

Poți dezactiva verificarea (dacă ești sigur că știi ce faci) folosind opțiunea --force opțiunea de git push.

Comentarii

    18

  • Problema este că eu nu sunt sigur că știu cu adevărat ce fac 🙂 –  > Por kfb.
  • @r_: Vă rog să citiți răspunsul meu. S-ar putea să te ajute în înțelegerea a ceea ce faci 🙂 –  > Por ralphtheninja.