diff options
author | Ekaitz Zarraga <ekaitz@elenq.tech> | 2022-05-24 22:33:36 +0200 |
---|---|---|
committer | Ekaitz Zarraga <ekaitz@elenq.tech> | 2022-05-26 14:51:04 +0200 |
commit | 68855f63c8e6685cfb47f5f29bb92b3ab8583abf (patch) | |
tree | 9561c4b15ed0258eb4b0fdfdc71a7510f04da44d /1.md | |
parent | e18fa33bc1f60d2fff070f761b5e991462989df9 (diff) |
Rebase
Diffstat (limited to '1.md')
-rw-r--r-- | 1.md | 101 |
1 files changed, 100 insertions, 1 deletions
@@ -491,7 +491,7 @@ Lehenengo zatian `HEAD`-en zegoena dago eta bigarrenean `iss53`-n zegoena. - `git branch -d <adarra>` adarrak ezabatzeko. Mergeatu gabe dauden adarrak ez ditu zuzenean ezabatzen. - `git branch --move <adarra> <izen_berria>` izenez aldatzeko. -- `git push --set-upstream <remote> <adarra>` remoteari zein adar erabili behar +- `git push -u|--set-upstream <remote> <adarra>` remoteari zein adar erabili behar duen esateko - `git push <remote> --delete <adarra>` remotean adar bat ezabatzeko @@ -501,3 +501,102 @@ Lehenengo zatian `HEAD`-en zegoena dago eta bigarrenean `iss53`-n zegoena. - Topic branches: issue eta feature bakoitzeko adar berri bat eratzen da. ## Adarrak remotetan + +Gitek remoten erreferentziak gordetzen ditu remoten egoera ikusi ahal izateko. +`git ls-remote <remote>` edo `git remote show <remote>` erabiliz remoteen +egorea ikusi daiteke. + +Remoten adarrak lokalean ikusi daitezke `<remote>/<adarra>` izenarekin. Ezin +dira aldatu. Push egiterakoan aldatzen dira, remotearen egoera aldatu delako. + +![Adibidea: repositorio lokalak bi commit berri ditu](img/remote-branches.png) + +## Push egitea + +- `git push <remote> <adarra>` adarra remotera pusheatzeko. Eskuz egin behar + da. Horrela adar lokalak babesten dira eta ez dira automatikoki igotzen. + +- `<adar_lokala>:<adar_remotoa>` erabiltzean izen ezberdinak jarri ahal zaizkie + adarrei, bata lokalean eta bestea remotean + +## Tracking branches + +Remoteak jarraitzeko erabiltzen mekanismoa da. Remotearen adar bat (*upstream*) +adar lokal baten (*tracking*) arteko erlazioa da. + +- `git checkout -b <adar_izena> <remote>/<adar>` trakeatzen du + `<remote>/<adar>` `<adar_izena>` izenarekin +- `git checkout --track <remote>/<adar>` oraingo adarra eta remotearena + erlazionatu. Sinpleago. +- `git checkout <adarra>` erlazioa eratzen du automatikoki, `<adarra>` lokalean + existitzen ez bada. Sinpleago. +- `git clone` egiterakoan `master` adarra lokala eratzen da `origin/master` + adarra trakeatzen. +- `git branch -u|--set-upstream <remote>/<adarra>` zure adarraren upstream-a + aldatzeko. Ikusi `git push`-en. + +> `@{upstream}` edo `@{u}` idatzi daiteke hortik aurrera remotearen adarraren +> izen osoa erabili beharrean + +## Pull egitea + +Tracking adarra aktibatuta badago, `git pull` egiteak zuzenean `git fetch` eta +`git merge` aldi berean egingo ditu. + +Kontuz ibili: batzutan `git pull`-en magia ulertzeko zaila izan daiteke. +Proiektua jende askok ukitzen badu, hobe `git fetch` egitea. + +## Adarrak eta rebaseak — I + +![](img/basic-rebase-1.png) + +## Adarrak eta rebaseak — II + +![`git merge` egitean gertatzen dena](img/basic-rebase-2.png) + +## Adarrak eta rebaseak — II + +![`git checkout experiment` +`git rebase master`](img/basic-rebase-3.png) + +Orain merge-a *fast-forward* izango da eta ez du merge commit-ik gehituko. + +## Rebase konplexuago bat — I + +![](img/interesting-rebase-1.png) + +## Rebase konplexuago bat — II + +![`git rebase --onto master server client`](img/interesting-rebase-2.png) + +`client`-en dauden aldaketak pasatzen ditu `master`-era `server`-en daudenak +izan ezik. + +Orain `server` `master`-en rebaseatu daiteke eta gero `git merge` +*fast-forward* bat egin. + +## Rebasekin kontuz ibili + +Rebaseak egiterakoan commit berriak egiten dira, aurrekoen antzekoak edukiz, ez +dira berdinak. Remote-an pusheatzerakoan beste lankideek reabaseak egitera +behartzen ditu: + +- `git push --force` remotean historia berridazten du. Git zerbitzuetan adar + babestuak existitzen dira hau saihesteko. Kontuz. +- `git pull --rebase` lagundu dezake `pull` egiterakoan, remotean historia + berridatzi bada. Pull-en estrategietako bat da, asko daude eta defektuz + egiteko konfiguratu daitezke. + +## Rebase vs Merge + +Filosofiaren arabera bata edo bestea gehiago erabiltzea komeni da: + +- Repositorioa historiko moduan ulertuta: rebase egitea txarra izango + litzateke, historikoa zapaltzen baitu. (*fossil-ek filosofia hau jarraitzen + du, ez dauka rebase egiteko tresnarik*) +- Repositorioa *making of* modura ikusten bada aproposa da rebase egitea. + Historikoa garbiagoa uzten duelako. + +Aholkua: lokalean reabase egin commit historikoa garbitzeko baina behin +zerbitzarira igota historia ez aldatu, lankideen prozesuan eragina baitu. + |