From 68855f63c8e6685cfb47f5f29bb92b3ab8583abf Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga <ekaitz@elenq.tech>
Date: Tue, 24 May 2022 22:33:36 +0200
Subject: Rebase

---
 1.md | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 100 insertions(+), 1 deletion(-)

(limited to '1.md')

diff --git a/1.md b/1.md
index 74b5cfb..7032974 100644
--- a/1.md
+++ b/1.md
@@ -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.
+
-- 
cgit v1.2.3