Aggiungi 'docs/04-fetch-merge-pull.md'
This commit is contained in:
@@ -0,0 +1,118 @@
|
||||
<!-- File: 04-fetch-merge-pull.md -->
|
||||
|
||||
# `git fetch`, `git merge` e `git pull` – differenze
|
||||
|
||||
Questi tre comandi sono spesso confusi, soprattutto da chi arriva da SVN.
|
||||
|
||||
---
|
||||
|
||||
## `git fetch`
|
||||
|
||||
- **Cosa fa:** scarica gli aggiornamenti dal remote (`origin`) ma **non** tocca la tua branch locale.
|
||||
- Aggiorna solo i branch “remoti” tipo `origin/develop`, `origin/main`.
|
||||
|
||||
Esempio:
|
||||
|
||||
```bash
|
||||
git fetch origin
|
||||
```
|
||||
|
||||
Dopo questo comando:
|
||||
|
||||
* `origin/develop` ha gli ultimi commit dal server
|
||||
* la tua branch `develop` locale è ancora come prima
|
||||
|
||||
Puoi vedere la differenza:
|
||||
|
||||
```bash
|
||||
git log --oneline --graph --decorate --all
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `git merge`
|
||||
|
||||
* **Cosa fa:** unisce i commit di un branch in un altro.
|
||||
* Crea un nuovo commit di **merge** (a meno che la storia non sia fast-forward).
|
||||
|
||||
Caso tipico: sei su `develop` e vuoi integrare gli ultimi commit dal server:
|
||||
|
||||
```bash
|
||||
git checkout development
|
||||
git fetch origin
|
||||
git merge origin/development
|
||||
```
|
||||
|
||||
Se non ci sono conflitti, Git può fare un **fast-forward**:
|
||||
|
||||
```text
|
||||
Updating 1a2b3c4..9f8e7d6
|
||||
Fast-forward
|
||||
src/report.py | 10 +++++++---
|
||||
1 file changed, 7 insertions(+), 3 deletions(-)
|
||||
```
|
||||
|
||||
Se ci sono conflitti, Git segnala i file:
|
||||
|
||||
```bash
|
||||
# risolvi i conflitti modificando i file
|
||||
git add file-conflitto.ext
|
||||
git commit # per completare il merge
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `git pull`
|
||||
|
||||
* **Cosa fa:** combinazione di:
|
||||
|
||||
1. `git fetch`
|
||||
2. `git merge` (o `git rebase`, se configurato)
|
||||
|
||||
Comando corto:
|
||||
|
||||
```bash
|
||||
git pull
|
||||
```
|
||||
|
||||
È comodo ma **meno esplicito**: non vedi distintamente fase di fetch e merge.
|
||||
|
||||
### Comportamento tipico a Meridiana (consigliato)
|
||||
|
||||
Per evitare sorprese:
|
||||
|
||||
```bash
|
||||
git fetch origin
|
||||
git merge origin/<nome-branch>
|
||||
```
|
||||
|
||||
Quindi, esempio completo:
|
||||
|
||||
```bash
|
||||
git checkout development
|
||||
git fetch origin
|
||||
git merge origin/development
|
||||
```
|
||||
|
||||
### Quando usare `git pull`
|
||||
|
||||
* Sei sulla branch che traccia già il remote (es. `development` → `origin/development`)
|
||||
* Sai che ti va bene un merge automatico
|
||||
|
||||
```bash
|
||||
git checkout development
|
||||
git pull
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Riepilogo concettuale
|
||||
|
||||
* **`git fetch`**
|
||||
➜ "Scarica le novità dal server, ma non toccare il mio lavoro"
|
||||
|
||||
* **`git merge`**
|
||||
➜ "Integra le modifiche da un branch dentro il branch su cui sono"
|
||||
|
||||
* **`git pull`**
|
||||
➜ "Scarica e integra subito (fetch + merge) nella branch attuale"
|
||||
Reference in New Issue
Block a user